From mailnull@www1.ietf.org Mon Feb 3 04:13:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01351 for ; Mon, 3 Feb 2003 04:13:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h139IHO04778 for sipping-archive@odin.ietf.org; Mon, 3 Feb 2003 04:18:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h139IGJ04775 for ; Mon, 3 Feb 2003 04:18:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01348 for ; Mon, 3 Feb 2003 04:12:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h139G5J04717; Mon, 3 Feb 2003 04:16:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h139ERJ04649 for ; Mon, 3 Feb 2003 04:14:27 -0500 Received: from thoth.sbs.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01263 for ; Mon, 3 Feb 2003 04:09:01 -0500 (EST) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id h139Cb621458 for ; Mon, 3 Feb 2003 10:12:37 +0100 (MET) Received: from mars.cert.siemens.de (ust.mchp.siemens.de [139.23.201.17]) by mail2.siemens.de (8.11.6/8.11.6) with ESMTP id h139CbR08036 for ; Mon, 3 Feb 2003 10:12:37 +0100 (MET) Received: from mail-k.mchp.siemens.de (mail-k.mchp.siemens.de [139.23.202.237]) by mars.cert.siemens.de (8.12.7/8.12.7/$SiemensCERT: mail/cert.mc,v 1.41 2003/01/31 16:25:20 ust Exp $) with ESMTP id h139CbF7055743 for ; Mon, 3 Feb 2003 10:12:37 +0100 (CET) Received: from mhpaba5c (mhpaba5c [139.23.204.46]) by mail-k.mchp.siemens.de with ESMTP id h139D4g4026201 for ; Mon, 3 Feb 2003 10:13:04 +0100 (MET) From: "Steffen Fries" Organization: Siemens AG To: sipping@ietf.org Date: Mon, 03 Feb 2003 10:12:36 +0100 MIME-Version: 1.0 Reply-to: steffen.fries@siemens.com Message-ID: <3E3E4094.15559.99A289@localhost> Priority: normal X-mailer: Pegasus Mail for Windows (v4.02a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Content-Transfer-Encoding: 7BIT Subject: [Sipping] SIP, SRTP and MIKEY Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi, I'm not quite sure, which working group fits best for this question, thus I'm posting this question here too. I already had a post in the the SIP WG but got only one reply. When SIP and SRTP are used in conjunction, an appropriate key management is necessary for SRTP. Within the MSEC WG MIKEY has been defined, which is thought to be used (also) for SRTP. MIKEY and an related draft (draft-ietf-msec-MIKEY-DHHMAC- 01.txt) offer 4 different key management methods based on: - pre-shared secrets - public key encryption - Diffie Hellman protected with signatures - Diffie Hellman protected with pre-shared secrets When MIKEY and SRTP are to be used in a SIP environment, what would be a suitable choice out of the four options? I'm not sure if the pre-shared secret based methods are suitable, since this would assume, that all users who want to communicate need to exchange a shared secret before. Well, this could be done by puting a shared secret in the SIP message and securing this by S/MIME, but then MIKEY would be protected by symmetric methods, although asymmetric technology was used to secure the shared secret transport, namely S/MIME. One could also use the certificates and private keys to secure MIKEY right from the beginning. There might be scenarios where the symmetric case is appropriate, but I'm not sure if this is a rather general case. Is MIKEY generally considered for key management in SIP or will this rather be done using draft-baugher-mmusic-sdpmediasec- 00.txt secured by S/MIME? The usage of MIKEY and SRTP is especially interesting in conjunction with other multimedia protocols like H.323. Voice encryption and associated key management could be performed across the different signaling protocols. Was there already a discussion related to this question, which I may be missed? Regards Steffen _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Feb 3 07:53:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06686 for ; Mon, 3 Feb 2003 07:53:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13Cwro19169 for sipping-archive@odin.ietf.org; Mon, 3 Feb 2003 07:58:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13CwrJ19166 for ; Mon, 3 Feb 2003 07:58:53 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06681 for ; Mon, 3 Feb 2003 07:53:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13Cw8J19124; Mon, 3 Feb 2003 07:58:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h139utJ06766 for ; Mon, 3 Feb 2003 04:56:55 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01672 for ; Mon, 3 Feb 2003 04:51:28 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h139t4KV006483; Mon, 3 Feb 2003 10:55:04 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 3 Feb 2003 10:55:04 +0100 Message-ID: <1F55F6582266314A85A55F6241509B670575B17F@Esealnt863.al.sw.ericsson.se> From: "Fredrik Lindholm (EAB)" To: "'Steffen Fries'" Cc: "'sipping@ietf.org'" , "Elisabetta Carrara (EAB)" Subject: RE: [Sipping] SIP, SRTP and MIKEY Date: Mon, 3 Feb 2003 10:51:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) 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: , Hi Steffen, I'll guess Elisabetta's mail got lost when she tried to answer you the last time (please also cc: AVT and/or MSEC/MMUSIC if you have questions regarding SRTP and/or MIKEY). Best, Fredrik -----Original Message----- From: Elisabetta Carrara (EAB) Sent: den 17 januari 2003 16:41 To: 'Steffen Fries'; sip@ietf.org Cc: Fredrik Lindholm (EAB) Subject: RE: SRTP and MIKEY usage in SIP Hi Steffen the public-key based methods are most suitable for client-to-client communications. The pre-shared could be for ex a good choice for client(s)-to-server communications. So, for SIP the public-key based may be more suitable, generally speaking. Cheers, /E > -----Original Message----- > From: Steffen Fries [mailto:steffen.fries@siemens.com] > Sent: den 17 januari 2003 16:20 > To: sip@ietf.org > Cc: Elisabetta.Carrara@era.ericsson.se > Subject: SRTP and MIKEY usage in SIP > > > Hi, > > I'm not quite sure, which working group fits best for this > question, thus I'm starting with the SIP WG ;-) > > When SIP and SRTP are used in conjunction, an appropriate > key management is necessary for SRTP. Within the MSEC WG > MIKEY has been defined, which is thought to be used (also) > for SRTP. > > MIKEY and an related draft (draft-ietf-msec-MIKEY-DHHMAC- > 01.txt) offer 4 different key management methods based on: > - pre-shared secrets > - public key encryption > - Diffie Hellman protected with signatures > - Diffie Hellman protected with pre-shared secrets > > When MIKEY and SRTP are to be used in a SIP environment, > what would be a suitable choice out of the four options? > > I'm not sure if the pre-shared secret pased methods are > suitable, since this would assume, that all users who want to > communicate need to exchange a shared secret before. Well, this > could be done by puting a shared secret in the SIP message and > securing this by S/MIME, but then MIKEY would be protected by > symmetric methods, although asymmetric technology was used to > secure the shared secret transport, namely S/MIME. One could > also use the certificates and private keys to secure MIKEY > right from the beginning. > > There might be scenarios where the symmetric case is > appropriate, but I'm not sure if this is a rather general case. > > Is MIKEY generally considered for key management in SIP or will > this rather be done using draft-baugher-mmusic-sdpmediasec- > 00.txt secured by S/MIME? > > The usage of MIKEY and SRTP is especially interesting in > conjunction with other multimedia protocols like H.323. Voice > encryption and associated key management could be performed > across the different signaling protocols. > > Was there already a discussion related to this question, which > I may be missed? > > Regards > Steffen > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Feb 3 11:16:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11876 for ; Mon, 3 Feb 2003 11:16:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13GLmd01127 for sipping-archive@odin.ietf.org; Mon, 3 Feb 2003 11:21:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13GLlJ01123 for ; Mon, 3 Feb 2003 11:21:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11846 for ; Mon, 3 Feb 2003 11:16:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13GKrJ01057; Mon, 3 Feb 2003 11:20:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13GJlJ00965 for ; Mon, 3 Feb 2003 11:19:47 -0500 Received: from smail3.alcatel.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11776 for ; Mon, 3 Feb 2003 11:14:12 -0500 (EST) From: Pascal.Jalet@alcatel.fr Received: from frmail21.netfr.alcatel.fr (frmail21.netfr.alcatel.fr [155.132.182.151]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id h13GHmPj008401; Mon, 3 Feb 2003 17:17:48 +0100 Subject: [sipping] draft-burger-sipping-netann-03.txt (Early media announcement) To: "Eric Burger" Cc: David.Rio@alcatel.fr, sipping@ietf.org Date: Mon, 3 Feb 2003 17:17:46 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL21/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 02/03/2003 17:17:48 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Eric, In early media announcement scenario, you suggest to send a 487 REQUEST TERMINATED, once the anouncement is played. But in RFC 3261, the 487 response is said to be used only when the previous request has been terminated with a BYE or a CANCEL. It is not the case in early media announcement scenario. So my question is ca:n we consider that the early media annoucement scenario is compliant with RFC 3261? We've faced a case in which a softphone refuses to close a call (screen still active) because it has received a 487 without any previous BYE or CANCEL. Is this terminal not compliant with RFC3261?(below is the call flow of the call) Softphone PROXY (SER) MS INVITE ----------> --------------> <----------------- ---------------183 PLAY of 10 s <------------------ ---------------487 ACK---------------> ----------------> After the ACK is sent, the call is still active. pascal _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Feb 3 14:53:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18936 for ; Mon, 3 Feb 2003 14:53:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13Jx1B20718 for sipping-archive@odin.ietf.org; Mon, 3 Feb 2003 14:59:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13Jx0J20715 for ; Mon, 3 Feb 2003 14:59:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18904 for ; Mon, 3 Feb 2003 14:53:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13JvaJ20669; Mon, 3 Feb 2003 14:57:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13JuHJ20631 for ; Mon, 3 Feb 2003 14:56:17 -0500 Received: from zoe.office.snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18839 for ; Mon, 3 Feb 2003 14:50:39 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 3 Feb 2003 14:54:19 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D248733@zoe.office.snowshore.com> Thread-Topic: Updated Version of MSCML Thread-Index: AcLLvf77yAQ8BXNXSiOKQBxK7US9ZQ== From: "Eric Burger" To: "Sipping (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h13JuHJ20632 Subject: [Sipping] Updated Version of MSCML Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Until it hits the archive: http://flyingfox.snowshore.com/i-d/sip/draft-vandyke-mscml-01.html http://flyingfox.snowshore.com/i-d/sip/draft-vandyke-mscml-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 mailnull@www1.ietf.org Tue Feb 4 06:46:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17525 for ; Tue, 4 Feb 2003 06:46:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14Bq7N19811 for sipping-archive@odin.ietf.org; Tue, 4 Feb 2003 06:52:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14Bq7J19808 for ; Tue, 4 Feb 2003 06:52:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17445 for ; Tue, 4 Feb 2003 06:46:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14BpUJ19730; Tue, 4 Feb 2003 06:51:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14BoPJ19633 for ; Tue, 4 Feb 2003 06:50:25 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17152; Tue, 4 Feb 2003 06:44:27 -0500 (EST) Message-Id: <200302041144.GAA17152@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 04 Feb 2003 06:44:26 -0500 Subject: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-01.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MIME media types for DPNSS Objects Author(s) : R. Mukundan et al. Filename : draft-mukundan-sipping-dpnss-01.txt Pages : 9 Date : 2003-2-3 This document describes Multipart Internet Mail Extensions (MIME) type for application/Digital Private Network Signaling System (DPNSS) objects for use in Session Initiation Protocol (SIP) applications, according to the rules defined in RFC 2048. These types can be used to identify Digital Private Network Signaling System 1 (DPNSS 1) objects within a SIP message such as INVITE or INFO, as might be implemented when using SIP in an environment where part of the call involves interworking to DPNSS 1 based Private Networks. RFC 3204 addresses a similar need for Integrated Service Digital Network User Part (ISUP) and Q Signaling (QSIG). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mukundan-sipping-dpnss-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mukundan-sipping-dpnss-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-3125419.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mukundan-sipping-dpnss-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-mukundan-sipping-dpnss-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-3125419.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Feb 4 06:48:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17616 for ; Tue, 4 Feb 2003 06:48:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14Bs2h19975 for sipping-archive@odin.ietf.org; Tue, 4 Feb 2003 06:54:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14Bs2J19972 for ; Tue, 4 Feb 2003 06:54:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17601 for ; Tue, 4 Feb 2003 06:48:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14BrYJ19916; Tue, 4 Feb 2003 06:53:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14BpUJ19732 for ; Tue, 4 Feb 2003 06:51:30 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17371; Tue, 4 Feb 2003 06:45:32 -0500 (EST) Message-Id: <200302041145.GAA17371@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 04 Feb 2003 06:45:32 -0500 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-overlap-04.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : Mapping of of Integrated Services Digital Network (ISUP) Overlap Signalling to the Session Initiation Protocol Author(s) : G. Camarillo et al. Filename : draft-ietf-sipping-overlap-04.txt Pages : 12 Date : 2003-2-3 This document describes a way to map ISUP overlap signalling to SIP. This mechanism might be implemented when using SIP in an environment where part of the call involves interworking with the Public Switched Telephone Network (PSTN). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-overlap-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sipping-overlap-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sipping-overlap-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-3125647.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-overlap-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-overlap-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-3125647.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Feb 4 06:56:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17826 for ; Tue, 4 Feb 2003 06:56:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14C1bQ20349 for sipping-archive@odin.ietf.org; Tue, 4 Feb 2003 07:01:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14C1bJ20346 for ; Tue, 4 Feb 2003 07:01:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17819 for ; Tue, 4 Feb 2003 06:55:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14C17J20327; Tue, 4 Feb 2003 07:01:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14C0tJ20292 for ; Tue, 4 Feb 2003 07:00:55 -0500 Received: from wiprom2mx1.wipro.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17791 for ; Tue, 4 Feb 2003 06:54:53 -0500 (EST) Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id h14BwQv06052 for ; Tue, 4 Feb 2003 17:28:26 +0530 (IST) Received: from blr-ec-msg01.wipro.com ([10.200.50.99]) by blr-ec-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 4 Feb 2003 17:28:21 +0530 Received: from ranjith2 ([192.168.178.234]) by blr-ec-msg01.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 4 Feb 2003 17:28:21 +0530 From: "Ranjith Mukundan" To: Subject: RE: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-01.txt Date: Tue, 4 Feb 2003 17:32:10 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <200302041144.GAA17152@ietf.org> X-OriginalArrivalTime: 04 Feb 2003 11:58:21.0188 (UTC) FILETIME=[B6861C40:01C2CC44] 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi List, We would like you take a look at this draft and revert with any comments/queries that you might have. SIPPING Chairs, The authors feel that the requirement and the need for this MIME type is quite acute. Hence we'd like you to consider this for inclusion as a WG I-D and suggest the way forward. - ranjith.. -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, February 04, 2003 5:14 PM To: IETF-Announce: Cc: sipping@ietf.org Subject: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MIME media types for DPNSS Objects Author(s) : R. Mukundan et al. Filename : draft-mukundan-sipping-dpnss-01.txt Pages : 9 Date : 2003-2-3 This document describes Multipart Internet Mail Extensions (MIME) type for application/Digital Private Network Signaling System (DPNSS) objects for use in Session Initiation Protocol (SIP) applications, according to the rules defined in RFC 2048. These types can be used to identify Digital Private Network Signaling System 1 (DPNSS 1) objects within a SIP message such as INVITE or INFO, as might be implemented when using SIP in an environment where part of the call involves interworking to DPNSS 1 based Private Networks. RFC 3204 addresses a similar need for Integrated Service Digital Network User Part (ISUP) and Q Signaling (QSIG). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mukundan-sipping-dpnss-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mukundan-sipping-dpnss-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Feb 5 06:49:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19370 for ; Wed, 5 Feb 2003 06:49:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h15BtCj18092 for sipping-archive@odin.ietf.org; Wed, 5 Feb 2003 06:55:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15BtCJ18089 for ; Wed, 5 Feb 2003 06:55:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19308 for ; Wed, 5 Feb 2003 06:48:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15BseJ18016; Wed, 5 Feb 2003 06:54:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15BpPJ17767 for ; Wed, 5 Feb 2003 06:51:25 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19104; Wed, 5 Feb 2003 06:44:57 -0500 (EST) Message-Id: <200302051144.GAA19104@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org, sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 05 Feb 2003 06:44:57 -0500 Subject: [Sipping] I-D ACTION:draft-ietf-sip-scvrtdisco-03.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Session Initiation Protocol Extension Header Field for Service Route Discovery During Registration Author(s) : D. Willis, B. Hoeneisen Filename : draft-ietf-sip-scvrtdisco-03.txt Pages : 18 Date : 2003-2-4 This document defines a SIP extension header field used in conjunction with responses to REGISTER requests to provide a mechanism by which a registrar may inform a registering UA of a service route that the UA may use to request outbound services from the registrar's domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-scvrtdisco-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-scvrtdisco-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-scvrtdisco-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-4134059.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-scvrtdisco-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-scvrtdisco-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-4134059.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Feb 5 14:57:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08340 for ; Wed, 5 Feb 2003 14:57:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h15K3aj18609 for sipping-archive@odin.ietf.org; Wed, 5 Feb 2003 15:03:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15K3ZJ18606 for ; Wed, 5 Feb 2003 15:03:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08332 for ; Wed, 5 Feb 2003 14:56:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15K2jJ18554; Wed, 5 Feb 2003 15:02:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15K1mJ18500 for ; Wed, 5 Feb 2003 15:01:48 -0500 Received: from cerbrus.convedia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08283 for ; Wed, 5 Feb 2003 14:55:12 -0500 (EST) Received: from ladon.convedia.com (ladon [192.168.208.15]) by cerbrus.convedia.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24574; Wed, 5 Feb 2003 11:56:12 -0800 (PST) Received: from laptop52 (laptop52.convedia.com [192.168.208.230]) by ladon.convedia.com (8.9.3+Sun/8.9.3) with SMTP id LAA26139; Wed, 5 Feb 2003 11:58:45 -0800 (PST) From: "Garland Sharratt" To: "Eric Burger" Cc: "Sipping@Ietf. Org" Subject: RE: [Sipping] Updated Version of MSCML Date: Wed, 5 Feb 2003 11:58:39 -0800 Keywords: .aaa Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <4A3384433CE2AB46A63468CB207E209D248733@zoe.office.snowshore.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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eric: I took a look at draft-vandyke-mscml-01 and saw no substantive changes. MSCML isn't perfect but my only real concern with it (both 01 and 00) is the fact that SnowShore has claimed IPR on it. This doesn't work for an interface that is supposed to be -- and otherwise likely would be -- adopted by all call agent and media server vendors who need its type of media server control. I did notice that the following paragraph in 00 -- "The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights." -- has been removed in 01. But the SnowShore notice on the IETF Page of Intellectual Property Rights Notices is still present ("SnowShore Patent Statement pertaining to draft-vandyke-mscml"). Is there any chance of getting MSCML released into the public domain so that it can be widely and safely adopted by everyone? Thanks, Garland -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf Of Eric Burger Sent: Monday, February 03, 2003 11:54 To: Sipping (E-mail) Subject: [Sipping] Updated Version of MSCML Until it hits the archive: http://flyingfox.snowshore.com/i-d/sip/draft-vandyke-mscml-01.html http://flyingfox.snowshore.com/i-d/sip/draft-vandyke-mscml-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 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 6 05:34:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11676 for ; Thu, 6 Feb 2003 05:34:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16Af6f20740 for sipping-archive@odin.ietf.org; Thu, 6 Feb 2003 05:41:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16Af5p20737 for ; Thu, 6 Feb 2003 05:41:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11650 for ; Thu, 6 Feb 2003 05:33:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16Adep20653; Thu, 6 Feb 2003 05:39:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16AcJp20562 for ; Thu, 6 Feb 2003 05:38:19 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11613; Thu, 6 Feb 2003 05:31:24 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h16AYuKV020200; Thu, 6 Feb 2003 11:34:56 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id DY5TVRQT; Thu, 6 Feb 2003 11:34:56 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h16AYuH7021218; Thu, 6 Feb 2003 12:34:56 +0200 (EET) Message-ID: <3E423A4E.3C404641@lmf.ericsson.se> Date: Thu, 06 Feb 2003 12:34:54 +0200 X-Sybari-Trust: 0c6564b1 9ffcebbb 22f6c2a2 00000138 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip , sipping CC: Dean Willis , Jon Peterson , Rohan Mahy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Design teams Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, I am updating the design team web pages for SIPPING and SIP. http://www.softarmor.com/sipwg/teams http://www.softarmor.com/sipping/teams/ I intend to consider the following design teams terminated: SIP MIB SIP Security PacketCable DCS Convergence Call Control SIP-T Call Flow SIP-H.323 If somebody believes that any of these design teams is alive and, therefore, it should not be considered terminated, let me know. Otherwise, I will "execute" all of them. Thanks, Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 6 09:36:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19384 for ; Thu, 6 Feb 2003 09:36:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16EgaQ04295 for sipping-archive@odin.ietf.org; Thu, 6 Feb 2003 09:42:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16Egap04292 for ; Thu, 6 Feb 2003 09:42:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19365 for ; Thu, 6 Feb 2003 09:35:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16Efdp04247; Thu, 6 Feb 2003 09:41:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16EbAp03735 for ; Thu, 6 Feb 2003 09:37:10 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19090; Thu, 6 Feb 2003 09:30:09 -0500 (EST) Message-Id: <200302061430.JAA19090@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 06 Feb 2003 09:30:09 -0500 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-aaa-req-02.txt,.pdf Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : Authentication, Authorization and Accounting Requirements for the Session Initiation Protocol Author(s) : J. Loughney, G. Camarillo Filename : draft-ietf-sipping-aaa-req-02.txt,.pdf Pages : 14 Date : 2003-2-5 As SIP services are deployed on the Internet, there is a need for authentication, authorization and accounting of SIP sessions. This document sets out the basic requirements for this work. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-aaa-req-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sipping-aaa-req-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sipping-aaa-req-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-5140318.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-aaa-req-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-aaa-req-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-5140318.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 7 08:34:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10479 for ; Fri, 7 Feb 2003 08:34:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17Df5h04084 for sipping-archive@odin.ietf.org; Fri, 7 Feb 2003 08:41:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17Df5p04081 for ; Fri, 7 Feb 2003 08:41:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10439 for ; Fri, 7 Feb 2003 08:33:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17DeCp03885; Fri, 7 Feb 2003 08:40:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16Hl1p18753 for ; Thu, 6 Feb 2003 12:47:01 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27453; Thu, 6 Feb 2003 12:39:56 -0500 (EST) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h16HiPuA020272; Thu, 6 Feb 2003 12:44:25 -0500 (EST) Received: from cisco.com (klingle-ultra.cisco.com [64.102.93.47]) by dingdong.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABJ37277; Thu, 6 Feb 2003 12:43:30 -0500 (EST) Message-ID: <3E429EC3.C7FFDFB5@cisco.com> Date: Thu, 06 Feb 2003 12:43:31 -0500 From: Kevin Lingle X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: sip , sipping , Dean Willis , Jon Peterson , Rohan Mahy , Jean-Francois Mule , "Kavitha P." References: <3E423A4E.3C404641@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: [Sip] Design teams Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit gonzalo, please don't terminate the SIP MIB team. we are still here, but have been having a hard time devoting time to a new revision (-05) of the I-D. we are working on it and we are targetting the end of the month to publish. the previous version of the draft (-04) has expired. that version had passed last call in sip wg. we took a moment to consider updating the mib to comply with rfc3261 - as it was riddled with references to 2543 at that time - before forwarding to iesg. we decided it prudent and thus the need for -05. however, other project priorities and some personal issues with the team have made it difficult to devote time/resources to -05 of the draft, but i hope that we are moving forward at this point. kevin Gonzalo Camarillo wrote: > > Folks, > > I am updating the design team web pages for SIPPING and SIP. > http://www.softarmor.com/sipwg/teams > http://www.softarmor.com/sipping/teams/ > > I intend to consider the following design teams terminated: > > SIP MIB > SIP Security > PacketCable DCS Convergence > Call Control > SIP-T > Call Flow > SIP-H.323 > > If somebody believes that any of these design teams is alive and, > therefore, it should not be considered terminated, let me know. > Otherwise, I will "execute" all of them. > > Thanks, > > Gonzalo > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kevin R. Lingle 919.392.2029 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 7 13:38:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17619 for ; Fri, 7 Feb 2003 13:38:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17IjaR21628 for sipping-archive@odin.ietf.org; Fri, 7 Feb 2003 13:45:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17Ijap21625 for ; Fri, 7 Feb 2003 13:45:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17574 for ; Fri, 7 Feb 2003 13:38:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17Iigp21587; Fri, 7 Feb 2003 13:44:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17Ihxp21560 for ; Fri, 7 Feb 2003 13:43:59 -0500 Received: from wiprom2mx1.wipro.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17545 for ; Fri, 7 Feb 2003 13:36:18 -0500 (EST) Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id h17Idtv18873 for ; Sat, 8 Feb 2003 00:09:56 +0530 (IST) Received: from blr-ec-msg01.wipro.com ([10.200.50.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 8 Feb 2003 00:09:50 +0530 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-01.txt Date: Sat, 8 Feb 2003 00:09:50 +0530 Message-ID: <5CD22C179E0D7C49954F3ACCA07E4EDE09D195@blr-ec-msg01.wipro.com> Thread-Topic: RE: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-01.txt Thread-Index: AcLO2Ewlfk1DMQpRRI+Z7cQYL+7aUg== From: "Ranjith Mukundan" To: X-OriginalArrivalTime: 07 Feb 2003 18:39:50.0832 (UTC) FILETIME=[4C4F5300:01C2CED8] 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: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable RE: [Sipping] I-D = ACTION:draft-mukundan-sipping-dpnss-01.txt

Hi,

posting WRT http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-= 01.txt


>>
>> Why is it so important to be able to tunnel DPNSS in SIP?  = I'd prefer
>> that folks implement a translation to SIP, where SIP can = natively carry
>> all the information that DPNSS is trying to convey.
>>

To put things in perspective:

1- DPNSS is a protocol (deployed primarily in UK, NZ, Australia and = parts of NA) very similar to QSIG (deployed primarily Europe) for = interconnecting PBXs or centrex customers hosted off LEs. DPNSS (like = QSIG) finds enormous application towards realizing a local VPN or = network-wide VPN services.

2- This draft aims to do exactly what RFC 3204 (MIME objects for = QSIG/ISUP) does for QSIG with appropriate/relevant customization for = DPNSS - i.e., to provide end-to-end & *complete*, DPNSS Service = transparency between pockets of DPNSS based private networks over a SIP = based core.

3- Currently, circuit-switched SS7 based cores, provide equivalent DPNSS = tunneling mechanisms through (ETSI & ANSI) ISUP *apart from* the = concomitant translation/interworking mechanisms to ISUP. The = translation/interworking mechanism to ISUP is limited to the basic call = and certain ISUP supplementary services where there is a direct/easy = equivalent.

4- H.323 also provides equivalent tunneling mechanisms (via the H.450 = Annexe procedures) for transparently carrying DSS1 based signaling = between DSS1-based network elements/gateways, over a H.323 core.

Some specifics:

1- DPNSS supports, as specified in BTNR 188, approximately 240+ = supplementary features/services (like Call Back When Free, Call Back = When Next Used, Executive Intrusion, Travelling Class of Service, Do Not = Disturb, Night Service, Private Network Route Optimization, Centralized = Operator, Three Party Takeover, Remote Diversion Registration etc). It = would be almost impossible to interwork to equivalent mechanisms in SIP, = without losing the service transparency when using an intervening SIP = based core.

2- Yes, we definitely need an interworking/translation mechanism to map = all the basic call/service paremeters, and procedures for mapping the = messages. But this does not preclude the need for a DPNSS MIME type, but = would rather be complimentary to the MIME type mechanism. Similar to http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-00= .txt , for QSIG, we are in the process of putting together an = interworking draft for DPNSS as well - but rather than making it DPNSS = specific, we are trying to make it a common draft to cover PRI, DPNSS = & DASS2 [as Q.SIG interworking is already a SIPPING WG ID]. Note = that, PRI and DASS2 will not need a MIME type as these are, as one might = be aware, for PSTN access, unlike DPNSS and QSIG (which are private = network protocols).

3- From the SIP perspective, carrying non-SIP applications as MIME = objects to ensure end to end service transparency is architecturally = less appalling than, say for e.g., tunneling DSS1 protocols in H.323 = based network - so the SIP DPNSS MIME proposition as per this I-D is the = obvious way forward for DPNSS service transparency over a SIP based = core, especially now that we see acute deployment needs to be met.

cheers,
ranjith..

> -----Original Message-----
> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]= On Behalf
> Of
> Ranjith Mukundan
> Sent: Tuesday, February 04, 2003 5:32 PM
> To: sipping@ietf.org
> Subject: RE: [Sipping] I-D = ACTION:draft-mukundan-sipping-dpnss-01.txt
>
>
> Hi List,
> We would like you take a look at this draft and revert with any
> comments/queries that you might have.
>
> SIPPING Chairs,
> The authors feel that the requirement and the need for this MIME = type
> is
> quite acute. Hence we'd like you to consider this for inclusion as = a
> WG I-D
> and suggest the way forward.
>
> - ranjith..
>
> -----Original Message-----
> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]= On Behalf
> Of
> Internet-Drafts@ietf.org
> Sent: Tuesday, February 04, 2003 5:14 PM
> To: IETF-Announce:
> Cc: sipping@ietf.org
> Subject: [Sipping] I-D = ACTION:draft-mukundan-sipping-dpnss-01.txt
>
>
> A New Internet-Draft is available from the on-line = Internet-Drafts
> directories.
>
>
>       Title   =         : MIME media types for DPNSS = Objects
>       = Author(s)       : R. Mukundan et al.
>       = Filename        : = draft-mukundan-sipping-dpnss-01.txt
>       Pages   =         : 9
>       Date    =         : 2003-2-3
>
> This document describes Multipart Internet Mail Extensions (MIME) = type
> for application/Digital Private Network Signaling System = (DPNSS)
> objects for use in Session Initiation Protocol (SIP) = applications,
> according to the rules defined in RFC 2048. These types can be used = to
> identify Digital Private Network Signaling System 1 (DPNSS 1) = objects
> within a SIP message such as INVITE or INFO, as might be = implemented
> when using SIP in an environment where part of the call = involves
> interworking to DPNSS 1 based Private Networks. RFC 3204 addresses = a
> similar need for Integrated Service Digital Network User Part = (ISUP)
> and Q Signaling (QSIG).
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-0= 1.tx
> t
>
> To remove yourself from the IETF Announcement list, send a message = to
> ietf-announce-request with the word unsubscribe in the body of = the
> message.
>
> Internet-Drafts are also available by anonymous FTP. Login with = the
> username
> "anonymous" and a password of your e-mail address. After = logging in,
> type "cd internet-drafts" and then
>       "get = draft-mukundan-sipping-dpnss-01.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html<= /A> or
> ftp://ftp.ietf.org/iet= f/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-mukundan-sipping-dpnss-01.txt".
>
> NOTE: The mail server at ietf.org can return the document in
>       MIME-encoded form by using the = "mpack" utility.  To use this
>       feature, insert the command = "ENCODING mime" before the "FILE"
>       command.  To decode the = response(s), you will need "munpack" or
>       a MIME-compliant mail reader.  = Different MIME-compliant mail readers
>       exhibit different behavior, = especially when dealing with
>       "multipart" MIME messages = (i.e. documents which have been split
>       up into multiple messages), so check = your local documentation on
>       how to manipulate these = messages.
>
>
> Below is the data which will enable a MIME compliant mail = reader
> implementation to automatically retrieve the ASCII version of = the
> Internet-Draft.
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf= .org/mailman/listinfo/sipping
> This list is for NEW development of the 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 mailnull@www1.ietf.org Fri Feb 7 14:49:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19508 for ; Fri, 7 Feb 2003 14:49:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17JuFx25955 for sipping-archive@odin.ietf.org; Fri, 7 Feb 2003 14:56:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17JuFp25952 for ; Fri, 7 Feb 2003 14:56:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19486 for ; Fri, 7 Feb 2003 14:48:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17Jtbp25888; Fri, 7 Feb 2003 14:55:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17Jsfp25850 for ; Fri, 7 Feb 2003 14:54:41 -0500 Received: from pope.teraglobal.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19451 for ; Fri, 7 Feb 2003 14:47:05 -0500 (EST) Received: from WXPWHEGDE ([66.192.6.37]) by pope.teraglobal.com (Netscape Messaging Server 4.15) with ESMTP id H9YFNX00.BSJ for ; Fri, 7 Feb 2003 12:02:21 -0800 From: "Veda Hegde" To: Date: Fri, 7 Feb 2003 11:50:32 -0800 Message-ID: <001201c2cee2$2f734750$2506c042@WXPWHEGDE> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C2CE9F.21500750" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: [Sipping] dynamic payload type Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C2CE9F.21500750 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi: Section 8.3.2 in RFC 3264 gives an example about the dynamic RTP map. ======================================================================== ================ However, in the case of RTP, the mapping from a particular dynamic payload type number to a particular codec within that media stream MUST NOT change for the duration of a session. For example, if A generates an offer with G.711 assigned to dynamic payload type number 46, payload type number 46 MUST refer to G.711 from that point forward in any offers or answers for that media stream within the session. However, it is acceptable for multiple payload type numbers to be mapped to the same codec, so that an updated offer could also use payload type number 72 for G.711. ======================================================================== ================= Is it allowed to use 46 for G.723 in the next m line? Thanks, Veda ------=_NextPart_000_0013_01C2CE9F.21500750 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:

Section 8.3.2 in RFC 3264 gives an example about the = dynamic RTP map.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

However, in the case of RTP, the mapping from =
a particular dynamic payload =
type
number to a particular =
codec within that media stream MUST NOT change for the =

duration of a =
session.  For example, if A =
generates an offer with G.711 assigned 
to =
dynamic payload type number 46, payload type number 46 MUST refer to =
G.711 from 
that =
point forward in any offers or answers for that media stream within the =
session.  =

However, =
it is acceptable for multiple payload type numbers to be mapped to the =
same
codec, so that an =
updated offer could also use payload type number 72 for =
G.711.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

 

Is it allowed to use 46 for G.723 in the next m line? =  

 

Thanks,
Veda

 

 

------=_NextPart_000_0013_01C2CE9F.21500750-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Feb 10 01:10:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16471 for ; Mon, 10 Feb 2003 01:10:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1A6ILw13040 for sipping-archive@odin.ietf.org; Mon, 10 Feb 2003 01:18:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1A6ILp13037 for ; Mon, 10 Feb 2003 01:18:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16459 for ; Mon, 10 Feb 2003 01:09:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1A6HWp13018; Mon, 10 Feb 2003 01:17:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1A6Fnp12960 for ; Mon, 10 Feb 2003 01:15:49 -0500 Received: from zoe.office.snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16434 for ; Mon, 10 Feb 2003 01:07:02 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [sipping] draft-burger-sipping-netann-03.txt (Early media announcement) Date: Mon, 10 Feb 2003 01:10:51 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D24876E@zoe.office.snowshore.com> Thread-Topic: [sipping] draft-burger-sipping-netann-03.txt (Early media announcement) Thread-Index: AcLLn9NPTQVIgkqTT/+LT3TQ3hOD6AE+wdoQ From: "Eric Burger" To: Cc: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1A6Fop12961 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit The idea of an early media announcement is that there is an implicit CANCEL. That reasoning still holds for RFC 3261. Do you have a better thought for a more appropriate result code? In the case of the soft phone you mention, I would offer the soft phone is not compliant with RFC 3261. It should tear down the dialog on any 4xx response. > -----Original Message----- > From: Pascal.Jalet@alcatel.fr [mailto:Pascal.Jalet@alcatel.fr] > Sent: Monday, February 03, 2003 11:18 AM > To: Eric Burger > Cc: David.Rio@alcatel.fr; sipping@ietf.org > Subject: [sipping] draft-burger-sipping-netann-03.txt (Early media > announcement) > > > > Eric, > In early media announcement scenario, you suggest to send a > 487 REQUEST > TERMINATED, once the anouncement is played. > But in RFC 3261, the 487 response is said to be used only > when the previous > request has been terminated with a BYE or a CANCEL. > It is not the case in early media announcement scenario. > So my question is ca:n we consider that the early media annoucement > scenario is compliant with RFC 3261? > > We've faced a case in which a softphone refuses to close a > call (screen > still active) because it has received a 487 without any previous > BYE or CANCEL. Is this terminal not compliant with > RFC3261?(below is the > call flow of the call) > > > > Softphone PROXY (SER) MS > INVITE ----------> --------------> > <----------------- ---------------183 > PLAY of 10 s > <------------------ ---------------487 > ACK---------------> ----------------> > > After the ACK is sent, the call is still active. > > > > pascal > > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Feb 10 03:16:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29688 for ; Mon, 10 Feb 2003 03:16:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1A8Osc30611 for sipping-archive@odin.ietf.org; Mon, 10 Feb 2003 03:24:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1A8Orp30608 for ; Mon, 10 Feb 2003 03:24:53 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29675 for ; Mon, 10 Feb 2003 03:16:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1A8OQp30593; Mon, 10 Feb 2003 03:24:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1A8MWp30366 for ; Mon, 10 Feb 2003 03:22:32 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29560 for ; Mon, 10 Feb 2003 03:13:43 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1A8HHAv011623; Mon, 10 Feb 2003 09:17:17 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id DW01BR6Q; Mon, 10 Feb 2003 09:17:16 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h1A8HGH7017961; Mon, 10 Feb 2003 10:17:16 +0200 (EET) Message-ID: <3E47600B.1FA20A58@lmf.ericsson.se> Date: Mon, 10 Feb 2003 10:17:15 +0200 X-Sybari-Trust: b1cea391 9ffcebbb 7a95d2f4 00000138 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sipping CC: Dean Willis , Rohan Mahy , kns10@cs.columbia.edu, Henning Schulzrinne , alan.johnston@wcom.com, rrroy@att.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] SIP-H.323 design team Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, The requirements document for SIP-H.323 interworking is advancing: http://www.ietf.org/internet-drafts/draft-agrawal-sip-h323-interworking-reqs-03.txt Now, it is time to start thinking about the solution document. If there are enough people willing to contribute, we intend to form a design team in SIPPING. The scope of the work will be most likely limited to basic call set-up. Those of you who are interested in being part of such a design team, please let me know. Thanks, Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Feb 10 05:38:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03594 for ; Mon, 10 Feb 2003 05:38:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1AAlBH06335 for sipping-archive@odin.ietf.org; Mon, 10 Feb 2003 05:47:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AAlBp06332 for ; Mon, 10 Feb 2003 05:47:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03573 for ; Mon, 10 Feb 2003 05:38:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AAkYp06293; Mon, 10 Feb 2003 05:46:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AAjBp06240 for ; Mon, 10 Feb 2003 05:45:11 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03509 for ; Mon, 10 Feb 2003 05:36:17 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1AAdwKV004786; Mon, 10 Feb 2003 11:39:58 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id DY54MK2J; Mon, 10 Feb 2003 11:39:57 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h1AAdvmT027139; Mon, 10 Feb 2003 12:39:57 +0200 (EET) Message-ID: <3E47817C.1E4F2B89@lmf.ericsson.se> Date: Mon, 10 Feb 2003 12:39:56 +0200 X-Sybari-Trust: 48bc1324 9ffcebbb 7a95d2f4 00000138 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sipping CC: Dean Willis , Rohan Mahy , Eric Burger Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Expert review for draft-burger-sipping-netann-04.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, We would like the SIPPING working group to provide expert review of: http://www.ietf.org/internet-drafts/draft-burger-sipping-netann-04.txt The authors have requested individual publication of this document. Expert Review will close on March 10th, 2003 Thanks, Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Feb 10 06:39:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04810 for ; Mon, 10 Feb 2003 06:39:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1ABm4A09484 for sipping-archive@odin.ietf.org; Mon, 10 Feb 2003 06:48:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ABm4p09481 for ; Mon, 10 Feb 2003 06:48:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04805 for ; Mon, 10 Feb 2003 06:39:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ABlWp09465; Mon, 10 Feb 2003 06:47:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ABkbp09416 for ; Mon, 10 Feb 2003 06:46:37 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04784 for ; Mon, 10 Feb 2003 06:37:42 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1ABfOKV023233 for ; Mon, 10 Feb 2003 12:41:24 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id DW01DRDT; Mon, 10 Feb 2003 12:41:24 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h1ABfOmT001323 for ; Mon, 10 Feb 2003 13:41:24 +0200 (EET) Message-ID: <3E478FE2.4EC184AE@lmf.ericsson.se> Date: Mon, 10 Feb 2003 13:41:22 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sipping Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] New version of the early media 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, I have just sumitted a new version of the early media draft. Until it appears in the archives, you can fetch it from: http://standards.ericsson.net/gonzalo/papers/draft-camarillo-sipping-early-media-01.txt I have included all the (long and useful) discussions we had in the mailing list. Therefore, the draft now keeps separate the "gateway" and the "application server" models. I have also removed the parts we did not agree on. Feedback is, as usual, appreciated. Thanks, Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Feb 10 06:45:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05026 for ; Mon, 10 Feb 2003 06:45:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1ABrbO09656 for sipping-archive@odin.ietf.org; Mon, 10 Feb 2003 06:53:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ABrbp09653 for ; Mon, 10 Feb 2003 06:53:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04929 for ; Mon, 10 Feb 2003 06:44:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ABr4p09620; Mon, 10 Feb 2003 06:53:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ABq5p09588 for ; Mon, 10 Feb 2003 06:52:05 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04908 for ; Mon, 10 Feb 2003 06:43:10 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1ABkqKV025892; Mon, 10 Feb 2003 12:46:53 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id DW01DTBJ; Mon, 10 Feb 2003 12:46:52 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h1ABkqmT001688; Mon, 10 Feb 2003 13:46:52 +0200 (EET) Message-ID: <3E47912B.CE58BFB5@lmf.ericsson.se> Date: Mon, 10 Feb 2003 13:46:51 +0200 X-Sybari-Trust: 97c708ba 9ffcebbb 7a95d2f4 00000138 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sipping CC: John Loughney Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] New version of the SIP-AAA reqs 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, we have released a new version of the SIP-AAA requirements draft. Based on the feedback we have received, it seems that the draft now includes all the requirements people had in mind. (Although further comments are, of course, always welcome). We will now try to get the work on the diameter-based solution going. Regards, Gonzalo -------- Original Message -------- Subject: [Sipping] I-D ACTION:draft-ietf-sipping-aaa-req-02.txt,.pdf Date: Thu, 06 Feb 2003 09:30:09 -0500 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; CC: sipping@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : Authentication, Authorization and Accounting Requirements for the Session Initiation Protocol Author(s) : J. Loughney, G. Camarillo Filename : draft-ietf-sipping-aaa-req-02.txt,.pdf Pages : 14 Date : 2003-2-5 As SIP services are deployed on the Internet, there is a need for authentication, authorization and accounting of SIP sessions. This document sets out the basic requirements for this work. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-aaa-req-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sipping-aaa-req-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sipping-aaa-req-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-5140318.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-aaa-req-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-aaa-req-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" --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 mailnull@www1.ietf.org Mon Feb 10 07:50:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07419 for ; Mon, 10 Feb 2003 07:50:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1ACx5D13182 for sipping-archive@odin.ietf.org; Mon, 10 Feb 2003 07:59:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ACx5p13179 for ; Mon, 10 Feb 2003 07:59:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07402 for ; Mon, 10 Feb 2003 07:50:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ACwUp13144; Mon, 10 Feb 2003 07:58:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ACvmp13102 for ; Mon, 10 Feb 2003 07:57:48 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07302 for ; Mon, 10 Feb 2003 07:48:54 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1ACqWAv005205; Mon, 10 Feb 2003 13:52:32 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id D7MWSXS5; Mon, 10 Feb 2003 13:52:31 +0100 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.137]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h1ACqVmT005924; Mon, 10 Feb 2003 14:52:31 +0200 (EET) Message-ID: <3E47A08F.8923CB7B@lmf.ericsson.se> Date: Mon, 10 Feb 2003 14:52:31 +0200 X-Sybari-Trust: 303142a0 9ffcebbb 7a95d2f4 00000138 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: sipping , Dean Willis , Rohan Mahy , Eric Burger Subject: Re: [Sipping] Expert review for draft-burger-sipping-netann-04.txt References: <3E47817C.1E4F2B89@lmf.ericsson.se> 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Some after-having-a-first-look-at-the-draft comments. 1. The 487 Request Terminated response code is used after the announcement has been played. There is already a discussion about this on the list, but I also think it is an issue. I don't know which code would be better to use, but RFC3261 does say that 487 is sent only when the request has been terminated by CANCEL, and I am not sure I agree on the "implicit CANCEL" thing... So, I think we should use another code. Either we come up with a new one, or we use whatever existing (does it really matter that much which code we use?). 2. Chapter 3 says that 183, with SDP shall be sent, to enable early media. I think it shall be said that 183 must be sent RELIABLE (using 100rel), if the SDP is to provide some functionality. 3. I don't like the "early" URI parameter. We should have a GENERIC early media mechanism for SIP, and not come up with solutions for specific applications. Also, the UAC may not even know it will contact a media server. It may send a "normal" SIP-URI, which is converted by a proxy into a ANNC-URL. How does the proxy know if the UAC support early media or not? Regards, Christer Holmberg Ericsson Finland Gonzalo Camarillo wrote: > Folks, > > We would like the SIPPING working group to provide expert review of: > > http://www.ietf.org/internet-drafts/draft-burger-sipping-netann-04.txt > > The authors have requested individual publication of this document. > Expert Review will close on March 10th, 2003 > > Thanks, > > Gonzalo > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Feb 10 09:48:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10873 for ; Mon, 10 Feb 2003 09:48:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1AEuxh19984 for sipping-archive@odin.ietf.org; Mon, 10 Feb 2003 09:56:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AEuwp19981 for ; Mon, 10 Feb 2003 09:56:58 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10868 for ; Mon, 10 Feb 2003 09:48:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AEuPp19927; Mon, 10 Feb 2003 09:56:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AEt5p19873 for ; Mon, 10 Feb 2003 09:55:05 -0500 Received: from kcmso2.proxy.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10814 for ; Mon, 10 Feb 2003 09:46:08 -0500 (EST) Received: from attrh0i.attrh.att.com ([135.37.94.54]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h1ADtXcJ017060 for ; Mon, 10 Feb 2003 08:49:49 -0600 (CST) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh0i.attrh.att.com (6.5.019) id 3E39EBFA0088CB1E; Mon, 10 Feb 2003 09:49:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 10 Feb 2003 09:49:08 -0500 Message-ID: <62DA45D4963FA747BA1B253E266760F905A6E368@OCCLUST04EVS1.ugd.att.com> Thread-Topic: SIP-H.323 design team Thread-Index: AcLQ3NhNDD07SrApR8+7BDBmWH+B3wANYJTg From: "Roy, Radhika R, ALABS" To: "Gonzalo Camarillo" , "sipping" Cc: "Dean Willis" , "Rohan Mahy" , , "Henning Schulzrinne" , , "Roy, Radhika R, ALABS" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1AEt5p19874 Subject: [Sipping] RE: SIP-H.323 design team Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Gonzalo: The design team of H.323-SIP Interworking has also the same members like that of the requirements teams. We have provided the first draft long time ago last year and was reviewed in the SIP-H.323 mailing list (later on SIP Implementer's list). We are also working for the second draft. At this point, I would also suggest, like requirements document, let Henning Schulzrinne should be the lead editor for the SIP-H.323 interworking standard. I have the draft copy of the second draft of the SIP-H.323 Interworking draft. I will send to all design team members so that Henning can start editing the document. Best regards, Radhika R. Roy rrroy@att.com On behalf of the SIP-H.323 Design Team -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: Monday, February 10, 2003 3:17 AM To: sipping Cc: Dean Willis; Rohan Mahy; kns10@cs.columbia.edu; Henning Schulzrinne; alan.johnston@wcom.com; Roy, Radhika R, ALABS Subject: SIP-H.323 design team Folks, The requirements document for SIP-H.323 interworking is advancing: http://www.ietf.org/internet-drafts/draft-agrawal-sip-h323-interworking- reqs-03.txt Now, it is time to start thinking about the solution document. If there are enough people willing to contribute, we intend to form a design team in SIPPING. The scope of the work will be most likely limited to basic call set-up. Those of you who are interested in being part of such a design team, please let me know. Thanks, Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Feb 10 21:19:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05041 for ; Mon, 10 Feb 2003 21:19:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1B2RlH32207 for sipping-archive@odin.ietf.org; Mon, 10 Feb 2003 21:27:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B2Rlp32204 for ; Mon, 10 Feb 2003 21:27:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05025 for ; Mon, 10 Feb 2003 21:18:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B2R6p32191; Mon, 10 Feb 2003 21:27:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B2P2p32141 for ; Mon, 10 Feb 2003 21:25:02 -0500 Received: from dgesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04988 for ; Mon, 10 Feb 2003 21:15:51 -0500 (EST) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0HA400CI7H4L88@firewall.wcom.com> for sipping@ietf.org; Tue, 11 Feb 2003 02:19:33 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HA400K01H4LXH@dgismtp02.wcomnet.com>; Tue, 11 Feb 2003 02:19:33 +0000 (GMT) Received: from hsinnreich2 ([166.50.128.53]) by dgismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HA400J9QH4I1G@dgismtp02.wcomnet.com>; Tue, 11 Feb 2003 02:19:33 +0000 (GMT) Date: Mon, 10 Feb 2003 20:19:29 -0600 From: Henry Sinnreich Subject: RE: [Sipping] New version of the SIP-AAA reqs draft In-reply-to: <3E47912B.CE58BFB5@lmf.ericsson.se> To: "'Gonzalo Camarillo'" , "'sipping'" Cc: "'John Loughney'" Message-id: <001201c2d174$03ac7300$358032a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > We will now try to get the work on the diameter-based solution going. As has been mentioned here, 99.999% (five nines :-0>) of existing implementations and deployment are RADIUS. After RADIUS come the web services. I suggest therefore to start with RADIUS instead. Thanks, Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of Gonzalo Camarillo > Sent: Monday, February 10, 2003 5:47 AM > To: sipping > Cc: John Loughney > Subject: [Sipping] New version of the SIP-AAA reqs draft > > > Hi, > > we have released a new version of the SIP-AAA requirements > draft. Based on the feedback we have received, it seems that > the draft now includes all the requirements people had in > mind. (Although further comments are, of course, always welcome). > > We will now try to get the work on the diameter-based solution going. > > Regards, > > Gonzalo > > > > -------- Original Message -------- > Subject: [Sipping] I-D ACTION:draft-ietf-sipping-aaa-req-02.txt,.pdf > Date: Thu, 06 Feb 2003 09:30:09 -0500 > From: Internet-Drafts@ietf.org > Reply-To: Internet-Drafts@ietf.org > To: IETF-Announce: ; > CC: sipping@ietf.org > > --NextPart > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. This draft is a work item of the > Session Initiation Proposal Investigation Working Group of the IETF. > > Title : Authentication, Authorization and > Accounting Requirements > for the Session Initiation Protocol > Author(s) : J. Loughney, G. Camarillo > Filename : draft-ietf-sipping-aaa-req-02.txt,.pdf > Pages : 14 > Date : 2003-2-5 > > As SIP services are deployed on the Internet, there is a need > for authentication, authorization and accounting of SIP > sessions. This document sets out the basic requirements for this work. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipping-aaa-req-02.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body > of the message. > > Internet-Drafts are also available by anonymous FTP. Login > with the username "anonymous" and a password of your e-mail > address. After logging in, type "cd internet-drafts" and then > "get draft-ietf-sipping-aaa-req-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sipping-aaa-req-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail > reader implementation to automatically retrieve the ASCII > version of the Internet-Draft. > > > --NextPart > Content-Type: Multipart/Alternative; Boundary="OtherAccess" > > --OtherAccess > Content-Type: Message/External-body; > access-type="mail-server"; > server="mailserv@ietf.org" > > Content-Type: text/plain > Content-ID: <2003-2-5140318.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-ietf-sipping-aaa-req-02.txt > > --OtherAccess > Content-Type: Message/External-body; > name="draft-ietf-sipping-aaa-req-02.txt"; > site="ftp.ietf.org"; > access-type="anon-ftp"; > directory="internet-drafts" > > > --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 > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Feb 11 03:58:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23992 for ; Tue, 11 Feb 2003 03:58:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1B973n30653 for sipping-archive@odin.ietf.org; Tue, 11 Feb 2003 04:07:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B973p30649 for ; Tue, 11 Feb 2003 04:07:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23978 for ; Tue, 11 Feb 2003 03:57:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B961p30526; Tue, 11 Feb 2003 04:06:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B94op30486 for ; Tue, 11 Feb 2003 04:04:50 -0500 Received: from wiprom2mx1.wipro.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23940 for ; Tue, 11 Feb 2003 03:55:28 -0500 (EST) Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id h1B8x7v06105 for ; Tue, 11 Feb 2003 14:29:07 +0530 (IST) Received: from blr-ec-msg01.wipro.com ([10.200.50.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 11 Feb 2003 14:29:02 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Feb 2003 14:29:02 +0530 Message-ID: <5CD22C179E0D7C49954F3ACCA07E4EDE09D1A8@blr-ec-msg01.wipro.com> Thread-Topic: RE: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-01.txt Thread-Index: AcLO2Ewlfk1DMQpRRI+Z7cQYL+7aUgC0ggTa From: "Ranjith Mukundan" To: X-OriginalArrivalTime: 11 Feb 2003 08:59:02.0537 (UTC) FILETIME=[D2C27F90:01C2D1AB] Content-Transfer-Encoding: quoted-printable Subject: [Sipping] QSIG Vs DPNSS MIME Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable QSIG Vs DPNSS MIME

we'd appreciate some views on this draft from atleast = those who fairly understand QSIG.

of course, others who feel that this MIME type collides directly with = the purpose of SIP are encouraged to provide alternatives bearing in = mind that providing complete end-to-end service transparency over the = intervening SIP based core would be essential, if we are to provide a = seamless migration path from H.323 based core networks - which already = provide equivalent mechanisms for DSS1 based protocols.

- ranjith..


-----Original Message-----
From:   Ranjith Mukundan
Sent:   Sat 2/8/2003 12:09 AM
To:     sipping@ietf.org
Cc:    
Subject:        RE: [Sipping] I-D = ACTION:draft-mukundan-sipping-dpnss-01.txt

Hi,

posting WRT http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-= 01.txt


>>
>> Why is it so important to be able to tunnel DPNSS in SIP?  = I'd prefer
>> that folks implement a translation to SIP, where SIP can = natively carry
>> all the information that DPNSS is trying to convey.
>>

To put things in perspective:

1- DPNSS is a protocol (deployed primarily in UK, NZ, Australia and = parts of NA) very similar to QSIG (deployed primarily Europe) for = interconnecting PBXs or centrex customers hosted off LEs. DPNSS (like = QSIG) finds enormous application towards realizing a local VPN or = network-wide VPN services.

2- This draft aims to do exactly what RFC 3204 (MIME objects for = QSIG/ISUP) does for QSIG with appropriate/relevant customization for = DPNSS - i.e., to provide end-to-end & *complete*, DPNSS Service = transparency between pockets of DPNSS based private networks over a SIP = based core.

3- Currently, circuit-switched SS7 based cores, provide equivalent DPNSS = tunneling mechanisms through (ETSI & ANSI) ISUP *apart from* the = concomitant translation/interworking mechanisms to ISUP. The = translation/interworking mechanism to ISUP is limited to the basic call = and certain ISUP supplementary services where there is a direct/easy = equivalent.

4- H.323 also provides equivalent tunneling mechanisms (via the H.450 = Annexe procedures) for transparently carrying DSS1 based signaling = between DSS1-based network elements/gateways, over a H.323 core.

Some specifics:

1- DPNSS supports, as specified in BTNR 188, approximately 240+ = supplementary features/services (like Call Back When Free, Call Back = When Next Used, Executive Intrusion, Travelling Class of Service, Do Not = Disturb, Night Service, Private Network Route Optimization, Centralized = Operator, Three Party Takeover, Remote Diversion Registration etc). It = would be almost impossible to interwork to equivalent mechanisms in SIP, = without losing the service transparency when using an intervening SIP = based core.

2- Yes, we definitely need an interworking/translation mechanism to map = all the basic call/service paremeters, and procedures for mapping the = messages. But this does not preclude the need for a DPNSS MIME type, but = would rather be complimentary to the MIME type mechanism. Similar to http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-00= .txt , for QSIG, we are in the process of putting together an = interworking draft for DPNSS as well - but rather than making it DPNSS = specific, we are trying to make it a common draft to cover PRI, DPNSS = & DASS2 [as Q.SIG interworking is already a SIPPING WG ID]. Note = that, PRI and DASS2 will not need a MIME type as these are, as one might = be aware, for PSTN access, unlike DPNSS and QSIG (which are private = network protocols).

3- From the SIP perspective, carrying non-SIP applications as MIME = objects to ensure end to end service transparency is architecturally = less appalling than, say for e.g., tunneling DSS1 protocols in H.323 = based network - so the SIP DPNSS MIME proposition as per this I-D is the = obvious way forward for DPNSS service transparency over a SIP based = core, especially now that we see acute deployment needs to be met.

cheers,
ranjith..

> -----Original Message-----
> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]= On Behalf
> Of
> Ranjith Mukundan
> Sent: Tuesday, February 04, 2003 5:32 PM
> To: sipping@ietf.org
> Subject: RE: [Sipping] I-D = ACTION:draft-mukundan-sipping-dpnss-01.txt
>
>
> Hi List,
> We would like you take a look at this draft and revert with any
> comments/queries that you might have.
>
> SIPPING Chairs,
> The authors feel that the requirement and the need for this MIME = type
> is
> quite acute. Hence we'd like you to consider this for inclusion as = a
> WG I-D
> and suggest the way forward.
>
> - ranjith..
>
> -----Original Message-----
> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]= On Behalf
> Of
> Internet-Drafts@ietf.org
> Sent: Tuesday, February 04, 2003 5:14 PM
> To: IETF-Announce:
> Cc: sipping@ietf.org
> Subject: [Sipping] I-D = ACTION:draft-mukundan-sipping-dpnss-01.txt
>
>
> A New Internet-Draft is available from the on-line = Internet-Drafts
> directories.
>
>
>       Title   =         : MIME media types for DPNSS = Objects
>       = Author(s)       : R. Mukundan et al.
>       = Filename        : = draft-mukundan-sipping-dpnss-01.txt
>       Pages   =         : 9
>       Date    =         : 2003-2-3
>
> This document describes Multipart Internet Mail Extensions (MIME) = type
> for application/Digital Private Network Signaling System = (DPNSS)
> objects for use in Session Initiation Protocol (SIP) = applications,
> according to the rules defined in RFC 2048. These types can be used = to
> identify Digital Private Network Signaling System 1 (DPNSS 1) = objects
> within a SIP message such as INVITE or INFO, as might be = implemented
> when using SIP in an environment where part of the call = involves
> interworking to DPNSS 1 based Private Networks. RFC 3204 addresses = a
> similar need for Integrated Service Digital Network User Part = (ISUP)
> and Q Signaling (QSIG).
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-0= 1.tx
> t
>
> To remove yourself from the IETF Announcement list, send a message = to
> ietf-announce-request with the word unsubscribe in the body of = the
> message.
>
> Internet-Drafts are also available by anonymous FTP. Login with = the
> username
> "anonymous" and a password of your e-mail address. After = logging in,
> type "cd internet-drafts" and then
>       "get = draft-mukundan-sipping-dpnss-01.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html<= /A> or
> ftp://ftp.ietf.org/iet= f/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-mukundan-sipping-dpnss-01.txt".
>
> NOTE: The mail server at ietf.org can return the document in
>       MIME-encoded form by using the = "mpack" utility.  To use this
>       feature, insert the command = "ENCODING mime" before the "FILE"
>       command.  To decode the = response(s), you will need "munpack" or
>       a MIME-compliant mail reader.  = Different MIME-compliant mail readers
>       exhibit different behavior, = especially when dealing with
>       "multipart" MIME messages = (i.e. documents which have been split
>       up into multiple messages), so check = your local documentation on
>       how to manipulate these = messages.
>
>
> Below is the data which will enable a MIME compliant mail = reader
> implementation to automatically retrieve the ASCII version of = the
> Internet-Draft.
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf= .org/mailman/listinfo/sipping
> This list is for NEW development of the 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 mailnull@www1.ietf.org Tue Feb 11 06:54:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29097 for ; Tue, 11 Feb 2003 06:54:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BC2ru08083 for sipping-archive@odin.ietf.org; Tue, 11 Feb 2003 07:02:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BC2rp08080 for ; Tue, 11 Feb 2003 07:02:53 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29057 for ; Tue, 11 Feb 2003 06:53:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BC24p08048; Tue, 11 Feb 2003 07:02:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BBs7p07750 for ; Tue, 11 Feb 2003 06:54:07 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28366; Tue, 11 Feb 2003 06:44:44 -0500 (EST) Message-Id: <200302111144.GAA28366@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 11 Feb 2003 06:44:44 -0500 Subject: [Sipping] I-D ACTION:draft-camarillo-sipping-early-media-01.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Early Media and Ringback Tone Generation in the Session Initiation Protocol Author(s) : G. Camarillo, H. Schulzrinne Filename : draft-camarillo-sipping-early-media-01.txt Pages : 10 Date : 2003-2-10 This document describes how to manage early media in SIP using two models; the gateway model and the application server model. It also describes which inputs need to be taken into consideration to define local policies for ringback tone generation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-camarillo-sipping-early-media-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-camarillo-sipping-early-media-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-camarillo-sipping-early-media-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-10132756.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-camarillo-sipping-early-media-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-camarillo-sipping-early-media-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-10132756.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Feb 11 09:57:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07133 for ; Tue, 11 Feb 2003 09:57:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BF6om20221 for sipping-archive@odin.ietf.org; Tue, 11 Feb 2003 10:06:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BF6op20218 for ; Tue, 11 Feb 2003 10:06:50 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07125 for ; Tue, 11 Feb 2003 09:57:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BF66p20194; Tue, 11 Feb 2003 10:06:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BF49p20125 for ; Tue, 11 Feb 2003 10:04:09 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07053 for ; Tue, 11 Feb 2003 09:54:42 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1BEvG201420 for ; Tue, 11 Feb 2003 16:57:16 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Feb 2003 16:58:23 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 11 Feb 2003 16:58:22 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 11 Feb 2003 16:58:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] New version of the SIP-AAA reqs draft Date: Tue, 11 Feb 2003 16:58:21 +0200 Message-ID: Thread-Topic: [Sipping] New version of the SIP-AAA reqs draft Thread-Index: AcLRdAibRKsknkqCSbqbOlxaxkUMkwAaY2hQ To: , , X-OriginalArrivalTime: 11 Feb 2003 14:58:22.0166 (UTC) FILETIME=[054CCF60:01C2D1DE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1BF49p20127 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Henry, > > We will now try to get the work on the diameter-based > solution going. > > As has been mentioned here, 99.999% (five nines :-0>) of existing > implementations and deployment are RADIUS. After RADIUS come the web > services. > > I suggest therefore to start with RADIUS instead. RADIUS is extremely limited in a number of cases - security, transport issues, reliability and is most likely illegal in many jurisdictions for use with token-based accounting (due to the non-reliable nature of RADIUS). What I think you are more concerned for the solution to work with RADIUS, correct? It may be pre-mature to discuss solutions, but one option is develop a solution using Diameter in RADIUS-compatibility mode. The alert reader then may be able to determine how to use RADIUS in such circumstances. However, it is unlikely that the IESG will approve using RADIUS for SIP-AAA needs because of the well-documented short comings of RADIUS. br, 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 mailnull@www1.ietf.org Tue Feb 11 12:31:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12486 for ; Tue, 11 Feb 2003 12:31:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BHe0c31390 for sipping-archive@odin.ietf.org; Tue, 11 Feb 2003 12:40:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BHe0p31387 for ; Tue, 11 Feb 2003 12:40:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12471 for ; Tue, 11 Feb 2003 12:30:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BHbRp31226; Tue, 11 Feb 2003 12:37:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BHaIp30489 for ; Tue, 11 Feb 2003 12:36:18 -0500 Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12246 for ; Tue, 11 Feb 2003 12:26:45 -0500 (EST) Received: from znsgy0k8.europe.nortel.com (europem01.nt.com [47.165.24.67]) by znsgs01r.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h1BHUPV23629 for ; Tue, 11 Feb 2003 17:30:26 GMT Received: from zwcwc012.europe.nortel.com ([47.160.46.124]) by znsgy0k8.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1NZ73Q43; Tue, 11 Feb 2003 17:30:25 -0000 Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1LVB512V>; Tue, 11 Feb 2003 17:29:15 -0000 Message-ID: X-Sybari-Space: 00000000 00000000 00000000 From: "Mark Watson" To: sipping@ietf.org Subject: RE: [Sipping] QSIG Vs DPNSS MIME Date: Tue, 11 Feb 2003 17:29:06 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D1F3.1418CB24" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2D1F3.1418CB24 Content-Type: text/plain; charset="iso-8859-1" All, I really can't see any difference between DPNSS and Q.SIG when it comes to the need for a MIME type for carriage of this within SIP. Can anyone come up with an argument for/against this draft which does not apply to Q.SIG just as well ? If not, then I certainly think this should be progressed. I have some comments on the draft: 1) DPNSS has now been published by the UK's Network Interoperability Consultative Committee as NICC Document 1301:2001/03. You can find it at http://www.oftel.gov.uk/ind_groups/nicc/Public/interconnectstandards/isc.htm along with lots of other gems. You should reference this version, rather than the somewhat harder to obtain BTNR. 2) Why do you need a length octet at the front of the message ? Can't you (or shouldn't you) put a Content-Length in the MIME headers for this MIME part ? 3) I think given the short length of the messages you could get away with mandating that segmented DPNSS messages should always be reassembled before encapsulating in SIP and that receivers must be able to receive such reassembled messages. This removes some unnecessary complexity. 4) Section 3, under table 1, you say 'Floating Point' when you mean 'Decimal'. I think the words 'contiguously increasing' could probably be removed here too. You will have trouble finding the next real number after 6.00! Regards...Mark -----Original Message----- From: Ranjith Mukundan [mailto:ranjith.mukundan@wipro.com] Sent: 11 February 2003 08:59 To: sipping@ietf.org Subject: [Sipping] QSIG Vs DPNSS MIME we'd appreciate some views on this draft from atleast those who fairly understand QSIG. of course, others who feel that this MIME type collides directly with the purpose of SIP are encouraged to provide alternatives bearing in mind that providing complete end-to-end service transparency over the intervening SIP based core would be essential, if we are to provide a seamless migration path from H.323 based core networks - which already provide equivalent mechanisms for DSS1 based protocols. - ranjith.. -----Original Message----- From: Ranjith Mukundan Sent: Sat 2/8/2003 12:09 AM To: sipping@ietf.org Cc: Subject: RE: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-01.txt Hi, posting WRT http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-01.txt >> >> Why is it so important to be able to tunnel DPNSS in SIP? I'd prefer >> that folks implement a translation to SIP, where SIP can natively carry >> all the information that DPNSS is trying to convey. >> To put things in perspective: 1- DPNSS is a protocol (deployed primarily in UK, NZ, Australia and parts of NA) very similar to QSIG (deployed primarily Europe) for interconnecting PBXs or centrex customers hosted off LEs. DPNSS (like QSIG) finds enormous application towards realizing a local VPN or network-wide VPN services. 2- This draft aims to do exactly what RFC 3204 (MIME objects for QSIG/ISUP) does for QSIG with appropriate/relevant customization for DPNSS - i.e., to provide end-to-end & *complete*, DPNSS Service transparency between pockets of DPNSS based private networks over a SIP based core. 3- Currently, circuit-switched SS7 based cores, provide equivalent DPNSS tunneling mechanisms through (ETSI & ANSI) ISUP *apart from* the concomitant translation/interworking mechanisms to ISUP. The translation/interworking mechanism to ISUP is limited to the basic call and certain ISUP supplementary services where there is a direct/easy equivalent. 4- H.323 also provides equivalent tunneling mechanisms (via the H.450 Annexe procedures) for transparently carrying DSS1 based signaling between DSS1-based network elements/gateways, over a H.323 core. Some specifics: 1- DPNSS supports, as specified in BTNR 188, approximately 240+ supplementary features/services (like Call Back When Free, Call Back When Next Used, Executive Intrusion, Travelling Class of Service, Do Not Disturb, Night Service, Private Network Route Optimization, Centralized Operator, Three Party Takeover, Remote Diversion Registration etc). It would be almost impossible to interwork to equivalent mechanisms in SIP, without losing the service transparency when using an intervening SIP based core. 2- Yes, we definitely need an interworking/translation mechanism to map all the basic call/service paremeters, and procedures for mapping the messages. But this does not preclude the need for a DPNSS MIME type, but would rather be complimentary to the MIME type mechanism. Similar to http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-00.txt , for QSIG, we are in the process of putting together an interworking draft for DPNSS as well - but rather than making it DPNSS specific, we are trying to make it a common draft to cover PRI, DPNSS & DASS2 [as Q.SIG interworking is already a SIPPING WG ID]. Note that, PRI and DASS2 will not need a MIME type as these are, as one might be aware, for PSTN access, unlike DPNSS and QSIG (which are private network protocols). 3- From the SIP perspective, carrying non-SIP applications as MIME objects to ensure end to end service transparency is architecturally less appalling than, say for e.g., tunneling DSS1 protocols in H.323 based network - so the SIP DPNSS MIME proposition as per this I-D is the obvious way forward for DPNSS service transparency over a SIP based core, especially now that we see acute deployment needs to be met. cheers, ranjith.. > -----Original Message----- > From: sipping-admin@ietf.org [ mailto:sipping-admin@ietf.org ]On Behalf > Of > Ranjith Mukundan > Sent: Tuesday, February 04, 2003 5:32 PM > To: sipping@ietf.org > Subject: RE: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-01.txt > > > Hi List, > We would like you take a look at this draft and revert with any > comments/queries that you might have. > > SIPPING Chairs, > The authors feel that the requirement and the need for this MIME type > is > quite acute. Hence we'd like you to consider this for inclusion as a > WG I-D > and suggest the way forward. > > - ranjith.. > > -----Original Message----- > From: sipping-admin@ietf.org [ mailto:sipping-admin@ietf.org ]On Behalf > Of > Internet-Drafts@ietf.org > Sent: Tuesday, February 04, 2003 5:14 PM > To: IETF-Announce: > Cc: sipping@ietf.org > Subject: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : MIME media types for DPNSS Objects > Author(s) : R. Mukundan et al. > Filename : draft-mukundan-sipping-dpnss-01.txt > Pages : 9 > Date : 2003-2-3 > > This document describes Multipart Internet Mail Extensions (MIME) type > for application/Digital Private Network Signaling System (DPNSS) > objects for use in Session Initiation Protocol (SIP) applications, > according to the rules defined in RFC 2048. These types can be used to > identify Digital Private Network Signaling System 1 (DPNSS 1) objects > within a SIP message such as INVITE or INFO, as might be implemented > when using SIP in an environment where part of the call involves > interworking to DPNSS 1 based Private Networks. RFC 3204 addresses a > similar need for Integrated Service Digital Network User Part (ISUP) > and Q Signaling (QSIG). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-01.tx > t > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-mukundan-sipping-dpnss-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-mukundan-sipping-dpnss-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 ------_=_NextPart_001_01C2D1F3.1418CB24 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable QSIG Vs DPNSS MIME
All,
 
I=20 really can't see any difference between DPNSS and Q.SIG when it comes = to the=20 need for a MIME type for carriage of this within SIP. Can anyone come = up with an=20 argument for/against this draft which does not apply to Q.SIG just as = well=20 ?
 
If=20 not, then I certainly think this should be = progressed.
 
I=20 have some comments on the draft:
1)=20 DPNSS has now been published by the UK's Network Interoperability = Consultative=20 Committee as NICC Document 1301:2001/03. You can find it at http://www.oftel.gov.uk/ind_groups/nicc/Public/interconnec= tstandards/isc.htm along=20 with lots of other gems.
 
You=20 should reference this version, rather than the somewhat harder to = obtain=20 BTNR.
 
2)=20 Why do you need a length octet at the front of the message ? Can't you = (or=20 shouldn't you) put a Content-Length in the MIME headers for this MIME = part=20 ?
3) I=20 think given the short length of the messages you could get away with = mandating=20 that segmented DPNSS messages should always be reassembled before = encapsulating=20 in SIP and that receivers must be able to receive such reassembled = messages.=20 This removes some unnecessary complexity.
4)=20 Section 3, under table 1, you say 'Floating Point' when you mean = 'Decimal'. I=20 think the words 'contiguously increasing' could probably be removed = here too.=20 You will have trouble finding the next real number after=20 6.00!
 
Regards...Mark
 
-----Original Message-----
From: Ranjith Mukundan=20 [mailto:ranjith.mukundan@wipro.com]
Sent: 11 February 2003=20 08:59
To: sipping@ietf.org
Subject: [Sipping] = QSIG Vs=20 DPNSS MIME

we'd appreciate some views on this draft from = atleast those=20 who fairly understand QSIG.

of course, others who feel that = this MIME=20 type collides directly with the purpose of SIP are encouraged to = provide=20 alternatives bearing in mind that providing complete end-to-end = service=20 transparency over the intervening SIP based core would be essential, = if we are=20 to provide a seamless migration path from H.323 based core networks - = which=20 already provide equivalent mechanisms for DSS1 based = protocols.

-=20 ranjith..


-----Original Message-----
From:   = Ranjith=20 Mukundan
Sent:   Sat 2/8/2003 12:09=20 AM
To:    =20 = sipping@ietf.org
Cc:    
Subject:  &= nbsp;    =20 RE: [Sipping] I-D=20 ACTION:draft-mukundan-sipping-dpnss-01.txt

Hi,

posting = WRT http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpns= s-01.txt


>>
>>=20 Why is it so important to be able to tunnel DPNSS in SIP?  I'd=20 prefer
>> that folks implement a translation to SIP, where = SIP can=20 natively carry
>> all the information that DPNSS is trying = to=20 convey.
>>

To put things in perspective:

1- = DPNSS is a=20 protocol (deployed primarily in UK, NZ, Australia and parts of NA) = very=20 similar to QSIG (deployed primarily Europe) for interconnecting PBXs = or=20 centrex customers hosted off LEs. DPNSS (like QSIG) finds enormous = application=20 towards realizing a local VPN or network-wide VPN services.

2- = This=20 draft aims to do exactly what RFC 3204 (MIME objects for QSIG/ISUP) = does for=20 QSIG with appropriate/relevant customization for DPNSS - i.e., to = provide=20 end-to-end & *complete*, DPNSS Service transparency between = pockets of=20 DPNSS based private networks over a SIP based core.

3- = Currently,=20 circuit-switched SS7 based cores, provide equivalent DPNSS tunneling=20 mechanisms through (ETSI & ANSI) ISUP *apart from* the = concomitant=20 translation/interworking mechanisms to ISUP. The = translation/interworking=20 mechanism to ISUP is limited to the basic call and certain ISUP = supplementary=20 services where there is a direct/easy equivalent.

4- H.323 = also=20 provides equivalent tunneling mechanisms (via the H.450 Annexe = procedures) for=20 transparently carrying DSS1 based signaling between DSS1-based = network=20 elements/gateways, over a H.323 core.

Some = specifics:

1- DPNSS=20 supports, as specified in BTNR 188, approximately 240+ supplementary=20 features/services (like Call Back When Free, Call Back When Next = Used,=20 Executive Intrusion, Travelling Class of Service, Do Not Disturb, = Night=20 Service, Private Network Route Optimization, Centralized Operator, = Three Party=20 Takeover, Remote Diversion Registration etc). It would be almost = impossible to=20 interwork to equivalent mechanisms in SIP, without losing the service = transparency when using an intervening SIP based core.

2- Yes, = we=20 definitely need an interworking/translation mechanism to map all the = basic=20 call/service paremeters, and procedures for mapping the messages. But = this=20 does not preclude the need for a DPNSS MIME type, but would rather be = complimentary to the MIME type mechanism. Similar to http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-= 00.txt=20 , for QSIG, we are in the process of putting together an interworking = draft=20 for DPNSS as well - but rather than making it DPNSS specific, we are = trying to=20 make it a common draft to cover PRI, DPNSS & DASS2 [as Q.SIG = interworking=20 is already a SIPPING WG ID]. Note that, PRI and DASS2 will not need a = MIME=20 type as these are, as one might be aware, for PSTN access, unlike = DPNSS and=20 QSIG (which are private network protocols).

3- From the SIP=20 perspective, carrying non-SIP applications as MIME objects to ensure = end to=20 end service transparency is architecturally less appalling than, say = for e.g.,=20 tunneling DSS1 protocols in H.323 based network - so the SIP DPNSS = MIME=20 proposition as per this I-D is the obvious way forward for DPNSS = service=20 transparency over a SIP based core, especially now that we see acute=20 deployment needs to be met.

cheers,
ranjith..

>=20 -----Original Message-----
> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org= ]On=20 Behalf
> Of
> Ranjith Mukundan
> Sent: Tuesday, = February 04,=20 2003 5:32 PM
> To: sipping@ietf.org
> Subject: RE: = [Sipping] I-D=20 ACTION:draft-mukundan-sipping-dpnss-01.txt
>
>
> Hi = List,
> We would like you take a look at this draft and revert = with=20 any
> comments/queries that you might have.
>
> = SIPPING=20 Chairs,
> The authors feel that the requirement and the need = for this=20 MIME type
> is
> quite acute. Hence we'd like you to = consider this=20 for inclusion as a
> WG I-D
> and suggest the way=20 forward.
>
> - ranjith..
>
> -----Original=20 Message-----
> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org= ]On=20 Behalf
> Of
> Internet-Drafts@ietf.org
> Sent: = Tuesday,=20 February 04, 2003 5:14 PM
> To: IETF-Announce:
> Cc:=20 sipping@ietf.org
> Subject: [Sipping] I-D=20 ACTION:draft-mukundan-sipping-dpnss-01.txt
>
>
> A = New=20 Internet-Draft is available from the on-line Internet-Drafts
>=20 directories.
>
>
>      =20 Title           : MIME = media=20 types for DPNSS Objects
>      =20 Author(s)       : R. Mukundan et = al.
>=20      =20 Filename        :=20 draft-mukundan-sipping-dpnss-01.txt
> =      =20 Pages           : = 9
>=20       Date   =20         : 2003-2-3
>
> = This=20 document describes Multipart Internet Mail Extensions (MIME) = type
> for=20 application/Digital Private Network Signaling System (DPNSS)
> = objects=20 for use in Session Initiation Protocol (SIP) applications,
> = according=20 to the rules defined in RFC 2048. These types can be used to
> = identify=20 Digital Private Network Signaling System 1 (DPNSS 1) objects
> = within a=20 SIP message such as INVITE or INFO, as might be implemented
> = when using=20 SIP in an environment where part of the call involves
> = interworking to=20 DPNSS 1 based Private Networks. RFC 3204 addresses a
> similar = need for=20 Integrated Service Digital Network User Part (ISUP)
> and Q = Signaling=20 (QSIG).
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss= -01.tx
>=20 t
>
> To remove yourself from the IETF Announcement list, = send a=20 message to
> ietf-announce-request with the word unsubscribe in = the body=20 of the
> message.
>
> Internet-Drafts are also = available by=20 anonymous FTP. Login with the
> username
> "anonymous" = and a=20 password of your e-mail address. After logging in,
> type "cd=20 internet-drafts" and then
>       "get = draft-mukundan-sipping-dpnss-01.txt".
>
> A list of=20 Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html= =20 or
> ftp://ftp.ietf.org/ie= tf/1shadow-sites.txt
>
>
>=20 Internet-Drafts can also be obtained by e-mail.
>
> Send = a message=20 to:
>       mailserv@ietf.org.
> = In the=20 body type:
>       "FILE=20 = /internet-drafts/draft-mukundan-sipping-dpnss-01.txt".
>
> = NOTE:=20 The mail server at ietf.org can return the document in
>=20       MIME-encoded form by using the "mpack" = utility.  To use this
>       = feature,=20 insert the command "ENCODING mime" before the "FILE"
>=20       command.  To decode the = response(s), you=20 will need "munpack" or
>       a = MIME-compliant=20 mail reader.  Different MIME-compliant mail readers
>=20       exhibit different behavior, especially = when=20 dealing with
>       "multipart" MIME = messages=20 (i.e. documents which have been split
> =      =20 up into multiple messages), so check your local documentation = on
>=20       how to manipulate these=20 messages.
>
>
> Below is the data which will enable = a MIME=20 compliant mail reader
> implementation to automatically = retrieve the=20 ASCII version of the
> Internet-Draft.
>
>=20 _______________________________________________
> Sipping = mailing=20 list  https://www1.iet= f.org/mailman/listinfo/sipping
>=20 This list is for NEW development of the application of SIP = Use
>=20 sip-implementors@cs.columbia.edu for questions on current sip = Use
>=20 sip@ietf.org for new developments of core=20 = SIP




______________________________________= _________=20 Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping = This list=20 is for NEW development of the application of SIP Use=20 sip-implementors@cs.columbia.edu for questions on current sip Use = sip@ietf.org=20 for new developments of core SIP ------_=_NextPart_001_01C2D1F3.1418CB24-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Feb 11 13:18:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13775 for ; Tue, 11 Feb 2003 13:18:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BIRFE01214 for sipping-archive@odin.ietf.org; Tue, 11 Feb 2003 13:27:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BIRFp01211 for ; Tue, 11 Feb 2003 13:27:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13766 for ; Tue, 11 Feb 2003 13:17:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BIQQp01162; Tue, 11 Feb 2003 13:26:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BIPVp01127 for ; Tue, 11 Feb 2003 13:25:31 -0500 Received: from wiprom2mx1.wipro.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13728 for ; Tue, 11 Feb 2003 13:15:55 -0500 (EST) Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id h1BIJav14053 for ; Tue, 11 Feb 2003 23:49:36 +0530 (IST) Received: from blr-ec-msg01.wipro.com ([10.200.50.99]) by blr-ec-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 11 Feb 2003 23:49:31 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] QSIG Vs DPNSS MIME Date: Tue, 11 Feb 2003 23:49:31 +0530 Message-ID: <5CD22C179E0D7C49954F3ACCA07E4EDE09D1AA@blr-ec-msg01.wipro.com> Thread-Topic: [Sipping] QSIG Vs DPNSS MIME Thread-Index: AcLR9NIWlLR46VHFQMODpUSSY4HpOwAAgSBp From: "Ranjith Mukundan" To: "Mark Watson" , X-OriginalArrivalTime: 11 Feb 2003 18:19:31.0392 (UTC) FILETIME=[1F1E8C00:01C2D1FA] 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: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable RE: [Sipping] QSIG Vs DPNSS MIME

Mark,

>> 2) Why do you need a length octet at the front of the message ? = Can't you
>> (or shouldn't you) put a Content-Length in the MIME headers for = this MIME
>> part ?

[ranjith]
The MIME Content-length is for the entire MIME object and represents the = cumulative lenght of the MIME content. There is no MIME length field = specifically for one of the many potential MIME objects that could have = been encapsulated. For e.g., in the examples illustrated in the draft, = the content length would be indicative of the SDP and the DPNSS PDU put = together. Given this, for implementation ease, the length field will be = highly desirable. We are also drawing upon our implementation experience = from an equivalent mechanism that is employed while carrying DPNSS in = ANSI ISUP - where, a length field is (logically) prepended along the = encapsulated DPNSS PDU.


>> 3) I think given the short length of the messages you could get = away with
>> mandating that segmented DPNSS messages should always be = reassembled before
>> encapsulating in SIP and that receivers must be able to receive = such
>> reassembled messages. This removes some unnecessary = complexity.

[ranjith]
The carriage of segmented DPNSS messages was retained, albeit leading to = inefficient network usage, as an *option* to primarily, accomodate = existing DPNSS layer 3 gateway implementations, where the DPNSS message = processing (either as transit or end-node function) is primarily based = on segmented DPNSS messages. Even in DPNSS - H.323 gateway = implementations that exist, segmented DPNSS messages are not = re-assembled. In order to keep the migration (towards SIP based core) = for the existing DPNSS gateway implementations seamless, it would indeed = be better to retain carriage of segmented DPNSS messages as an *option* = BUT *strongly recommend* to reassemble DPNSS messages before = encapsulation in SIP. We'll modify the text in the draft = accordingly.

cheers,
- ranjith..

-----Original Message-----
From:   Mark Watson [mailto:mwatson@nortelnetworks.= com]
Sent:   Tue 2/11/2003 10:59 PM
To:     sipping@ietf.org
Cc:    
Subject:        RE: [Sipping] QSIG Vs = DPNSS MIME
All,

I really can't see any difference between DPNSS and Q.SIG when it comes = to
the need for a MIME type for carriage of this within SIP. Can anyone = come up
with an argument for/against this draft which does not apply to Q.SIG = just
as well ?

If not, then I certainly think this should be progressed.

I have some comments on the draft:
1) DPNSS has now been published by the UK's Network Interoperability
Consultative Committee as NICC Document 1301:2001/03. You can find it = at
http://www.oftel.gov.uk/ind_groups/nicc/Public/interconnects= tandards/isc.htm
<http://www.oftel.gov.uk/ind_groups/nicc/Public/interconnectstandards/= isc.ht
m>  along with lots of other gems.

You should reference this version, rather than the somewhat harder to = obtain
BTNR.

2) Why do you need a length octet at the front of the message ? Can't = you
(or shouldn't you) put a Content-Length in the MIME headers for this = MIME
part ?
3) I think given the short length of the messages you could get away = with
mandating that segmented DPNSS messages should always be reassembled = before
encapsulating in SIP and that receivers must be able to receive such
reassembled messages. This removes some unnecessary complexity.
4) Section 3, under table 1, you say 'Floating Point' when you mean
'Decimal'. I think the words 'contiguously increasing' could probably = be
removed here too. You will have trouble finding the next real number = after
6.00!

Regards...Mark


-----Original Message-----
From: Ranjith Mukundan [mailto:ranjith.mukundan@wipro.= com]
Sent: 11 February 2003 08:59
To: sipping@ietf.org
Subject: [Sipping] QSIG Vs DPNSS MIME



we'd appreciate some views on this draft from atleast those who = fairly
understand QSIG.

of course, others who feel that this MIME type collides directly with = the
purpose of SIP are encouraged to provide alternatives bearing in mind = that
providing complete end-to-end service transparency over the intervening = SIP
based core would be essential, if we are to provide a seamless = migration
path from H.323 based core networks - which already provide = equivalent
mechanisms for DSS1 based protocols.

- ranjith..


-----Original Message-----
From:   Ranjith Mukundan
Sent:   Sat 2/8/2003 12:09 AM
To:     sipping@ietf.org
Cc:   
Subject:        RE: [Sipping] I-D = ACTION:draft-mukundan-sipping-dpnss-01.txt

Hi,

posting WRT
http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-= 01.txt
<http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-= 01.txt>


>>
>> Why is it so important to be able to tunnel DPNSS in SIP?  = I'd prefer
>> that folks implement a translation to SIP, where SIP can = natively carry
>> all the information that DPNSS is trying to convey.
>>

To put things in perspective:

1- DPNSS is a protocol (deployed primarily in UK, NZ, Australia and = parts of
NA) very similar to QSIG (deployed primarily Europe) for = interconnecting
PBXs or centrex customers hosted off LEs. DPNSS (like QSIG) finds = enormous
application towards realizing a local VPN or network-wide VPN = services.

2- This draft aims to do exactly what RFC 3204 (MIME objects for = QSIG/ISUP)
does for QSIG with appropriate/relevant customization for DPNSS - i.e., = to
provide end-to-end & *complete*, DPNSS Service transparency between = pockets
of DPNSS based private networks over a SIP based core.

3- Currently, circuit-switched SS7 based cores, provide equivalent = DPNSS
tunneling mechanisms through (ETSI & ANSI) ISUP *apart from* the = concomitant
translation/interworking mechanisms to ISUP. The = translation/interworking
mechanism to ISUP is limited to the basic call and certain ISUP
supplementary services where there is a direct/easy equivalent.

4- H.323 also provides equivalent tunneling mechanisms (via the H.450 = Annexe
procedures) for transparently carrying DSS1 based signaling between
DSS1-based network elements/gateways, over a H.323 core.

Some specifics:

1- DPNSS supports, as specified in BTNR 188, approximately 240+
supplementary features/services (like Call Back When Free, Call Back = When
Next Used, Executive Intrusion, Travelling Class of Service, Do Not = Disturb,
Night Service, Private Network Route Optimization, Centralized = Operator,
Three Party Takeover, Remote Diversion Registration etc). It would be = almost
impossible to interwork to equivalent mechanisms in SIP, without losing = the
service transparency when using an intervening SIP based core.

2- Yes, we definitely need an interworking/translation mechanism to map = all
the basic call/service paremeters, and procedures for mapping the = messages.
But this does not preclude the need for a DPNSS MIME type, but would = rather
be complimentary to the MIME type mechanism. Similar to
http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-00= .txt
<http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-00= .txt>  ,
for QSIG, we are in the process of putting together an interworking = draft
for DPNSS as well - but rather than making it DPNSS specific, we are = trying
to make it a common draft to cover PRI, DPNSS & DASS2 [as Q.SIG = interworking
is already a SIPPING WG ID]. Note that, PRI and DASS2 will not need a = MIME
type as these are, as one might be aware, for PSTN access, unlike DPNSS = and
QSIG (which are private network protocols).

3- From the SIP perspective, carrying non-SIP applications as MIME = objects
to ensure end to end service transparency is architecturally less = appalling
than, say for e.g., tunneling DSS1 protocols in H.323 based network - so = the
SIP DPNSS MIME proposition as per this I-D is the obvious way forward = for
DPNSS service transparency over a SIP based core, especially now that we = see
acute deployment needs to be met.

cheers,
ranjith..

> -----Original Message-----
> From: sipping-admin@ietf.org [ mailto:sipping-admin@ietf.org<= BR> <mailto:sipping-admin@ietf.org&= gt; ]On Behalf
> Of
> Ranjith Mukundan
> Sent: Tuesday, February 04, 2003 5:32 PM
> To: sipping@ietf.org
> Subject: RE: [Sipping] I-D = ACTION:draft-mukundan-sipping-dpnss-01.txt
>
>
> Hi List,
> We would like you take a look at this draft and revert with any
> comments/queries that you might have.
>
> SIPPING Chairs,
> The authors feel that the requirement and the need for this MIME = type
> is
> quite acute. Hence we'd like you to consider this for inclusion as = a
> WG I-D
> and suggest the way forward.
>
> - ranjith..
>
> -----Original Message-----
> From: sipping-admin@ietf.org [ mailto:sipping-admin@ietf.org<= BR> <mailto:sipping-admin@ietf.org&= gt; ]On Behalf
> Of
> Internet-Drafts@ietf.org
> Sent: Tuesday, February 04, 2003 5:14 PM
> To: IETF-Announce:
> Cc: sipping@ietf.org
> Subject: [Sipping] I-D = ACTION:draft-mukundan-sipping-dpnss-01.txt
>
>
> A New Internet-Draft is available from the on-line = Internet-Drafts
> directories.
>
>
>       = Title           : MIME = media types for DPNSS Objects
>       = Author(s)       : R. Mukundan et al.
>       = Filename        : = draft-mukundan-sipping-dpnss-01.txt
>       = Pages           : = 9
>       = Date            : = 2003-2-3
>
> This document describes Multipart Internet Mail Extensions (MIME) = type
> for application/Digital Private Network Signaling System = (DPNSS)
> objects for use in Session Initiation Protocol (SIP) = applications,
> according to the rules defined in RFC 2048. These types can be used = to
> identify Digital Private Network Signaling System 1 (DPNSS 1) = objects
> within a SIP message such as INVITE or INFO, as might be = implemented
> when using SIP in an environment where part of the call = involves
> interworking to DPNSS 1 based Private Networks. RFC 3204 addresses = a
> similar need for Integrated Service Digital Network User Part = (ISUP)
> and Q Signaling (QSIG).
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-0= 1.tx
<http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-0= 1.tx>
> t
>
> To remove yourself from the IETF Announcement list, send a message = to
> ietf-announce-request with the word unsubscribe in the body of = the
> message.
>
> Internet-Drafts are also available by anonymous FTP. Login with = the
> username
> "anonymous" and a password of your e-mail address. After = logging in,
> type "cd internet-drafts" and then
>       "get = draft-mukundan-sipping-dpnss-01.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html<= /A> <http://www.ietf.org/shadow.html<= /A>>  or
> ftp://ftp.ietf.org/iet= f/1shadow-sites.txt
<ftp://ftp.ietf.org/iet= f/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-mukundan-sipping-dpnss-01.txt".
>
> NOTE: The mail server at ietf.org can return the document in
>       MIME-encoded form by using the = "mpack" utility.  To use this
>       feature, insert the command = "ENCODING mime" before the "FILE"
>       command.  To decode the = response(s), you will need "munpack" or
>       a MIME-compliant mail = reader.  Different MIME-compliant mail readers
>       exhibit different behavior, = especially when dealing with
>       "multipart" MIME = messages (i.e. documents which have been split
>       up into multiple messages), so = check your local documentation on
>       how to manipulate these = messages.
>
>
> Below is the data which will enable a MIME compliant mail = reader
> implementation to automatically retrieve the ASCII version of = the
> Internet-Draft.
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf= .org/mailman/listinfo/sipping
<https://www1.ietf= .org/mailman/listinfo/sipping>
> This list is for NEW development of the 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 mailnull@www1.ietf.org Tue Feb 11 13:38:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14608 for ; Tue, 11 Feb 2003 13:38:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BIlOv02721 for sipping-archive@odin.ietf.org; Tue, 11 Feb 2003 13:47:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BIlOp02718 for ; Tue, 11 Feb 2003 13:47:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14583 for ; Tue, 11 Feb 2003 13:37:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BIkep02668; Tue, 11 Feb 2003 13:46:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BIj9p02594 for ; Tue, 11 Feb 2003 13:45:09 -0500 Received: from pmesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14532 for ; Tue, 11 Feb 2003 13:35:37 -0500 (EST) Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0HA500FLPQFK89@firewall.wcom.com> for sipping@ietf.org; Tue, 11 Feb 2003 18:38:08 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HA500L01QFJ5O@pmismtp02.wcomnet.com>; Tue, 11 Feb 2003 18:38:08 +0000 (GMT) Received: from hsinnreich2 ([166.42.32.104]) by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HA500KD3QFJUF@pmismtp02.wcomnet.com>; Tue, 11 Feb 2003 18:38:07 +0000 (GMT) Date: Tue, 11 Feb 2003 12:38:07 -0600 From: Henry Sinnreich Subject: RE: [Sipping] New version of the SIP-AAA reqs draft In-reply-to: To: john.loughney@nokia.com, Gonzalo.Camarillo@lmf.ericsson.se, sipping@ietf.org Message-id: <000001c2d1fc$b8a17cf0$68202aa6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >but one option is develop a solution using > Diameter in RADIUS-compatibility mode. OK, this is better than nothing. We'll take what we can :-) As mentioned, the installed base is RADIUS, no matter how voluminous the DIAMETER literature may be. Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of john.loughney@nokia.com > Sent: Tuesday, February 11, 2003 8:58 AM > To: Henry.Sinnreich@wcom.com; > Gonzalo.Camarillo@lmf.ericsson.se; sipping@ietf.org > Subject: RE: [Sipping] New version of the SIP-AAA reqs draft > > > Hi Henry, > > > > > We will now try to get the work on the diameter-based > > solution going. > > > > As has been mentioned here, 99.999% (five nines :-0>) of existing > > implementations and deployment are RADIUS. After RADIUS > come the web > > services. > > > > I suggest therefore to start with RADIUS instead. > > RADIUS is extremely limited in a number of cases - security, > transport issues, reliability and is most likely illegal in > many jurisdictions for use with token-based accounting (due > to the non-reliable nature of RADIUS). > > What I think you are more concerned for the solution to work > with RADIUS, correct? It may be pre-mature to discuss > solutions, but one option is develop a solution using > Diameter in RADIUS-compatibility mode. The alert reader then > may be able to determine how to use RADIUS in such > circumstances. However, it is unlikely that the IESG will > approve using RADIUS for SIP-AAA needs because of the > well-documented short comings of RADIUS. > > br, > 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 > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Feb 11 13:43:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14814 for ; Tue, 11 Feb 2003 13:43:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BIqkq03126 for sipping-archive@odin.ietf.org; Tue, 11 Feb 2003 13:52:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BIqjp03123 for ; Tue, 11 Feb 2003 13:52:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14798 for ; Tue, 11 Feb 2003 13:43:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BIq5p03102; Tue, 11 Feb 2003 13:52:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BIpqp03048 for ; Tue, 11 Feb 2003 13:51:52 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14749 for ; Tue, 11 Feb 2003 13:42:20 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1BIit215200 for ; Tue, 11 Feb 2003 20:44:55 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Feb 2003 20:46:02 +0200 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 11 Feb 2003 20:46:02 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 11 Feb 2003 20:46:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] New version of the SIP-AAA reqs draft Date: Tue, 11 Feb 2003 20:46:01 +0200 Message-ID: Thread-Topic: [Sipping] New version of the SIP-AAA reqs draft Thread-Index: AcLR/OdIh57j7ayFTaqILBJ5IShwDAAAK8Ww To: , , X-OriginalArrivalTime: 11 Feb 2003 18:46:02.0147 (UTC) FILETIME=[D3487F30:01C2D1FD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1BIprp03049 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Henry, > >but one option is develop a solution using > > Diameter in RADIUS-compatibility mode. > > OK, this is better than nothing. We'll take what we can :-) > > As mentioned, the installed base is RADIUS, no matter how > voluminous the DIAMETER literature may be. I think the issues is that the IETF should recommend what is the right thing to do & why. If people choose to do something else, well, that is life. I understand what you are asking but I do note that some people have thought that the potential for AAA is much greater than the existing installed base. br, 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 mailnull@www1.ietf.org Tue Feb 11 13:56:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15152 for ; Tue, 11 Feb 2003 13:56:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BJ59x03619 for sipping-archive@odin.ietf.org; Tue, 11 Feb 2003 14:05:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BJ58p03616 for ; Tue, 11 Feb 2003 14:05:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15139 for ; Tue, 11 Feb 2003 13:55:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BJ4Op03591; Tue, 11 Feb 2003 14:04:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BJ3Ip03533 for ; Tue, 11 Feb 2003 14:03:18 -0500 Received: from wiprom2mx1.wipro.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15064 for ; Tue, 11 Feb 2003 13:53:40 -0500 (EST) Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id h1BIvMv18464 for ; Wed, 12 Feb 2003 00:27:22 +0530 (IST) Received: from blr-ec-msg01.wipro.com ([10.200.50.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 12 Feb 2003 00:27:17 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: Re : [Sipping] QSIG Vs DPNSS MIME Date: Wed, 12 Feb 2003 00:27:17 +0530 Message-ID: <5CD22C179E0D7C49954F3ACCA07E4EDE09D1AC@blr-ec-msg01.wipro.com> Thread-Topic: Re : [Sipping] QSIG Vs DPNSS MIME Thread-Index: AcLR/2WkGO0P8aWdQAGEqcXi8zxggQ== From: "Ranjith Mukundan" To: , X-OriginalArrivalTime: 11 Feb 2003 18:57:17.0379 (UTC) FILETIME=[65C0B930:01C2D1FF] 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: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Re : [Sipping] QSIG Vs DPNSS MIME

John,


>> 4. During this work we found it necessary to specify that a = QSIG-SIP gateway
>> should behave as a transit PBX from the perspective of the QSIG = protocol.

[ranjith]
Yes, as in the case of QSIG, the DPNSS-SIP gateway too is expected to = behave as a 'transit' from the DPNSS point of view. Thats a good point = you raised. We need to look harder at this aspect and incorporate the = required text in the draft (esp regarding the transit timers etc).


>> 6. The message buffering option may not be suitable for = buffering ISRM(I)
>> and SSRM(I) messages. These messages are not only used to = overcome the 45
>> octet message limit but are also used for overlap sending. = Consequently a
>> SSRM(C) will not necessarily be expected.

[ranjith]
Agreed. The buffering option makes sense for segmented messages alone. = Extending it to overlap signaling will unnecessarily complicate the = gateway implementation and also defeats the purpose of overlap = signaling. As you suggest, I guess we should restrict the buffering = option to segmented messages alone.

>> I suspect that you will wish to limit DPNSS tunnelling to
>> option 1 - otherwise you will need to carry additional = information that is
>> normally available from DPNSS layer 2. This needs to be = stated.

[ranjith]
Currently, Yes. But you've raised an interesting point. We'll explore = the possibility of option 2; unless it complicates the protocol aspects = vis-a-vis the advantages.

Thanks for the inputs.

cheers,
- ranjith..


-----Original Message-----
From: Elwell, John [mailto:john.elwell@siemens.com]
Sent: Tuesday, February 11, 2003 4:59 PM
To: 'Ranjith Mukundan'
Subject: RE: [Sipping] QSIG Vs DPNSS MIME


Ranjith,

Just a few remarks.

1. DPNSS is no longer published by BT. The latest version (version 7) = is
DPNSS[188] published by Oftel sub-committee NICC (Network = Interoperability
Consultative Committee). This has also has an internal reference = number
ND1301:2001/03. The current URL is:

http://www.oftel.gov.uk/ind_groups/nicc/Public/interconnects= tandards/isc.htm
<http://www.oftel.gov.uk/ind_groups/nicc/Public/interconnectstandards/= isc.ht
m>

but this is liable to change (e.g., Oftel will change to Ofcom) and = should
not be quoted in any long-term document.

I don't think previous versions (1 to 6) are available any more, but = of
course there will be implementations. However, most people will be = aware
only of the BTNRs, so it would still be worth mentioning "formerly = BTNR
188".

2. If version number is to be carried, then version 7 should be = added.

3. For QSIG tunneling over SIP we found that the RFC specifying the = MIME
type is insufficient for achieving correct operation in multi-vendor
networks. Therefore in ECMA we are working on an additional = specification
that will detail procedures to be adopted at the QSIG-SIP gateway.

4. During this work we found it necessary to specify that a QSIG-SIP = gateway
should behave as a transit PBX from the perspective of the QSIG = protocol. I
think this was mainly to make sure that all timers worked correctly. = You
might wish to explore whether the same statement needs to be made for = DPNSS
gateways. For example, by making a gateway behave as a transit PBX, it = would
be required to respond with a CIM when a CRM is received, rather than = simply
passing on the CRM.

5. This may also have impact on the message buffering option. A gateway = may
need to run a timer if it receives EEM(I) to guard against failure = to
receive EEM(C).

6. The message buffering option may not be suitable for buffering = ISRM(I)
and SSRM(I) messages. These messages are not only used to overcome the = 45
octet message limit but are also used for overlap sending. Consequently = a
SSRM(C) will not necessarily be expected.

7. For QSIG we are considering two options: option 1 is to tunnel only = one
QSIG call over a single SIP dialogue. Option 2 is to tunnel an = arbitrary
number of QSIG calls in series and/or in parallel over a semi-permanent = SIP
dialogue. Option 2 uses the QSIG call reference to identify the call and = the
QSIG channel identification information element to identify the = particular
RTP session. I suspect that you will wish to limit DPNSS tunnelling = to
option 1 - otherwise you will need to carry additional information that = is
normally available from DPNSS layer 2. This needs to be stated.

I hope this is of use to you.

John

John Elwell - Technical Consultant
Tel: +44 (0)115 943 4989
Fax: +44 (0)115 943 4969
e-mail: mailto:john.elwell@siemens.com <mailto:john.elwell@siemens.com>
web: http://www.siemens-design= -services.com
<http://www.siemens-desig= n-services.com/>

Siemens Communications
Technology Drive, Beeston, Nottingham, NG9 1LA.  England.

"Siemens Communications - a division of Siemens plc,  = Registered No: 727817,
England. Registered office: Siemens House, Oldbury, Bracknell, = Berkshire,
RG12 8FZ.


-----Original Message-----
From: Ranjith Mukundan [mailto:ranjith.mukundan@wipro.= com]
Sent: 11 February 2003 08:59
To: sipping@ietf.org
Subject: [Sipping] QSIG Vs DPNSS MIME



we'd appreciate some views on this draft from atleast those who = fairly
understand QSIG.

of course, others who feel that this MIME type collides directly with = the
purpose of SIP are encouraged to provide alternatives bearing in mind = that
providing complete end-to-end service transparency over the intervening = SIP
based core would be essential, if we are to provide a seamless = migration
path from H.323 based core networks - which already provide = equivalent
mechanisms for DSS1 based protocols.

- ranjith..


-----Original Message-----
From:   Ranjith Mukundan
Sent:   Sat 2/8/2003 12:09 AM
To:     sipping@ietf.org
Cc:
Subject:        RE: [Sipping] I-D = ACTION:draft-mukundan-sipping-dpnss-01.txt

Hi,

posting WRT
http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-= 01.txt
<http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-= 01.txt>


>>
>> Why is it so important to be able to tunnel DPNSS in SIP?  = I'd prefer
>> that folks implement a translation to SIP, where SIP can = natively carry
>> all the information that DPNSS is trying to convey.
>>

To put things in perspective:

1- DPNSS is a protocol (deployed primarily in UK, NZ, Australia and = parts of
NA) very similar to QSIG (deployed primarily Europe) for = interconnecting
PBXs or centrex customers hosted off LEs. DPNSS (like QSIG) finds = enormous
application towards realizing a local VPN or network-wide VPN = services.

2- This draft aims to do exactly what RFC 3204 (MIME objects for = QSIG/ISUP)
does for QSIG with appropriate/relevant customization for DPNSS - i.e., = to
provide end-to-end & *complete*, DPNSS Service transparency between = pockets
of DPNSS based private networks over a SIP based core.

3- Currently, circuit-switched SS7 based cores, provide equivalent = DPNSS
tunneling mechanisms through (ETSI & ANSI) ISUP *apart from* the = concomitant
translation/interworking mechanisms to ISUP. The = translation/interworking
mechanism to ISUP is limited to the basic call and certain ISUP
supplementary services where there is a direct/easy equivalent.

4- H.323 also provides equivalent tunneling mechanisms (via the H.450 = Annexe
procedures) for transparently carrying DSS1 based signaling between
DSS1-based network elements/gateways, over a H.323 core.

Some specifics:

1- DPNSS supports, as specified in BTNR 188, approximately 240+
supplementary features/services (like Call Back When Free, Call Back = When
Next Used, Executive Intrusion, Travelling Class of Service, Do Not = Disturb,
Night Service, Private Network Route Optimization, Centralized = Operator,
Three Party Takeover, Remote Diversion Registration etc). It would be = almost
impossible to interwork to equivalent mechanisms in SIP, without losing = the
service transparency when using an intervening SIP based core.

2- Yes, we definitely need an interworking/translation mechanism to map = all
the basic call/service paremeters, and procedures for mapping the = messages.
But this does not preclude the need for a DPNSS MIME type, but would = rather
be complimentary to the MIME type mechanism. Similar to
http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-00= .txt
<http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-00= .txt>  ,
for QSIG, we are in the process of putting together an interworking = draft
for DPNSS as well - but rather than making it DPNSS specific, we are = trying
to make it a common draft to cover PRI, DPNSS & DASS2 [as Q.SIG = interworking
is already a SIPPING WG ID]. Note that, PRI and DASS2 will not need a = MIME
type as these are, as one might be aware, for PSTN access, unlike DPNSS = and
QSIG (which are private network protocols).

3- From the SIP perspective, carrying non-SIP applications as MIME = objects
to ensure end to end service transparency is architecturally less = appalling
than, say for e.g., tunneling DSS1 protocols in H.323 based network - so = the
SIP DPNSS MIME proposition as per this I-D is the obvious way forward = for
DPNSS service transparency over a SIP based core, especially now that we = see
acute deployment needs to be met.

cheers,
ranjith..

> -----Original Message-----
> From: sipping-admin@ietf.org [ mailto:sipping-admin@ietf.org<= BR> <mailto:sipping-admin@ietf.org&= gt; ]On Behalf
> Of
> Ranjith Mukundan
> Sent: Tuesday, February 04, 2003 5:32 PM
> To: sipping@ietf.org
> Subject: RE: [Sipping] I-D = ACTION:draft-mukundan-sipping-dpnss-01.txt
>
>
> Hi List,
> We would like you take a look at this draft and revert with any
> comments/queries that you might have.
>
> SIPPING Chairs,
> The authors feel that the requirement and the need for this MIME = type
> is
> quite acute. Hence we'd like you to consider this for inclusion as = a
> WG I-D
> and suggest the way forward.
>
> - ranjith..
>
> -----Original Message-----
> From: sipping-admin@ietf.org [ mailto:sipping-admin@ietf.org<= BR> <mailto:sipping-admin@ietf.org&= gt; ]On Behalf
> Of
> Internet-Drafts@ietf.org
> Sent: Tuesday, February 04, 2003 5:14 PM
> To: IETF-Announce:
> Cc: sipping@ietf.org
> Subject: [Sipping] I-D = ACTION:draft-mukundan-sipping-dpnss-01.txt
>
>
> A New Internet-Draft is available from the on-line = Internet-Drafts
> directories.
>
>
>       = Title           : MIME = media types for DPNSS Objects
>       = Author(s)       : R. Mukundan et al.
>       = Filename        : = draft-mukundan-sipping-dpnss-01.txt
>       = Pages           : = 9
>       = Date            : = 2003-2-3
>
> This document describes Multipart Internet Mail Extensions (MIME) = type
> for application/Digital Private Network Signaling System = (DPNSS)
> objects for use in Session Initiation Protocol (SIP) = applications,
> according to the rules defined in RFC 2048. These types can be used = to
> identify Digital Private Network Signaling System 1 (DPNSS 1) = objects
> within a SIP message such as INVITE or INFO, as might be = implemented
> when using SIP in an environment where part of the call = involves
> interworking to DPNSS 1 based Private Networks. RFC 3204 addresses = a
> similar need for Integrated Service Digital Network User Part = (ISUP)
> and Q Signaling (QSIG).
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-0= 1.tx
<http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-0= 1.tx>
> t
>
> To remove yourself from the IETF Announcement list, send a message = to
> ietf-announce-request with the word unsubscribe in the body of = the
> message.
>
> Internet-Drafts are also available by anonymous FTP. Login with = the
> username
> "anonymous" and a password of your e-mail address. After = logging in,
> type "cd internet-drafts" and then
>       "get = draft-mukundan-sipping-dpnss-01.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html<= /A> <http://www.ietf.org/shadow.html<= /A>>  or
> ftp://ftp.ietf.org/iet= f/1shadow-sites.txt
<ftp://ftp.ietf.org/iet= f/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-mukundan-sipping-dpnss-01.txt".
>
> NOTE: The mail server at ietf.org can return the document in
>       MIME-encoded form by using the = "mpack" utility.  To use this
>       feature, insert the command = "ENCODING mime" before the "FILE"
>       command.  To decode the = response(s), you will need "munpack" or
>       a MIME-compliant mail = reader.  Different MIME-compliant mail readers
>       exhibit different behavior, = especially when dealing with
>       "multipart" MIME = messages (i.e. documents which have been split
>       up into multiple messages), so = check your local documentation on
>       how to manipulate these = messages.
>
>
> Below is the data which will enable a MIME compliant mail = reader
> implementation to automatically retrieve the ASCII version of = the
> Internet-Draft.
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf= .org/mailman/listinfo/sipping
<https://www1.ietf= .org/mailman/listinfo/sipping>
> This list is for NEW development of the 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 mailnull@www1.ietf.org Tue Feb 11 14:20:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15855 for ; Tue, 11 Feb 2003 14:20:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BJTZ105237 for sipping-archive@odin.ietf.org; Tue, 11 Feb 2003 14:29:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BJTYp05234 for ; Tue, 11 Feb 2003 14:29:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15834 for ; Tue, 11 Feb 2003 14:20:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BJSpp05199; Tue, 11 Feb 2003 14:28:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BJRdp05126 for ; Tue, 11 Feb 2003 14:27:40 -0500 Received: from dgesmtp01.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15809 for ; Tue, 11 Feb 2003 14:18:06 -0500 (EST) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.wcom.com (Iplanet MTA) with ESMTP id <0HA50081NSEETI@firewall.wcom.com> for sipping@ietf.org; Tue, 11 Feb 2003 19:20:38 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HA500301SE5GV@pmismtp04.wcomnet.com>; Tue, 11 Feb 2003 19:20:38 +0000 (GMT) Received: from hsinnreich2 ([166.42.32.104]) by pmismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HA5002FASCZRA@pmismtp04.wcomnet.com>; Tue, 11 Feb 2003 19:20:34 +0000 (GMT) Date: Tue, 11 Feb 2003 13:19:47 -0600 From: Henry Sinnreich Subject: RE: [Sipping] New version of the SIP-AAA reqs draft In-reply-to: To: john.loughney@nokia.com, Gonzalo.Camarillo@lmf.ericsson.se, sipping@ietf.org Message-id: <001f01c2d202$a6722060$68202aa6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >potential for AAA is much > greater than the existing installed base. Yes, and it will be in the XML based web services architecture. Nobody will buy anything, including IP services using anything else. No bank IT department will ever know what DIAMETER is. I rest my case and will not repeat this argument any further. Who can predict the future anyway... Henry > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Tuesday, February 11, 2003 12:46 PM > To: Henry.Sinnreich@wcom.com; > Gonzalo.Camarillo@lmf.ericsson.se; sipping@ietf.org > Subject: RE: [Sipping] New version of the SIP-AAA reqs draft > > > Hi Henry, > > > >but one option is develop a solution using > > > Diameter in RADIUS-compatibility mode. > > > > OK, this is better than nothing. We'll take what we can :-) > > > > As mentioned, the installed base is RADIUS, no matter how > > voluminous the DIAMETER literature may be. > > I think the issues is that the IETF should recommend what is > the right thing to do & why. If people choose to do > something else, well, that is life. > > I understand what you are asking but I do note that some > people have thought that the potential for AAA is much > greater than the existing installed base. > > br, > 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 mailnull@www1.ietf.org Tue Feb 11 14:56:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16918 for ; Tue, 11 Feb 2003 14:56:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BK5Wg07789 for sipping-archive@odin.ietf.org; Tue, 11 Feb 2003 15:05:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BK5Wp07786 for ; Tue, 11 Feb 2003 15:05:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16910 for ; Tue, 11 Feb 2003 14:55:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BK4Yp07706; Tue, 11 Feb 2003 15:04:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BK3Pp07644 for ; Tue, 11 Feb 2003 15:03:25 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16851 for ; Tue, 11 Feb 2003 14:53:48 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h1BJvSC26517; Tue, 11 Feb 2003 19:57:28 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Feb 2003 14:57:51 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214DB8@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Mark Watson'" , sipping@ietf.org Subject: RE: [Sipping] QSIG Vs DPNSS MIME Date: Tue, 11 Feb 2003 14:57:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D207.D8D90320" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2D207.D8D90320 Content-Type: text/plain; charset="iso-8859-1" I begin to sympathize with those who argued that the ISUP/QSIG MIME type should have been a more open-ended envelope for telephony signaling information. I am reluctant to standardize every conceivable sort of telephony signaling as a MIME type with some profile information for encapsulating it in SIP. I suppose the question really is one of how great the need is to standardize this DPNSS encapsulation. I'm not really familiar with it, so I don't have much of an opinion either way. In any event, as another nit, this document should not define the Content-Disposition header, it should reference the definition and BNF in RFC3204. Jon Peterson NeuStar, Inc. -----Original Message----- From: Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: Tuesday, February 11, 2003 9:29 AM To: sipping@ietf.org Subject: RE: [Sipping] QSIG Vs DPNSS MIME All, I really can't see any difference between DPNSS and Q.SIG when it comes to the need for a MIME type for carriage of this within SIP. Can anyone come up with an argument for/against this draft which does not apply to Q.SIG just as well ? If not, then I certainly think this should be progressed. I have some comments on the draft: 1) DPNSS has now been published by the UK's Network Interoperability Consultative Committee as NICC Document 1301:2001/03. You can find it at http://www.oftel.gov.uk/ind_groups/nicc/Public/interconnectstandards/isc.htm along with lots of other gems. You should reference this version, rather than the somewhat harder to obtain BTNR. 2) Why do you need a length octet at the front of the message ? Can't you (or shouldn't you) put a Content-Length in the MIME headers for this MIME part ? 3) I think given the short length of the messages you could get away with mandating that segmented DPNSS messages should always be reassembled before encapsulating in SIP and that receivers must be able to receive such reassembled messages. This removes some unnecessary complexity. 4) Section 3, under table 1, you say 'Floating Point' when you mean 'Decimal'. I think the words 'contiguously increasing' could probably be removed here too. You will have trouble finding the next real number after 6.00! Regards...Mark -----Original Message----- From: Ranjith Mukundan [mailto:ranjith.mukundan@wipro.com] Sent: 11 February 2003 08:59 To: sipping@ietf.org Subject: [Sipping] QSIG Vs DPNSS MIME we'd appreciate some views on this draft from atleast those who fairly understand QSIG. of course, others who feel that this MIME type collides directly with the purpose of SIP are encouraged to provide alternatives bearing in mind that providing complete end-to-end service transparency over the intervening SIP based core would be essential, if we are to provide a seamless migration path from H.323 based core networks - which already provide equivalent mechanisms for DSS1 based protocols. - ranjith.. -----Original Message----- From: Ranjith Mukundan Sent: Sat 2/8/2003 12:09 AM To: sipping@ietf.org Cc: Subject: RE: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-01.txt Hi, posting WRT http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-01.txt >> >> Why is it so important to be able to tunnel DPNSS in SIP? I'd prefer >> that folks implement a translation to SIP, where SIP can natively carry >> all the information that DPNSS is trying to convey. >> To put things in perspective: 1- DPNSS is a protocol (deployed primarily in UK, NZ, Australia and parts of NA) very similar to QSIG (deployed primarily Europe) for interconnecting PBXs or centrex customers hosted off LEs. DPNSS (like QSIG) finds enormous application towards realizing a local VPN or network-wide VPN services. 2- This draft aims to do exactly what RFC 3204 (MIME objects for QSIG/ISUP) does for QSIG with appropriate/relevant customization for DPNSS - i.e., to provide end-to-end & *complete*, DPNSS Service transparency between pockets of DPNSS based private networks over a SIP based core. 3- Currently, circuit-switched SS7 based cores, provide equivalent DPNSS tunneling mechanisms through (ETSI & ANSI) ISUP *apart from* the concomitant translation/interworking mechanisms to ISUP. The translation/interworking mechanism to ISUP is limited to the basic call and certain ISUP supplementary services where there is a direct/easy equivalent. 4- H.323 also provides equivalent tunneling mechanisms (via the H.450 Annexe procedures) for transparently carrying DSS1 based signaling between DSS1-based network elements/gateways, over a H.323 core. Some specifics: 1- DPNSS supports, as specified in BTNR 188, approximately 240+ supplementary features/services (like Call Back When Free, Call Back When Next Used, Executive Intrusion, Travelling Class of Service, Do Not Disturb, Night Service, Private Network Route Optimization, Centralized Operator, Three Party Takeover, Remote Diversion Registration etc). It would be almost impossible to interwork to equivalent mechanisms in SIP, without losing the service transparency when using an intervening SIP based core. 2- Yes, we definitely need an interworking/translation mechanism to map all the basic call/service paremeters, and procedures for mapping the messages. But this does not preclude the need for a DPNSS MIME type, but would rather be complimentary to the MIME type mechanism. Similar to http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-00.txt , for QSIG, we are in the process of putting together an interworking draft for DPNSS as well - but rather than making it DPNSS specific, we are trying to make it a common draft to cover PRI, DPNSS & DASS2 [as Q.SIG interworking is already a SIPPING WG ID]. Note that, PRI and DASS2 will not need a MIME type as these are, as one might be aware, for PSTN access, unlike DPNSS and QSIG (which are private network protocols). 3- From the SIP perspective, carrying non-SIP applications as MIME objects to ensure end to end service transparency is architecturally less appalling than, say for e.g., tunneling DSS1 protocols in H.323 based network - so the SIP DPNSS MIME proposition as per this I-D is the obvious way forward for DPNSS service transparency over a SIP based core, especially now that we see acute deployment needs to be met. cheers, ranjith.. > -----Original Message----- > From: sipping-admin@ietf.org [ mailto:sipping-admin@ietf.org ]On Behalf > Of > Ranjith Mukundan > Sent: Tuesday, February 04, 2003 5:32 PM > To: sipping@ietf.org > Subject: RE: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-01.txt > > > Hi List, > We would like you take a look at this draft and revert with any > comments/queries that you might have. > > SIPPING Chairs, > The authors feel that the requirement and the need for this MIME type > is > quite acute. Hence we'd like you to consider this for inclusion as a > WG I-D > and suggest the way forward. > > - ranjith.. > > -----Original Message----- > From: sipping-admin@ietf.org [ mailto:sipping-admin@ietf.org ]On Behalf > Of > Internet-Drafts@ietf.org > Sent: Tuesday, February 04, 2003 5:14 PM > To: IETF-Announce: > Cc: sipping@ietf.org > Subject: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : MIME media types for DPNSS Objects > Author(s) : R. Mukundan et al. > Filename : draft-mukundan-sipping-dpnss-01.txt > Pages : 9 > Date : 2003-2-3 > > This document describes Multipart Internet Mail Extensions (MIME) type > for application/Digital Private Network Signaling System (DPNSS) > objects for use in Session Initiation Protocol (SIP) applications, > according to the rules defined in RFC 2048. These types can be used to > identify Digital Private Network Signaling System 1 (DPNSS 1) objects > within a SIP message such as INVITE or INFO, as might be implemented > when using SIP in an environment where part of the call involves > interworking to DPNSS 1 based Private Networks. RFC 3204 addresses a > similar need for Integrated Service Digital Network User Part (ISUP) > and Q Signaling (QSIG). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-01.tx > t > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-mukundan-sipping-dpnss-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-mukundan-sipping-dpnss-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 ------_=_NextPart_001_01C2D207.D8D90320 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable QSIG Vs DPNSS MIME
 
I=20 begin to sympathize with those who argued that the ISUP/QSIG MIME type = should=20 have been a more open-ended envelope for telephony signaling = information. I am=20 reluctant to standardize every conceivable sort of telephony signaling = as a MIME=20 type with some profile information for encapsulating it in=20 SIP.
 
I=20 suppose the question really is one of how great the need is to = standardize this=20 DPNSS encapsulation. I'm not really familiar with it, so I don't have = much of an=20 opinion either way.
 
In any=20 event, as another nit, this document should not define the=20 Content-Disposition header, it should reference the definition and BNF = in=20 RFC3204.
 
Jon=20 Peterson
NeuStar, Inc.
-----Original Message-----
From: Mark Watson=20 [mailto:mwatson@nortelnetworks.com]
Sent: Tuesday, February = 11, 2003=20 9:29 AM
To: sipping@ietf.org
Subject: RE: = [Sipping] QSIG=20 Vs DPNSS MIME

All,
 
I=20 really can't see any difference between DPNSS and Q.SIG when it comes = to the=20 need for a MIME type for carriage of this within SIP. Can anyone come = up with=20 an argument for/against this draft which does not apply to Q.SIG just = as well=20 ?
 
If=20 not, then I certainly think this should be = progressed.
 
I=20 have some comments on the draft:
1)=20 DPNSS has now been published by the UK's Network Interoperability = Consultative=20 Committee as NICC Document 1301:2001/03. You can find it at http://www.oftel.gov.uk/ind_groups/nicc/Public/interconnec= tstandards/isc.htm along=20 with lots of other gems.
 
You should reference this version, rather = than the=20 somewhat harder to obtain BTNR.
 
2)=20 Why do you need a length octet at the front of the message ? Can't = you (or=20 shouldn't you) put a Content-Length in the MIME headers for this MIME = part=20 ?
3)=20 I think given the short length of the messages you could get away = with=20 mandating that segmented DPNSS messages should always be reassembled = before=20 encapsulating in SIP and that receivers must be able to receive such=20 reassembled messages. This removes some unnecessary=20 complexity.
4)=20 Section 3, under table 1, you say 'Floating Point' when you mean = 'Decimal'. I=20 think the words 'contiguously increasing' could probably be removed = here too.=20 You will have trouble finding the next real number after=20 6.00!
 
Regards...Mark
 
-----Original Message-----
From: Ranjith = Mukundan=20 [mailto:ranjith.mukundan@wipro.com]
Sent: 11 February = 2003=20 08:59
To: sipping@ietf.org
Subject: [Sipping] = QSIG Vs=20 DPNSS MIME

we'd appreciate some views on this draft from = atleast those=20 who fairly understand QSIG.

of course, others who feel that = this MIME=20 type collides directly with the purpose of SIP are encouraged to = provide=20 alternatives bearing in mind that providing complete end-to-end = service=20 transparency over the intervening SIP based core would be = essential, if we=20 are to provide a seamless migration path from H.323 based core = networks -=20 which already provide equivalent mechanisms for DSS1 based=20 protocols.

- ranjith..


-----Original=20 Message-----
From:   Ranjith = Mukundan
Sent:   Sat=20 2/8/2003 12:09 AM
To:    =20 = sipping@ietf.org
Cc:    
Subject:  &= nbsp;    =20 RE: [Sipping] I-D=20 = ACTION:draft-mukundan-sipping-dpnss-01.txt

Hi,

posting = WRT http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpns= s-01.txt


>>
>>=20 Why is it so important to be able to tunnel DPNSS in SIP?  I'd = prefer
>> that folks implement a translation to SIP, where = SIP can=20 natively carry
>> all the information that DPNSS is trying = to=20 convey.
>>

To put things in perspective:

1- = DPNSS is=20 a protocol (deployed primarily in UK, NZ, Australia and parts of = NA) very=20 similar to QSIG (deployed primarily Europe) for interconnecting = PBXs or=20 centrex customers hosted off LEs. DPNSS (like QSIG) finds enormous=20 application towards realizing a local VPN or network-wide VPN=20 services.

2- This draft aims to do exactly what RFC 3204 = (MIME=20 objects for QSIG/ISUP) does for QSIG with appropriate/relevant = customization=20 for DPNSS - i.e., to provide end-to-end & *complete*, DPNSS = Service=20 transparency between pockets of DPNSS based private networks over a = SIP=20 based core.

3- Currently, circuit-switched SS7 based cores, = provide=20 equivalent DPNSS tunneling mechanisms through (ETSI & ANSI) = ISUP *apart=20 from* the concomitant translation/interworking mechanisms to ISUP. = The=20 translation/interworking mechanism to ISUP is limited to the basic = call and=20 certain ISUP supplementary services where there is a direct/easy=20 equivalent.

4- H.323 also provides equivalent tunneling = mechanisms=20 (via the H.450 Annexe procedures) for transparently carrying DSS1 = based=20 signaling between DSS1-based network elements/gateways, over a = H.323=20 core.

Some specifics:

1- DPNSS supports, as specified = in BTNR=20 188, approximately 240+ supplementary features/services (like Call = Back When=20 Free, Call Back When Next Used, Executive Intrusion, Travelling = Class of=20 Service, Do Not Disturb, Night Service, Private Network Route = Optimization,=20 Centralized Operator, Three Party Takeover, Remote Diversion = Registration=20 etc). It would be almost impossible to interwork to equivalent = mechanisms in=20 SIP, without losing the service transparency when using an = intervening SIP=20 based core.

2- Yes, we definitely need an = interworking/translation=20 mechanism to map all the basic call/service paremeters, and = procedures for=20 mapping the messages. But this does not preclude the need for a = DPNSS MIME=20 type, but would rather be complimentary to the MIME type mechanism. = Similar=20 to http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-= 00.txt=20 , for QSIG, we are in the process of putting together an = interworking draft=20 for DPNSS as well - but rather than making it DPNSS specific, we = are trying=20 to make it a common draft to cover PRI, DPNSS & DASS2 [as Q.SIG = interworking is already a SIPPING WG ID]. Note that, PRI and DASS2 = will not=20 need a MIME type as these are, as one might be aware, for PSTN = access,=20 unlike DPNSS and QSIG (which are private network = protocols).

3- From=20 the SIP perspective, carrying non-SIP applications as MIME objects = to ensure=20 end to end service transparency is architecturally less appalling = than, say=20 for e.g., tunneling DSS1 protocols in H.323 based network - so the = SIP DPNSS=20 MIME proposition as per this I-D is the obvious way forward for = DPNSS=20 service transparency over a SIP based core, especially now that we = see acute=20 deployment needs to be met.

cheers,
ranjith..

> = -----Original Message-----
> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org= ]On=20 Behalf
> Of
> Ranjith Mukundan
> Sent: Tuesday, = February=20 04, 2003 5:32 PM
> To: sipping@ietf.org
> Subject: RE: = [Sipping]=20 I-D = ACTION:draft-mukundan-sipping-dpnss-01.txt
>
>
> Hi=20 List,
> We would like you take a look at this draft and = revert with=20 any
> comments/queries that you might have.
>
> = SIPPING=20 Chairs,
> The authors feel that the requirement and the need = for this=20 MIME type
> is
> quite acute. Hence we'd like you to = consider=20 this for inclusion as a
> WG I-D
> and suggest the way=20 forward.
>
> - ranjith..
>
> -----Original=20 Message-----
> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org= ]On=20 Behalf
> Of
> Internet-Drafts@ietf.org
> Sent: = Tuesday,=20 February 04, 2003 5:14 PM
> To: IETF-Announce:
> Cc:=20 sipping@ietf.org
> Subject: [Sipping] I-D=20 ACTION:draft-mukundan-sipping-dpnss-01.txt
>
>
> = A New=20 Internet-Draft is available from the on-line = Internet-Drafts
>=20 directories.
>
>
>       = Title           : MIME = media=20 types for DPNSS Objects
>      =20 Author(s)       : R. Mukundan et = al.
>=20      =20 Filename        :=20 draft-mukundan-sipping-dpnss-01.txt
> =      =20 Pages           : = 9
>=20       Date   =20         : = 2003-2-3
>
> This=20 document describes Multipart Internet Mail Extensions (MIME) = type
>=20 for application/Digital Private Network Signaling System = (DPNSS)
>=20 objects for use in Session Initiation Protocol (SIP) = applications,
>=20 according to the rules defined in RFC 2048. These types can be used = to
> identify Digital Private Network Signaling System 1 = (DPNSS 1)=20 objects
> within a SIP message such as INVITE or INFO, as = might be=20 implemented
> when using SIP in an environment where part of = the call=20 involves
> interworking to DPNSS 1 based Private Networks. = RFC 3204=20 addresses a
> similar need for Integrated Service Digital = Network User=20 Part (ISUP)
> and Q Signaling (QSIG).
>
> A URL = for this=20 Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss= -01.tx
>=20 t
>
> To remove yourself from the IETF Announcement = list, send a=20 message to
> ietf-announce-request with the word unsubscribe = in the=20 body of the
> message.
>
> Internet-Drafts are = also=20 available by anonymous FTP. Login with the
> username
> = "anonymous" and a password of your e-mail address. After logging = in,
>=20 type "cd internet-drafts" and then
> =      =20 "get draft-mukundan-sipping-dpnss-01.txt".
>
> A list = of=20 Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html= =20 or
> ftp://ftp.ietf.org/ie= tf/1shadow-sites.txt
>
>
>=20 Internet-Drafts can also be obtained by e-mail.
>
> = Send a=20 message to:
>      =20 mailserv@ietf.org.
> In the body type:
>=20       "FILE=20 = /internet-drafts/draft-mukundan-sipping-dpnss-01.txt".
>
> = NOTE:=20 The mail server at ietf.org can return the document in
>=20       MIME-encoded form by using the = "mpack"=20 utility.  To use this
>       = feature,=20 insert the command "ENCODING mime" before the "FILE"
>=20       command.  To decode the = response(s), you=20 will need "munpack" or
>       a=20 MIME-compliant mail reader.  Different MIME-compliant mail=20 readers
>       exhibit different = behavior,=20 especially when dealing with
>       = "multipart" MIME messages (i.e. documents which have been = split
>=20       up into multiple messages), so check = your=20 local documentation on
>       how = to=20 manipulate these messages.
>
>
> Below is the = data which=20 will enable a MIME compliant mail reader
> implementation to=20 automatically retrieve the ASCII version of the
>=20 Internet-Draft.
>
>=20 _______________________________________________
> Sipping = mailing=20 list  https://www1.iet= f.org/mailman/listinfo/sipping
>=20 This list is for NEW development of the application of SIP = Use
>=20 sip-implementors@cs.columbia.edu for questions on current sip = Use
>=20 sip@ietf.org for new developments of core=20 = SIP




______________________________________= _________=20 Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping = This=20 list is for NEW development of the application of SIP Use=20 sip-implementors@cs.columbia.edu for questions on current sip Use=20 sip@ietf.org for new developments of core SIP=20
------_=_NextPart_001_01C2D207.D8D90320-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Feb 11 18:22:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21523 for ; Tue, 11 Feb 2003 18:22:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BNVNu20673 for sipping-archive@odin.ietf.org; Tue, 11 Feb 2003 18:31:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BNVNp20670 for ; Tue, 11 Feb 2003 18:31:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21492 for ; Tue, 11 Feb 2003 18:21:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BNUdp20586; Tue, 11 Feb 2003 18:30:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BNTQp20531 for ; Tue, 11 Feb 2003 18:29:26 -0500 Received: from petasus.ch.intel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21459 for ; Tue, 11 Feb 2003 18:19:48 -0500 (EST) Received: from azsmsxvs040.ch.intel.com (azsmsxvs040.ch.intel.com [10.2.248.11]) by petasus.ch.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.49 2003/01/13 19:45:39 dmccart Exp $) with SMTP id h1BNNwV19833 for ; Tue, 11 Feb 2003 23:23:58 GMT Received: from azsmsx023.ch.intel.com ([10.2.248.28]) by azsmsxvs040.ch.intel.com (NAVGW 2.5.2.11) with SMTP id M2003021116233022277 for ; Tue, 11 Feb 2003 16:23:30 -0700 Received: by azsmsx023.ch.intel.com with Internet Mail Service (5.5.2653.19) id <1N0BAXML>; Tue, 11 Feb 2003 16:19:19 -0700 Message-ID: <3D90571297ABD511957400508BF29C43043EA574@pysmsx101.py.intel.com> From: "Miao, Kai" To: sipping@ietf.org Date: Tue, 11 Feb 2003 16:23:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D224.956735E0" Subject: [Sipping] Question about call flow in draft-ietf-sipping-service-examples-0 3 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2D224.956735E0 Content-Type: text/plain; charset="iso-8859-1" Could someone provide an answer to the following question: In the first example, Call Hold, given in draft-ietf-sipping-service-examples-03.txt, why F10, i.e., INVITE(hold), has a=sendonly in its SDP message and F12, i.e., 200 OK, has no "a=" attribute at all while "No RTP Sent!" is marked in the call flow diagram? Shoudn't F12 contain a=recvonly or a=inactive, following the Offer/Answer model? Why there is "no RTP sent" in the diagram when there is "a=sendonly" in F10? Thanks, Kai Miao Intel ------_=_NextPart_001_01C2D224.956735E0 Content-Type: text/html; charset="iso-8859-1" QSIG Vs DPNSS MIME
Could someone provide an answer to the following question:
 
In the first example, Call Hold, given in draft-ietf-sipping-service-examples-03.txt, why F10, i.e., INVITE(hold), has a=sendonly in its SDP message and F12, i.e., 200 OK, has no "a=" attribute at all while "No RTP Sent!" is marked in the call flow diagram? 
 
Shoudn't F12 contain a=recvonly or a=inactive, following the Offer/Answer model? Why there is "no RTP sent" in the diagram when there is "a=sendonly" in F10?
 
Thanks,
Kai Miao
Intel   
------_=_NextPart_001_01C2D224.956735E0-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Feb 11 18:37:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21935 for ; Tue, 11 Feb 2003 18:37:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BNks921948 for sipping-archive@odin.ietf.org; Tue, 11 Feb 2003 18:46:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BNksp21945 for ; Tue, 11 Feb 2003 18:46:54 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21902 for ; Tue, 11 Feb 2003 18:37:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BNkJp21919; Tue, 11 Feb 2003 18:46:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BNjnp21870 for ; Tue, 11 Feb 2003 18:45:49 -0500 Received: from petasus.ch.intel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21892 for ; Tue, 11 Feb 2003 18:36:11 -0500 (EST) Received: from azsmsxvs040.ch.intel.com (azsmsxvs040.ch.intel.com [10.2.248.11]) by petasus.ch.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.49 2003/01/13 19:45:39 dmccart Exp $) with SMTP id h1BNeK522093 for ; Tue, 11 Feb 2003 23:40:20 GMT Received: from azsmsx023.ch.intel.com ([10.2.248.28]) by azsmsxvs040.ch.intel.com (NAVGW 2.5.2.11) with SMTP id M2003021116395301562 for ; Tue, 11 Feb 2003 16:39:53 -0700 Received: by azsmsx023.ch.intel.com with Internet Mail Service (5.5.2653.19) id <1N0BAZ7G>; Tue, 11 Feb 2003 16:35:42 -0700 Message-ID: <3D90571297ABD511957400508BF29C43043EA575@pysmsx101.py.intel.com> From: "Miao, Kai" To: "'sipping@ietf.org'" Date: Tue, 11 Feb 2003 16:39:52 -0700 Expiry-Date: Thu, 13 Feb 2003 16:39:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Sipping] Recall: Question about call flow in draft-ietf-sipping-service-ex amples-03 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Miao, Kai would like to recall the message, "Question about call flow in draft-ietf-sipping-service-examples-03". _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Feb 11 22:35:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27141 for ; Tue, 11 Feb 2003 22:35:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1C3ieW02746 for sipping-archive@odin.ietf.org; Tue, 11 Feb 2003 22:44:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C3iep02743 for ; Tue, 11 Feb 2003 22:44:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27132 for ; Tue, 11 Feb 2003 22:34:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C3hdp02704; Tue, 11 Feb 2003 22:43:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C3gXp02674 for ; Tue, 11 Feb 2003 22:42:33 -0500 Received: from wiprom2mx1.wipro.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27028 for ; Tue, 11 Feb 2003 22:32:35 -0500 (EST) Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id h1C3aFv10416 for ; Wed, 12 Feb 2003 09:06:15 +0530 (IST) Received: from blr-ec-msg01.wipro.com ([10.200.50.99]) by blr-ec-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 12 Feb 2003 09:06:09 +0530 Received: from ranjith2 ([192.168.178.234]) by blr-ec-msg01.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 12 Feb 2003 09:06:09 +0530 From: "Ranjith Mukundan" To: "Peterson, Jon" , "'Mark Watson'" , Subject: RE: [Sipping] QSIG Vs DPNSS MIME Date: Wed, 12 Feb 2003 09:10:03 +0530 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-040faa5b-3dcd-11d7-ba7f-006067005148" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) x-mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <15A2739B7DAA624D8091C65981D7DA8101214DB8@stntexch2.va.neustar.com> Importance: Normal X-OriginalArrivalTime: 12 Feb 2003 03:36:09.0349 (UTC) FILETIME=[E1DA5B50:01C2D247] Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPartTM-000-040faa5b-3dcd-11d7-ba7f-006067005148 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007D_01C2D276.8701EF20" ------=_NextPart_000_007D_01C2D276.8701EF20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit QSIG Vs DPNSS MIMEin so far as inter-PBX/Centrex connectivity goes, amongst the DSS1 derived protocols, DPNSS is, IMO, the *only* (big) missing piece. Can anyone think of another, standards-based, telephony signaling, the might require a MIME carriage?? (atleast, i can't think of any - not even an arcane, minimally deployed one) As I mentioned earlier, we dont need MIME types for protocols like DASS2, PRI and all the other 'conceivable sort' of telephony signaling thats used for PSTN connectivity (vis-a-vis inter-PBX/centrex connectivity). Even in the case of telephony protocols used for inter-PBX/centrex connectivity, unless it requires the same end to end, complete service transparency as in the case of private networks interconnected by QSIG or DPNSS, it does not mandate carriage as MIME type (a simple interworking function to SIP would suffice). So I dont think we'll a slew of MIME types... >> In any event, as another nit, this document should not define the Content-Disposition header, it should reference the definition and BNF in RFC3204. Should've known. thanks - it was an oversight. cheers, - ranjith.. -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf Of Peterson, Jon Sent: Wednesday, February 12, 2003 1:28 AM To: 'Mark Watson'; sipping@ietf.org Subject: RE: [Sipping] QSIG Vs DPNSS MIME I begin to sympathize with those who argued that the ISUP/QSIG MIME type should have been a more open-ended envelope for telephony signaling information. I am reluctant to standardize every conceivable sort of telephony signaling as a MIME type with some profile information for encapsulating it in SIP. I suppose the question really is one of how great the need is to standardize this DPNSS encapsulation. I'm not really familiar with it, so I don't have much of an opinion either way. In any event, as another nit, this document should not define the Content-Disposition header, it should reference the definition and BNF in RFC3204. Jon Peterson NeuStar, Inc. -----Original Message----- From: Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: Tuesday, February 11, 2003 9:29 AM To: sipping@ietf.org Subject: RE: [Sipping] QSIG Vs DPNSS MIME All, I really can't see any difference between DPNSS and Q.SIG when it comes to the need for a MIME type for carriage of this within SIP. Can anyone come up with an argument for/against this draft which does not apply to Q.SIG just as well ? If not, then I certainly think this should be progressed. I have some comments on the draft: 1) DPNSS has now been published by the UK's Network Interoperability Consultative Committee as NICC Document 1301:2001/03. You can find it at http://www.oftel.gov.uk/ind_groups/nicc/Public/interconnectstandards/isc.htm along with lots of other gems. You should reference this version, rather than the somewhat harder to obtain BTNR. 2) Why do you need a length octet at the front of the message ? Can't you (or shouldn't you) put a Content-Length in the MIME headers for this MIME part ? 3) I think given the short length of the messages you could get away with mandating that segmented DPNSS messages should always be reassembled before encapsulating in SIP and that receivers must be able to receive such reassembled messages. This removes some unnecessary complexity. 4) Section 3, under table 1, you say 'Floating Point' when you mean 'Decimal'. I think the words 'contiguously increasing' could probably be removed here too. You will have trouble finding the next real number after 6.00! Regards...Mark -----Original Message----- From: Ranjith Mukundan [mailto:ranjith.mukundan@wipro.com] Sent: 11 February 2003 08:59 To: sipping@ietf.org Subject: [Sipping] QSIG Vs DPNSS MIME we'd appreciate some views on this draft from atleast those who fairly understand QSIG. of course, others who feel that this MIME type collides directly with the purpose of SIP are encouraged to provide alternatives bearing in mind that providing complete end-to-end service transparency over the intervening SIP based core would be essential, if we are to provide a seamless migration path from H.323 based core networks - which already provide equivalent mechanisms for DSS1 based protocols. - ranjith.. -----Original Message----- From: Ranjith Mukundan Sent: Sat 2/8/2003 12:09 AM To: sipping@ietf.org Cc: Subject: RE: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-01.txt Hi, posting WRT http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-01.txt >> >> Why is it so important to be able to tunnel DPNSS in SIP? I'd prefer >> that folks implement a translation to SIP, where SIP can natively carry >> all the information that DPNSS is trying to convey. >> To put things in perspective: 1- DPNSS is a protocol (deployed primarily in UK, NZ, Australia and parts of NA) very similar to QSIG (deployed primarily Europe) for interconnecting PBXs or centrex customers hosted off LEs. DPNSS (like QSIG) finds enormous application towards realizing a local VPN or network-wide VPN services. 2- This draft aims to do exactly what RFC 3204 (MIME objects for QSIG/ISUP) does for QSIG with appropriate/relevant customization for DPNSS - i.e., to provide end-to-end & *complete*, DPNSS Service transparency between pockets of DPNSS based private networks over a SIP based core. 3- Currently, circuit-switched SS7 based cores, provide equivalent DPNSS tunneling mechanisms through (ETSI & ANSI) ISUP *apart from* the concomitant translation/interworking mechanisms to ISUP. The translation/interworking mechanism to ISUP is limited to the basic call and certain ISUP supplementary services where there is a direct/easy equivalent. 4- H.323 also provides equivalent tunneling mechanisms (via the H.450 Annexe procedures) for transparently carrying DSS1 based signaling between DSS1-based network elements/gateways, over a H.323 core. Some specifics: 1- DPNSS supports, as specified in BTNR 188, approximately 240+ supplementary features/services (like Call Back When Free, Call Back When Next Used, Executive Intrusion, Travelling Class of Service, Do Not Disturb, Night Service, Private Network Route Optimization, Centralized Operator, Three Party Takeover, Remote Diversion Registration etc). It would be almost impossible to interwork to equivalent mechanisms in SIP, without losing the service transparency when using an intervening SIP based core. 2- Yes, we definitely need an interworking/translation mechanism to map all the basic call/service paremeters, and procedures for mapping the messages. But this does not preclude the need for a DPNSS MIME type, but would rather be complimentary to the MIME type mechanism. Similar to http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-00.txt , for QSIG, we are in the process of putting together an interworking draft for DPNSS as well - but rather than making it DPNSS specific, we are trying to make it a common draft to cover PRI, DPNSS & DASS2 [as Q.SIG interworking is already a SIPPING WG ID]. Note that, PRI and DASS2 will not need a MIME type as these are, as one might be aware, for PSTN access, unlike DPNSS and QSIG (which are private network protocols). 3- From the SIP perspective, carrying non-SIP applications as MIME objects to ensure end to end service transparency is architecturally less appalling than, say for e.g., tunneling DSS1 protocols in H.323 based network - so the SIP DPNSS MIME proposition as per this I-D is the obvious way forward for DPNSS service transparency over a SIP based core, especially now that we see acute deployment needs to be met. cheers, ranjith.. > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf > Of > Ranjith Mukundan > Sent: Tuesday, February 04, 2003 5:32 PM > To: sipping@ietf.org > Subject: RE: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-01.txt > > > Hi List, > We would like you take a look at this draft and revert with any > comments/queries that you might have. > > SIPPING Chairs, > The authors feel that the requirement and the need for this MIME type > is > quite acute. Hence we'd like you to consider this for inclusion as a > WG I-D > and suggest the way forward. > > - ranjith.. > > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf > Of > Internet-Drafts@ietf.org > Sent: Tuesday, February 04, 2003 5:14 PM > To: IETF-Announce: > Cc: sipping@ietf.org > Subject: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : MIME media types for DPNSS Objects > Author(s) : R. Mukundan et al. > Filename : draft-mukundan-sipping-dpnss-01.txt > Pages : 9 > Date : 2003-2-3 > > This document describes Multipart Internet Mail Extensions (MIME) type > for application/Digital Private Network Signaling System (DPNSS) > objects for use in Session Initiation Protocol (SIP) applications, > according to the rules defined in RFC 2048. These types can be used to > identify Digital Private Network Signaling System 1 (DPNSS 1) objects > within a SIP message such as INVITE or INFO, as might be implemented > when using SIP in an environment where part of the call involves > interworking to DPNSS 1 based Private Networks. RFC 3204 addresses a > similar need for Integrated Service Digital Network User Part (ISUP) > and Q Signaling (QSIG). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-01.tx > t > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-mukundan-sipping-dpnss-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-mukundan-sipping-dpnss-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 ------=_NextPart_000_007D_01C2D276.8701EF20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable QSIG Vs DPNSS MIME
in so=20 far as inter-PBX/Centrex connectivity goes, amongst the DSS1 derived = protocols,=20 DPNSS is, IMO, the *only*  (big) missing piece. Can anyone think of = another, standards-based, telephony signaling, the might require a MIME=20 carriage?? (atleast, i can't think of any - not even an arcane, = minimally=20 deployed one)
 
As I=20 mentioned earlier, we dont need MIME types for protocols like DASS2, PRI = and all=20 the other 'conceivable sort' of telephony signaling thats used for PSTN=20 connectivity (vis-a-vis inter-PBX/centrex connectivity).  Even in = the case=20 of telephony protocols used for inter-PBX/centrex connectivity, unless = it=20 requires the same end to end, complete service transparency as in the = case of=20 private networks interconnected by QSIG or DPNSS, it does not=20 mandate carriage as MIME type (a simple interworking function = to SIP=20 would suffice).  
 
So I=20 dont think we'll a slew of MIME types...
 
>> In any event, as another = nit, this=20 document should not define the Content-Disposition header, it should = reference=20 the definition and BNF in RFC3204.
Should've known. thanks - it was = an=20 oversight.
 
cheers,
-=20 ranjith..
-----Original Message-----
From: = sipping-admin@ietf.org=20 [mailto:sipping-admin@ietf.org]On Behalf Of Peterson,=20 Jon
Sent: Wednesday, February 12, 2003 1:28 AM
To: = 'Mark=20 Watson'; sipping@ietf.org
Subject: RE: [Sipping] QSIG Vs = DPNSS=20 MIME

 
I=20 begin to sympathize with those who argued that the ISUP/QSIG MIME type = should=20 have been a more open-ended envelope for telephony signaling = information. I am=20 reluctant to standardize every conceivable sort of telephony signaling = as a=20 MIME type with some profile information for encapsulating it in=20 SIP.
 
I=20 suppose the question really is one of how great the need is to = standardize=20 this DPNSS encapsulation. I'm not really familiar with it, so I don't = have=20 much of an opinion either way.
 
In=20 any event, as another nit, this document should not define the=20 Content-Disposition header, it should reference the definition and BNF = in=20 RFC3204.
 
Jon=20 Peterson
NeuStar, Inc.
-----Original Message-----
From: Mark Watson=20 [mailto:mwatson@nortelnetworks.com]
Sent: Tuesday, = February 11,=20 2003 9:29 AM
To: sipping@ietf.org
Subject: RE: = [Sipping]=20 QSIG Vs DPNSS MIME

All,
 
I really can't see any difference between = DPNSS and=20 Q.SIG when it comes to the need for a MIME type for carriage of this = within=20 SIP. Can anyone come up with an argument for/against this draft = which does=20 not apply to Q.SIG just as well ?
 
If not, then I certainly think this = should be=20 progressed.
 
I have some comments on the=20 draft:
1) DPNSS has now been published by the = UK's Network=20 Interoperability Consultative Committee as NICC Document = 1301:2001/03. You=20 can find it at http://www.oftel.gov.uk/ind_groups/nicc/Public/interconnects= tandards/isc.htm along=20 with lots of other gems.
 
You should reference this version, rather = than the=20 somewhat harder to obtain BTNR.
 
2) Why do you need a length octet at the = front of=20 the message ? Can't you (or shouldn't you) put a Content-Length in = the MIME=20 headers for this MIME part ?
3) I think given the short length of the = messages=20 you could get away with mandating that segmented DPNSS messages = should=20 always be reassembled before encapsulating in SIP and that receivers = must be=20 able to receive such reassembled messages. This removes some = unnecessary=20 complexity.
4) Section 3, under table 1, you say = 'Floating=20 Point' when you mean 'Decimal'. I think the words 'contiguously = increasing'=20 could probably be removed here too. You will have trouble finding = the next=20 real number after 6.00!
 
Regards...Mark
 
-----Original Message-----
From: Ranjith = Mukundan=20 [mailto:ranjith.mukundan@wipro.com]
Sent: 11 February = 2003=20 08:59
To: sipping@ietf.org
Subject: [Sipping] = QSIG Vs=20 DPNSS MIME

we'd appreciate some views on this draft from = atleast=20 those who fairly understand QSIG.

of course, others who = feel that=20 this MIME type collides directly with the purpose of SIP are = encouraged to=20 provide alternatives bearing in mind that providing complete = end-to-end=20 service transparency over the intervening SIP based core would be=20 essential, if we are to provide a seamless migration path from = H.323 based=20 core networks - which already provide equivalent mechanisms for = DSS1 based=20 protocols.

- ranjith..


-----Original=20 Message-----
From:   Ranjith = Mukundan
Sent:  =20 Sat 2/8/2003 12:09 AM
To:    =20 = sipping@ietf.org
Cc:    
Subject:  &n= bsp;    =20 RE: [Sipping] I-D=20 = ACTION:draft-mukundan-sipping-dpnss-01.txt

Hi,

posting WRT = http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-= 01.txt


>>
>>=20 Why is it so important to be able to tunnel DPNSS in SIP?  = I'd=20 prefer
>> that folks implement a translation to SIP, = where SIP=20 can natively carry
>> all the information that DPNSS is = trying to=20 convey.
>>

To put things in perspective:

1- = DPNSS=20 is a protocol (deployed primarily in UK, NZ, Australia and parts = of NA)=20 very similar to QSIG (deployed primarily Europe) for = interconnecting PBXs=20 or centrex customers hosted off LEs. DPNSS (like QSIG) finds = enormous=20 application towards realizing a local VPN or network-wide VPN=20 services.

2- This draft aims to do exactly what RFC 3204 = (MIME=20 objects for QSIG/ISUP) does for QSIG with appropriate/relevant=20 customization for DPNSS - i.e., to provide end-to-end & = *complete*,=20 DPNSS Service transparency between pockets of DPNSS based private = networks=20 over a SIP based core.

3- Currently, circuit-switched SS7 = based=20 cores, provide equivalent DPNSS tunneling mechanisms through (ETSI = &=20 ANSI) ISUP *apart from* the concomitant translation/interworking=20 mechanisms to ISUP. The translation/interworking mechanism to ISUP = is=20 limited to the basic call and certain ISUP supplementary services = where=20 there is a direct/easy equivalent.

4- H.323 also provides=20 equivalent tunneling mechanisms (via the H.450 Annexe procedures) = for=20 transparently carrying DSS1 based signaling between DSS1-based = network=20 elements/gateways, over a H.323 core.

Some = specifics:

1-=20 DPNSS supports, as specified in BTNR 188, approximately 240+ = supplementary=20 features/services (like Call Back When Free, Call Back When Next = Used,=20 Executive Intrusion, Travelling Class of Service, Do Not Disturb, = Night=20 Service, Private Network Route Optimization, Centralized Operator, = Three=20 Party Takeover, Remote Diversion Registration etc). It would be = almost=20 impossible to interwork to equivalent mechanisms in SIP, without = losing=20 the service transparency when using an intervening SIP based=20 core.

2- Yes, we definitely need an = interworking/translation=20 mechanism to map all the basic call/service paremeters, and = procedures for=20 mapping the messages. But this does not preclude the need for a = DPNSS MIME=20 type, but would rather be complimentary to the MIME type = mechanism.=20 Similar to http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-00= .txt=20 , for QSIG, we are in the process of putting together an = interworking=20 draft for DPNSS as well - but rather than making it DPNSS = specific, we are=20 trying to make it a common draft to cover PRI, DPNSS & DASS2 = [as Q.SIG=20 interworking is already a SIPPING WG ID]. Note that, PRI and DASS2 = will=20 not need a MIME type as these are, as one might be aware, for PSTN = access,=20 unlike DPNSS and QSIG (which are private network = protocols).

3-=20 From the SIP perspective, carrying non-SIP applications as MIME = objects to=20 ensure end to end service transparency is architecturally less = appalling=20 than, say for e.g., tunneling DSS1 protocols in H.323 based = network - so=20 the SIP DPNSS MIME proposition as per this I-D is the obvious way = forward=20 for DPNSS service transparency over a SIP based core, especially = now that=20 we see acute deployment needs to be=20 met.

cheers,
ranjith..

> -----Original=20 Message-----
> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]= On=20 Behalf
> Of
> Ranjith Mukundan
> Sent: Tuesday, = February=20 04, 2003 5:32 PM
> To: sipping@ietf.org
> Subject: RE: = [Sipping] I-D=20 ACTION:draft-mukundan-sipping-dpnss-01.txt
>
>
> = Hi=20 List,
> We would like you take a look at this draft and = revert with=20 any
> comments/queries that you might have.
>
> = SIPPING=20 Chairs,
> The authors feel that the requirement and the need = for=20 this MIME type
> is
> quite acute. Hence we'd like you = to=20 consider this for inclusion as a
> WG I-D
> and = suggest the=20 way forward.
>
> - ranjith..
>
> = -----Original=20 Message-----
> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]= On=20 Behalf
> Of
> Internet-Drafts@ietf.org
> Sent: = Tuesday,=20 February 04, 2003 5:14 PM
> To: IETF-Announce:
> Cc:=20 sipping@ietf.org
> Subject: [Sipping] I-D=20 ACTION:draft-mukundan-sipping-dpnss-01.txt
>
>
> = A New=20 Internet-Draft is available from the on-line = Internet-Drafts
>=20 directories.
>
>
> =      =20 Title           : = MIME media=20 types for DPNSS Objects
>      =20 Author(s)       : R. Mukundan et = al.
>=20      =20 Filename        :=20 draft-mukundan-sipping-dpnss-01.txt
> =      =20 Pages           : = 9
>=20       Date   =20         : = 2003-2-3
>
> This=20 document describes Multipart Internet Mail Extensions (MIME) = type
>=20 for application/Digital Private Network Signaling System = (DPNSS)
>=20 objects for use in Session Initiation Protocol (SIP) = applications,
>=20 according to the rules defined in RFC 2048. These types can be = used=20 to
> identify Digital Private Network Signaling System 1 = (DPNSS 1)=20 objects
> within a SIP message such as INVITE or INFO, as = might be=20 implemented
> when using SIP in an environment where part of = the=20 call involves
> interworking to DPNSS 1 based Private = Networks. RFC=20 3204 addresses a
> similar need for Integrated Service = Digital=20 Network User Part (ISUP)
> and Q Signaling = (QSIG).
>
> A=20 URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-0= 1.tx
>=20 t
>
> To remove yourself from the IETF Announcement = list, send=20 a message to
> ietf-announce-request with the word = unsubscribe in=20 the body of the
> message.
>
> Internet-Drafts = are also=20 available by anonymous FTP. Login with the
> = username
>=20 "anonymous" and a password of your e-mail address. After logging=20 in,
> type "cd internet-drafts" and then
>=20       "get=20 draft-mukundan-sipping-dpnss-01.txt".
>
> A list of=20 Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html<= /A>=20 or
> ftp://ftp.ietf.org/iet= f/1shadow-sites.txt
>
>
>=20 Internet-Drafts can also be obtained by e-mail.
>
> = Send a=20 message to:
>      =20 mailserv@ietf.org.
> In the body type:
>=20       "FILE=20 = /internet-drafts/draft-mukundan-sipping-dpnss-01.txt".
>
>=20 NOTE: The mail server at ietf.org can return the document = in
>=20       MIME-encoded form by using the = "mpack"=20 utility.  To use this
>       = feature,=20 insert the command "ENCODING mime" before the "FILE"
>=20       command.  To decode the = response(s),=20 you will need "munpack" or
>       = a=20 MIME-compliant mail reader.  Different MIME-compliant mail=20 readers
>       exhibit different = behavior,=20 especially when dealing with
> =      =20 "multipart" MIME messages (i.e. documents which have been = split
>=20       up into multiple messages), so = check your=20 local documentation on
>       how = to=20 manipulate these messages.
>
>
> Below is the = data which=20 will enable a MIME compliant mail reader
> implementation to = automatically retrieve the ASCII version of the
>=20 Internet-Draft.
>
>=20 _______________________________________________
> Sipping = mailing=20 list  https://www1.ietf= .org/mailman/listinfo/sipping
>=20 This list is for NEW development of the application of SIP = Use
>=20 sip-implementors@cs.columbia.edu for questions on current sip = Use
>=20 sip@ietf.org for new developments of core=20 = SIP




_______________________________________= ________=20 Sipping mailing list = https://www1.ietf.org/mailman/listinfo/sipping This=20 list is for NEW development of the application of SIP Use=20 sip-implementors@cs.columbia.edu for questions on current sip Use=20 sip@ietf.org for new developments of core SIP=20
------=_NextPart_000_007D_01C2D276.8701EF20-- ------=_NextPartTM-000-040faa5b-3dcd-11d7-ba7f-006067005148-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Feb 12 00:28:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29234 for ; Wed, 12 Feb 2003 00:28:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1C5bRJ08708 for sipping-archive@odin.ietf.org; Wed, 12 Feb 2003 00:37:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C5bRp08704 for ; Wed, 12 Feb 2003 00:37:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29230 for ; Wed, 12 Feb 2003 00:27:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C5akp08010; Wed, 12 Feb 2003 00:36:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C5ZSp07935 for ; Wed, 12 Feb 2003 00:35:28 -0500 Received: from shardagate2.mahindrabt.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29189 for ; Wed, 12 Feb 2003 00:25:41 -0500 (EST) Received: from thisdomain (mailscan.sharda.mahindrabt.com [10.5.0.97]) by shardagate2.mahindrabt.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA19639 for ; Wed, 12 Feb 2003 10:59:00 +0530 Received: from intranet.sharda.mahindrabt.com by mahindrabt.com ; Wed, 12 Feb 2003 10:47:35 +0530 Date: Wed, 12 Feb 2003 10:47:35 +0530 X-Originating-IP: 10.5.0.15 X-Auth-User: kalele@mahindrabt.com Received: from mahindrabt.com ([10.5.4.79]) by intranet.sharda.mahindrabt.com (8.9.3/8.9.3) with ESMTP id KAA07453; Wed, 12 Feb 2003 10:59:10 +0530 Message-ID: <3E49DB24.485E7AB8@mahindrabt.com> Date: Wed, 12 Feb 2003 10:57:00 +0530 From: Ajit Kalele X-Mailer: Mozilla 4.73 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Miao, Kai" CC: sipping@ietf.org Subject: Re: [Sipping] Question about call flow in draft-ietf-sipping-service-examples-03 References: <3D90571297ABD511957400508BF29C43043EA574@pysmsx101.py.intel.com> Content-Type: multipart/alternative; boundary="------------4EBF4A7AAF468E2D6AD0E84F" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------4EBF4A7AAF468E2D6AD0E84F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I think there is an error in the call flows. Either A has to respond with an "a=inactive", so that there is no RTP flow between the UAs, or else there should be unidirectional RTP flow between the 2 UAs. Best Regards - Ajit "Miao, Kai" wrote: > Could someone provide an answer to the following question:In the > first example, Call Hold, given > in draft-ietf-sipping-service-examples-03.txt, why F10, i.e., > INVITE(hold), has a=sendonly in its SDP message and F12, i.e., 200 OK, > has no "a=" attribute at all while "No RTP Sent!" is marked in the > call flow diagram? Shoudn't F12 contain a=recvonly or a=inactive, > following the Offer/Answer model? Why there is "no RTP sent" in the > diagram when there is "a=sendonly" in F10?Thanks,Kai MiaoIntel ********************************************************* Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com --------------4EBF4A7AAF468E2D6AD0E84F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

I think there is an error in the call flows.

Either A has to respond with an "a=inactive", so that there is no RTP flow between the UAs, or else there should be unidirectional RTP flow between the 2 UAs.

Best Regards
- Ajit

"Miao, Kai" wrote:

 Could someone provide an answer to the following question:In the first example, Call Hold, given in draft-ietf-sipping-service-examples-03.txt, why F10, i.e., INVITE(hold), has a=sendonly in its SDP message and F12, i.e., 200 OK, has no "a=" attribute at all while "No RTP Sent!" is marked in the call flow diagram? Shoudn't F12 contain a=recvonly or a=inactive, following the Offer/Answer model? Why there is "no RTP sent" in the diagram when there is "a=sendonly" in F10?Thanks,Kai MiaoIntel 

*********************************************************
Disclaimer

This message (including any attachments) contains
confidential information intended for a specific
individual and purpose, and is protected by law.
If you are not the intended recipient, you should
delete this message and are hereby notified that
any disclosure, copying, or distribution of this
message, or the taking of any action based on it,
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com

--------------4EBF4A7AAF468E2D6AD0E84F-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Feb 12 00:46:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29530 for ; Wed, 12 Feb 2003 00:46:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1C5u1B09263 for sipping-archive@odin.ietf.org; Wed, 12 Feb 2003 00:56:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C5u0p09260 for ; Wed, 12 Feb 2003 00:56:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29516 for ; Wed, 12 Feb 2003 00:46:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C5tFp09237; Wed, 12 Feb 2003 00:55:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C5sPp09200 for ; Wed, 12 Feb 2003 00:54:25 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29503 for ; Wed, 12 Feb 2003 00:44:39 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.152]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h1C5mIYH023507; Wed, 12 Feb 2003 00:48:18 -0500 (EST) Message-ID: <3E49E01D.8050208@dynamicsoft.com> Date: Wed, 12 Feb 2003 00:48:13 -0500 From: Jonathan Rosenberg Organization: dynamicsoft 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: "Peterson, Jon" CC: "'Mark Watson'" , sipping@ietf.org Subject: Re: [Sipping] QSIG Vs DPNSS MIME References: <15A2739B7DAA624D8091C65981D7DA8101214DB8@stntexch2.va.neustar.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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit My two cents on this stuff (applies to QSIG too). The idea behind sip-t was that carriage of the isup bodies made sense because the semantics of the sip messages matched the isup; the isup was providing "extra" information that was simply carried in its native form. Having the semantics match is important for use of services in the SIP network. If these DPNSS bodies have a semantic different than the SIP message they are carried in (i.e., call transfer is carried in an INFO), then I think thats a bad thing and not in line with the sip-t architecture. Now, I don't know DPNSS really, so I don't know if this is what you are proposing. It is just a comment on the general direction. -Jonathan R. Peterson, Jon wrote: > > I begin to sympathize with those who argued that the ISUP/QSIG MIME type > should have been a more open-ended envelope for telephony signaling > information. I am reluctant to standardize every conceivable sort of > telephony signaling as a MIME type with some profile information for > encapsulating it in SIP. > > I suppose the question really is one of how great the need is to > standardize this DPNSS encapsulation. I'm not really familiar with it, > so I don't have much of an opinion either way. > > In any event, as another nit, this document should not define the > Content-Disposition header, it should reference the definition and BNF > in RFC3204. > > Jon Peterson > NeuStar, Inc. > > -----Original Message----- > *From:* Mark Watson [mailto:mwatson@nortelnetworks.com] > *Sent:* Tuesday, February 11, 2003 9:29 AM > *To:* sipping@ietf.org > *Subject:* RE: [Sipping] QSIG Vs DPNSS MIME > > All, > > I really can't see any difference between DPNSS and Q.SIG when it > comes to the need for a MIME type for carriage of this within SIP. > Can anyone come up with an argument for/against this draft which > does not apply to Q.SIG just as well ? > > If not, then I certainly think this should be progressed. > > I have some comments on the draft: > 1) DPNSS has now been published by the UK's Network Interoperability > Consultative Committee as NICC Document 1301:2001/03. You can find > it at > http://www.oftel.gov.uk/ind_groups/nicc/Public/interconnectstandards/isc.htm along > with lots of other gems. > > You should reference this version, rather than the somewhat harder > to obtain BTNR. > > 2) Why do you need a length octet at the front of the message ? > Can't you (or shouldn't you) put a Content-Length in the MIME > headers for this MIME part ? > 3) I think given the short length of the messages you could get away > with mandating that segmented DPNSS messages should always be > reassembled before encapsulating in SIP and that receivers must be > able to receive such reassembled messages. This removes some > unnecessary complexity. > 4) Section 3, under table 1, you say 'Floating Point' when you mean > 'Decimal'. I think the words 'contiguously increasing' could > probably be removed here too. You will have trouble finding the next > real number after 6.00! > > Regards...Mark > > > -----Original Message----- > *From:* Ranjith Mukundan [mailto:ranjith.mukundan@wipro.com] > *Sent:* 11 February 2003 08:59 > *To:* sipping@ietf.org > *Subject:* [Sipping] QSIG Vs DPNSS MIME > > we'd appreciate some views on this draft from atleast those who > fairly understand QSIG. > > of course, others who feel that this MIME type collides directly > with the purpose of SIP are encouraged to provide alternatives > bearing in mind that providing complete end-to-end service > transparency over the intervening SIP based core would be > essential, if we are to provide a seamless migration path from > H.323 based core networks - which already provide equivalent > mechanisms for DSS1 based protocols. > > - ranjith.. > > > -----Original Message----- > From: Ranjith Mukundan > Sent: Sat 2/8/2003 12:09 AM > To: sipping@ietf.org > Cc: > Subject: RE: [Sipping] I-D > ACTION:draft-mukundan-sipping-dpnss-01.txt > > Hi, > > posting WRT > http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-01.txt > > > >> > >> Why is it so important to be able to tunnel DPNSS in SIP? > I'd prefer > >> that folks implement a translation to SIP, where SIP can > natively carry > >> all the information that DPNSS is trying to convey. > >> > > To put things in perspective: > > 1- DPNSS is a protocol (deployed primarily in UK, NZ, Australia > and parts of NA) very similar to QSIG (deployed primarily > Europe) for interconnecting PBXs or centrex customers hosted off > LEs. DPNSS (like QSIG) finds enormous application towards > realizing a local VPN or network-wide VPN services. > > 2- This draft aims to do exactly what RFC 3204 (MIME objects for > QSIG/ISUP) does for QSIG with appropriate/relevant customization > for DPNSS - i.e., to provide end-to-end & *complete*, DPNSS > Service transparency between pockets of DPNSS based private > networks over a SIP based core. > > 3- Currently, circuit-switched SS7 based cores, provide > equivalent DPNSS tunneling mechanisms through (ETSI & ANSI) ISUP > *apart from* the concomitant translation/interworking mechanisms > to ISUP. The translation/interworking mechanism to ISUP is > limited to the basic call and certain ISUP supplementary > services where there is a direct/easy equivalent. > > 4- H.323 also provides equivalent tunneling mechanisms (via the > H.450 Annexe procedures) for transparently carrying DSS1 based > signaling between DSS1-based network elements/gateways, over a > H.323 core. > > Some specifics: > > 1- DPNSS supports, as specified in BTNR 188, approximately 240+ > supplementary features/services (like Call Back When Free, Call > Back When Next Used, Executive Intrusion, Travelling Class of > Service, Do Not Disturb, Night Service, Private Network Route > Optimization, Centralized Operator, Three Party Takeover, Remote > Diversion Registration etc). It would be almost impossible to > interwork to equivalent mechanisms in SIP, without losing the > service transparency when using an intervening SIP based core. > > 2- Yes, we definitely need an interworking/translation mechanism > to map all the basic call/service paremeters, and procedures for > mapping the messages. But this does not preclude the need for a > DPNSS MIME type, but would rather be complimentary to the MIME > type mechanism. Similar to > http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-00.txt > , for QSIG, we are in the process of putting together an > interworking draft for DPNSS as well - but rather than making it > DPNSS specific, we are trying to make it a common draft to cover > PRI, DPNSS & DASS2 [as Q.SIG interworking is already a SIPPING > WG ID]. Note that, PRI and DASS2 will not need a MIME type as > these are, as one might be aware, for PSTN access, unlike DPNSS > and QSIG (which are private network protocols). > > 3- From the SIP perspective, carrying non-SIP applications as > MIME objects to ensure end to end service transparency is > architecturally less appalling than, say for e.g., tunneling > DSS1 protocols in H.323 based network - so the SIP DPNSS MIME > proposition as per this I-D is the obvious way forward for DPNSS > service transparency over a SIP based core, especially now that > we see acute deployment needs to be met. > > cheers, > ranjith.. > > > -----Original Message----- > > From: sipping-admin@ietf.org > [mailto:sipping-admin@ietf.org]On Behalf > > Of > > Ranjith Mukundan > > Sent: Tuesday, February 04, 2003 5:32 PM > > To: sipping@ietf.org > > Subject: RE: [Sipping] I-D > ACTION:draft-mukundan-sipping-dpnss-01.txt > > > > > > Hi List, > > We would like you take a look at this draft and revert with any > > comments/queries that you might have. > > > > SIPPING Chairs, > > The authors feel that the requirement and the need for this > MIME type > > is > > quite acute. Hence we'd like you to consider this for > inclusion as a > > WG I-D > > and suggest the way forward. > > > > - ranjith.. > > > > -----Original Message----- > > From: sipping-admin@ietf.org > [mailto:sipping-admin@ietf.org]On Behalf > > Of > > Internet-Drafts@ietf.org > > Sent: Tuesday, February 04, 2003 5:14 PM > > To: IETF-Announce: > > Cc: sipping@ietf.org > > Subject: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-01.txt > > > > > > A New Internet-Draft is available from the on-line > Internet-Drafts > > directories. > > > > > > Title : MIME media types for DPNSS Objects > > Author(s) : R. Mukundan et al. > > Filename : draft-mukundan-sipping-dpnss-01.txt > > Pages : 9 > > Date : 2003-2-3 > > > > This document describes Multipart Internet Mail Extensions > (MIME) type > > for application/Digital Private Network Signaling System (DPNSS) > > objects for use in Session Initiation Protocol (SIP) > applications, > > according to the rules defined in RFC 2048. These types can > be used to > > identify Digital Private Network Signaling System 1 (DPNSS 1) > objects > > within a SIP message such as INVITE or INFO, as might be > implemented > > when using SIP in an environment where part of the call involves > > interworking to DPNSS 1 based Private Networks. RFC 3204 > addresses a > > similar need for Integrated Service Digital Network User Part > (ISUP) > > and Q Signaling (QSIG). > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-01.tx > > t > > > > To remove yourself from the IETF Announcement list, send a > message to > > ietf-announce-request with the word unsubscribe in the body > of the > > message. > > > > Internet-Drafts are also available by anonymous FTP. Login > with the > > username > > "anonymous" and a password of your e-mail address. After > logging in, > > type "cd internet-drafts" and then > > "get draft-mukundan-sipping-dpnss-01.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE > /internet-drafts/draft-mukundan-sipping-dpnss-01.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use > this > > feature, insert the command "ENCODING mime" before the > "FILE" > > command. To decode the response(s), you will need > "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant > mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have > been split > > up into multiple messages), so check your local > documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > _______________________________________________ > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sip@ietf.org for new developments of core SIP > > > > > _______________________________________________ Sipping mailing > list https://www1.ietf.org/mailman/listinfo/sipping This list is > for NEW development of the application of SIP Use > sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Feb 12 00:51:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29601 for ; Wed, 12 Feb 2003 00:51:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1C60Vc09504 for sipping-archive@odin.ietf.org; Wed, 12 Feb 2003 01:00:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C60Vp09501 for ; Wed, 12 Feb 2003 01:00:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29590 for ; Wed, 12 Feb 2003 00:50:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C603p09483; Wed, 12 Feb 2003 01:00:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C5xWp09415 for ; Wed, 12 Feb 2003 00:59:32 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29587 for ; Wed, 12 Feb 2003 00:49:47 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.152]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h1C5rYYH023513 for ; Wed, 12 Feb 2003 00:53:34 -0500 (EST) Message-ID: <3E49E159.3060103@dynamicsoft.com> Date: Wed, 12 Feb 2003 00:53:29 -0500 From: Jonathan Rosenberg Organization: dynamicsoft 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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] updated conferencing framework Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, I've submitted an update to the conferencing framework document. THis is the result of a lot of work of the conferencing design team to make things consistent across documents, and to resolve hard problems like how sidebars are handled. Until it appears in the archives you can pick up a copy at: http://www.jdrosen.net/papers/draft-rosenberg-sipping-conferencing-framework-01.txt Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Feb 12 01:05:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29828 for ; Wed, 12 Feb 2003 01:05:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1C6EkB10600 for sipping-archive@odin.ietf.org; Wed, 12 Feb 2003 01:14:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C6Ekp10597 for ; Wed, 12 Feb 2003 01:14:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29825 for ; Wed, 12 Feb 2003 01:05:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C6EGp10576; Wed, 12 Feb 2003 01:14:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C6Dqp10536 for ; Wed, 12 Feb 2003 01:13:52 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29793 for ; Wed, 12 Feb 2003 01:04:06 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.152]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h1C67sYH023523 for ; Wed, 12 Feb 2003 01:07:54 -0500 (EST) Message-ID: <3E49E4B5.8010608@dynamicsoft.com> Date: Wed, 12 Feb 2003 01:07:49 -0500 From: Jonathan Rosenberg Organization: dynamicsoft 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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] New I-D on URI leasing Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, I've just submitted an I-D on the concept of "URI leasing". THis is my proposed technique for solving the "globally routable UA URI" problem. SPecifically, for cases like REFER, how do we construct a URI that routes to a specific UA instance in a domain? At the last ietf meeting, this issue came up in several contexts. I suggested a single document to explore the problem. The chairs asked for volunteers, and I said I'd write one, time permitting, if no one else stepped up. Since no one did, well, here it is. Until it appears in the archives, you can pick it up at: http://www.jdrosen.net/papers/draft-rosenberg-sipping-lease-00.txt http://www.jdrosen.net/papers/draft-rosenberg-sipping-lease-00.html Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Feb 12 02:17:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12940 for ; Wed, 12 Feb 2003 02:17:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1C7Qgh24707 for sipping-archive@odin.ietf.org; Wed, 12 Feb 2003 02:26:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C7Qfp24704 for ; Wed, 12 Feb 2003 02:26:41 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12408 for ; Wed, 12 Feb 2003 02:16:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C7Pwp24444; Wed, 12 Feb 2003 02:25:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C7Otp24380 for ; Wed, 12 Feb 2003 02:24:55 -0500 Received: from wiprom2mx1.wipro.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10718 for ; Wed, 12 Feb 2003 02:14:59 -0500 (EST) Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id h1C7Idv19320 for ; Wed, 12 Feb 2003 12:48:39 +0530 (IST) Received: from blr-ec-msg01.wipro.com ([10.200.50.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 12 Feb 2003 12:48:34 +0530 Received: from ranjith2 ([192.168.178.234]) by blr-ec-msg01.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 12 Feb 2003 12:48:34 +0530 From: "Ranjith Mukundan" To: "Peterson, Jon" , "Jonathan Rosenberg" Cc: , "'Mark Watson'" Subject: RE: [Sipping] QSIG Vs DPNSS MIME Date: Wed, 12 Feb 2003 12:52:28 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) x-mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3E49E01D.8050208@dynamicsoft.com> Importance: Normal X-OriginalArrivalTime: 12 Feb 2003 07:18:34.0340 (UTC) FILETIME=[F4166240:01C2D266] 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In case of DPNSS too the message semantics matches SIP messages - atleast to the same extent as it does for ISUP. The primary driver for carrying the DPNSS objects is to seamlessly transfer the DPNSS supplementary service information across pockets of DPNSS private networks (including DPNSS based centrex customer groups) over an intervening SIP based core, in its native form. In fact, from the message semantics point of view (as opposed to the supplementary service procedures and info elements point of view); as far as the session setup, control and release messages go, DPNSS messages (ISRM - for setup, NAM-for alerting, CRM/CIM- for rel/rel-ack, ANS, EEM - for end to end 'pass along' messages etc) are more aligned to ISUP message semantics than perhaps to QSIG message semantics. For e.g., in case of QSIG some of the session related service messages like NOTIFY, INFORMATION, FAC - would all get carried in SIP INFO message, while in the case of DPNSS, only EEM (equivalent of PAM in ANSI ISUP) would get carried in the SIP INFO and hence finds a better semantic match to SIP messages - perhaps a better match when compared to QSIG. It's only wrt the DPNSS overlap messages and layer 3 maintenance messages (like LLM, LRM etc) that finding a semantically good message fit to SIP becomes diffucult - but equivalent constraints exists in case of ISUP overlap and maintenance messages (Blocking, Reset, Cirtuit Validation Test etc) too. We could include some typical service flows in the appendix of the this draft to reinforce the fact that DPNSS layer 3 messages does in fact render itself for a better semantic message fit with SIP. cheers, - ranjith.. -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf Of Jonathan Rosenberg Sent: Wednesday, February 12, 2003 11:18 AM To: Peterson, Jon Cc: 'Mark Watson'; sipping@ietf.org Subject: Re: [Sipping] QSIG Vs DPNSS MIME My two cents on this stuff (applies to QSIG too). The idea behind sip-t was that carriage of the isup bodies made sense because the semantics of the sip messages matched the isup; the isup was providing "extra" information that was simply carried in its native form. Having the semantics match is important for use of services in the SIP network. If these DPNSS bodies have a semantic different than the SIP message they are carried in (i.e., call transfer is carried in an INFO), then I think thats a bad thing and not in line with the sip-t architecture. Now, I don't know DPNSS really, so I don't know if this is what you are proposing. It is just a comment on the general direction. -Jonathan R. Peterson, Jon wrote: > > I begin to sympathize with those who argued that the ISUP/QSIG MIME type > should have been a more open-ended envelope for telephony signaling > information. I am reluctant to standardize every conceivable sort of > telephony signaling as a MIME type with some profile information for > encapsulating it in SIP. > > I suppose the question really is one of how great the need is to > standardize this DPNSS encapsulation. I'm not really familiar with it, > so I don't have much of an opinion either way. > > In any event, as another nit, this document should not define the > Content-Disposition header, it should reference the definition and BNF > in RFC3204. > > Jon Peterson > NeuStar, Inc. > > -----Original Message----- > *From:* Mark Watson [mailto:mwatson@nortelnetworks.com] > *Sent:* Tuesday, February 11, 2003 9:29 AM > *To:* sipping@ietf.org > *Subject:* RE: [Sipping] QSIG Vs DPNSS MIME > > All, > > I really can't see any difference between DPNSS and Q.SIG when it > comes to the need for a MIME type for carriage of this within SIP. > Can anyone come up with an argument for/against this draft which > does not apply to Q.SIG just as well ? > > If not, then I certainly think this should be progressed. > > I have some comments on the draft: > 1) DPNSS has now been published by the UK's Network Interoperability > Consultative Committee as NICC Document 1301:2001/03. You can find > it at > http://www.oftel.gov.uk/ind_groups/nicc/Public/interconnectstandards/isc.htm along > with lots of other gems. > > You should reference this version, rather than the somewhat harder > to obtain BTNR. > > 2) Why do you need a length octet at the front of the message ? > Can't you (or shouldn't you) put a Content-Length in the MIME > headers for this MIME part ? > 3) I think given the short length of the messages you could get away > with mandating that segmented DPNSS messages should always be > reassembled before encapsulating in SIP and that receivers must be > able to receive such reassembled messages. This removes some > unnecessary complexity. > 4) Section 3, under table 1, you say 'Floating Point' when you mean > 'Decimal'. I think the words 'contiguously increasing' could > probably be removed here too. You will have trouble finding the next > real number after 6.00! > > Regards...Mark > > > -----Original Message----- > *From:* Ranjith Mukundan [mailto:ranjith.mukundan@wipro.com] > *Sent:* 11 February 2003 08:59 > *To:* sipping@ietf.org > *Subject:* [Sipping] QSIG Vs DPNSS MIME > > we'd appreciate some views on this draft from atleast those who > fairly understand QSIG. > > of course, others who feel that this MIME type collides directly > with the purpose of SIP are encouraged to provide alternatives > bearing in mind that providing complete end-to-end service > transparency over the intervening SIP based core would be > essential, if we are to provide a seamless migration path from > H.323 based core networks - which already provide equivalent > mechanisms for DSS1 based protocols. > > - ranjith.. > > > -----Original Message----- > From: Ranjith Mukundan > Sent: Sat 2/8/2003 12:09 AM > To: sipping@ietf.org > Cc: > Subject: RE: [Sipping] I-D > ACTION:draft-mukundan-sipping-dpnss-01.txt > > Hi, > > posting WRT > http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-01.txt > > > >> > >> Why is it so important to be able to tunnel DPNSS in SIP? > I'd prefer > >> that folks implement a translation to SIP, where SIP can > natively carry > >> all the information that DPNSS is trying to convey. > >> > > To put things in perspective: > > 1- DPNSS is a protocol (deployed primarily in UK, NZ, Australia > and parts of NA) very similar to QSIG (deployed primarily > Europe) for interconnecting PBXs or centrex customers hosted off > LEs. DPNSS (like QSIG) finds enormous application towards > realizing a local VPN or network-wide VPN services. > > 2- This draft aims to do exactly what RFC 3204 (MIME objects for > QSIG/ISUP) does for QSIG with appropriate/relevant customization > for DPNSS - i.e., to provide end-to-end & *complete*, DPNSS > Service transparency between pockets of DPNSS based private > networks over a SIP based core. > > 3- Currently, circuit-switched SS7 based cores, provide > equivalent DPNSS tunneling mechanisms through (ETSI & ANSI) ISUP > *apart from* the concomitant translation/interworking mechanisms > to ISUP. The translation/interworking mechanism to ISUP is > limited to the basic call and certain ISUP supplementary > services where there is a direct/easy equivalent. > > 4- H.323 also provides equivalent tunneling mechanisms (via the > H.450 Annexe procedures) for transparently carrying DSS1 based > signaling between DSS1-based network elements/gateways, over a > H.323 core. > > Some specifics: > > 1- DPNSS supports, as specified in BTNR 188, approximately 240+ > supplementary features/services (like Call Back When Free, Call > Back When Next Used, Executive Intrusion, Travelling Class of > Service, Do Not Disturb, Night Service, Private Network Route > Optimization, Centralized Operator, Three Party Takeover, Remote > Diversion Registration etc). It would be almost impossible to > interwork to equivalent mechanisms in SIP, without losing the > service transparency when using an intervening SIP based core. > > 2- Yes, we definitely need an interworking/translation mechanism > to map all the basic call/service paremeters, and procedures for > mapping the messages. But this does not preclude the need for a > DPNSS MIME type, but would rather be complimentary to the MIME > type mechanism. Similar to > http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-00.txt > , for QSIG, we are in the process of putting together an > interworking draft for DPNSS as well - but rather than making it > DPNSS specific, we are trying to make it a common draft to cover > PRI, DPNSS & DASS2 [as Q.SIG interworking is already a SIPPING > WG ID]. Note that, PRI and DASS2 will not need a MIME type as > these are, as one might be aware, for PSTN access, unlike DPNSS > and QSIG (which are private network protocols). > > 3- From the SIP perspective, carrying non-SIP applications as > MIME objects to ensure end to end service transparency is > architecturally less appalling than, say for e.g., tunneling > DSS1 protocols in H.323 based network - so the SIP DPNSS MIME > proposition as per this I-D is the obvious way forward for DPNSS > service transparency over a SIP based core, especially now that > we see acute deployment needs to be met. > > cheers, > ranjith.. > > > -----Original Message----- > > From: sipping-admin@ietf.org > [mailto:sipping-admin@ietf.org]On Behalf > > Of > > Ranjith Mukundan > > Sent: Tuesday, February 04, 2003 5:32 PM > > To: sipping@ietf.org > > Subject: RE: [Sipping] I-D > ACTION:draft-mukundan-sipping-dpnss-01.txt > > > > > > Hi List, > > We would like you take a look at this draft and revert with any > > comments/queries that you might have. > > > > SIPPING Chairs, > > The authors feel that the requirement and the need for this > MIME type > > is > > quite acute. Hence we'd like you to consider this for > inclusion as a > > WG I-D > > and suggest the way forward. > > > > - ranjith.. > > > > -----Original Message----- > > From: sipping-admin@ietf.org > [mailto:sipping-admin@ietf.org]On Behalf > > Of > > Internet-Drafts@ietf.org > > Sent: Tuesday, February 04, 2003 5:14 PM > > To: IETF-Announce: > > Cc: sipping@ietf.org > > Subject: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-01.txt > > > > > > A New Internet-Draft is available from the on-line > Internet-Drafts > > directories. > > > > > > Title : MIME media types for DPNSS Objects > > Author(s) : R. Mukundan et al. > > Filename : draft-mukundan-sipping-dpnss-01.txt > > Pages : 9 > > Date : 2003-2-3 > > > > This document describes Multipart Internet Mail Extensions > (MIME) type > > for application/Digital Private Network Signaling System (DPNSS) > > objects for use in Session Initiation Protocol (SIP) > applications, > > according to the rules defined in RFC 2048. These types can > be used to > > identify Digital Private Network Signaling System 1 (DPNSS 1) > objects > > within a SIP message such as INVITE or INFO, as might be > implemented > > when using SIP in an environment where part of the call involves > > interworking to DPNSS 1 based Private Networks. RFC 3204 > addresses a > > similar need for Integrated Service Digital Network User Part > (ISUP) > > and Q Signaling (QSIG). > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-01.tx > > t > > > > To remove yourself from the IETF Announcement list, send a > message to > > ietf-announce-request with the word unsubscribe in the body > of the > > message. > > > > Internet-Drafts are also available by anonymous FTP. Login > with the > > username > > "anonymous" and a password of your e-mail address. After > logging in, > > type "cd internet-drafts" and then > > "get draft-mukundan-sipping-dpnss-01.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE > /internet-drafts/draft-mukundan-sipping-dpnss-01.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use > this > > feature, insert the command "ENCODING mime" before the > "FILE" > > command. To decode the response(s), you will need > "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant > mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have > been split > > up into multiple messages), so check your local > documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > _______________________________________________ > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sip@ietf.org for new developments of core SIP > > > > > _______________________________________________ Sipping mailing > list https://www1.ietf.org/mailman/listinfo/sipping This list is > for NEW development of the application of SIP Use > sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Feb 12 04:11:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26860 for ; Wed, 12 Feb 2003 04:11:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1C9KtS31777 for sipping-archive@odin.ietf.org; Wed, 12 Feb 2003 04:20:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C9Ktp31774 for ; Wed, 12 Feb 2003 04:20:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26801 for ; Wed, 12 Feb 2003 04:11:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C9Jwp31711; Wed, 12 Feb 2003 04:19:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1C9IWp31674 for ; Wed, 12 Feb 2003 04:18:32 -0500 Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26764 for ; Wed, 12 Feb 2003 04:08:40 -0500 (EST) Received: from znsgy0k8.europe.nortel.com (znsgy0k8.europe.nortel.com [47.165.24.67]) by znsgs01r.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h1C9CCU10359; Wed, 12 Feb 2003 09:12:13 GMT Received: from zwcwc012.europe.nortel.com ([47.160.46.124]) by znsgy0k8.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1NZ7PRT2; Wed, 12 Feb 2003 09:12:13 -0000 Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1LVB5NHV>; Wed, 12 Feb 2003 09:10:38 -0000 Message-ID: X-Sybari-Space: 00000000 00000000 00000000 From: "Mark Watson" To: "'Ranjith Mukundan'" , "Peterson, Jon" , sipping@ietf.org Subject: RE: [Sipping] QSIG Vs DPNSS MIME Date: Wed, 12 Feb 2003 09:10:38 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D276.1D7C8970" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2D276.1D7C8970 Content-Type: text/plain; charset="iso-8859-1" I can't think of any other telephony signalling protocols which would warrent MIME encapsulation in SIP either. Service Transparency is only an issue when it's a peer-to-peer protocol that you are considering (if it's not peer-to-peer e.g. DSS1, then there's no transparency concept in the original protocol to be carried over into SIP - every node needs to understand every feature, in which case a SIP gateway can interwork to appropriate SIP features or correctly terminate the feature on the telephony side). National legacy PSTN signalling aside, the only standard public network signalling is ISUP. The only standard private network signalling systems that I know of are Q.SIG and DPNSS. Of coure there are lot of proprietary ones, but I don't think we should consider MIME types for these. ...Mark -----Original Message----- From: Ranjith Mukundan [mailto:ranjith.mukundan@wipro.com] Sent: 12 February 2003 03:40 To: Peterson, Jon; Watson, Mark [MOP:EP10:EXCH]; sipping@ietf.org Subject: RE: [Sipping] QSIG Vs DPNSS MIME in so far as inter-PBX/Centrex connectivity goes, amongst the DSS1 derived protocols, DPNSS is, IMO, the *only* (big) missing piece. Can anyone think of another, standards-based, telephony signaling, the might require a MIME carriage?? (atleast, i can't think of any - not even an arcane, minimally deployed one) As I mentioned earlier, we dont need MIME types for protocols like DASS2, PRI and all the other 'conceivable sort' of telephony signaling thats used for PSTN connectivity (vis-a-vis inter-PBX/centrex connectivity). Even in the case of telephony protocols used for inter-PBX/centrex connectivity, unless it requires the same end to end, complete service transparency as in the case of private networks interconnected by QSIG or DPNSS, it does not mandate carriage as MIME type (a simple interworking function to SIP would suffice). So I dont think we'll a slew of MIME types... >> In any event, as another nit, this document should not define the Content-Disposition header, it should reference the definition and BNF in RFC3204. Should've known. thanks - it was an oversight. cheers, - ranjith.. -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf Of Peterson, Jon Sent: Wednesday, February 12, 2003 1:28 AM To: 'Mark Watson'; sipping@ietf.org Subject: RE: [Sipping] QSIG Vs DPNSS MIME I begin to sympathize with those who argued that the ISUP/QSIG MIME type should have been a more open-ended envelope for telephony signaling information. I am reluctant to standardize every conceivable sort of telephony signaling as a MIME type with some profile information for encapsulating it in SIP. I suppose the question really is one of how great the need is to standardize this DPNSS encapsulation. I'm not really familiar with it, so I don't have much of an opinion either way. In any event, as another nit, this document should not define the Content-Disposition header, it should reference the definition and BNF in RFC3204. Jon Peterson NeuStar, Inc. -----Original Message----- From: Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: Tuesday, February 11, 2003 9:29 AM To: sipping@ietf.org Subject: RE: [Sipping] QSIG Vs DPNSS MIME All, I really can't see any difference between DPNSS and Q.SIG when it comes to the need for a MIME type for carriage of this within SIP. Can anyone come up with an argument for/against this draft which does not apply to Q.SIG just as well ? If not, then I certainly think this should be progressed. I have some comments on the draft: 1) DPNSS has now been published by the UK's Network Interoperability Consultative Committee as NICC Document 1301:2001/03. You can find it at http://www.oftel.gov.uk/ind_groups/nicc/Public/interconnectstandards/isc.htm along with lots of other gems. You should reference this version, rather than the somewhat harder to obtain BTNR. 2) Why do you need a length octet at the front of the message ? Can't you (or shouldn't you) put a Content-Length in the MIME headers for this MIME part ? 3) I think given the short length of the messages you could get away with mandating that segmented DPNSS messages should always be reassembled before encapsulating in SIP and that receivers must be able to receive such reassembled messages. This removes some unnecessary complexity. 4) Section 3, under table 1, you say 'Floating Point' when you mean 'Decimal'. I think the words 'contiguously increasing' could probably be removed here too. You will have trouble finding the next real number after 6.00! Regards...Mark -----Original Message----- From: Ranjith Mukundan [mailto:ranjith.mukundan@wipro.com] Sent: 11 February 2003 08:59 To: sipping@ietf.org Subject: [Sipping] QSIG Vs DPNSS MIME we'd appreciate some views on this draft from atleast those who fairly understand QSIG. of course, others who feel that this MIME type collides directly with the purpose of SIP are encouraged to provide alternatives bearing in mind that providing complete end-to-end service transparency over the intervening SIP based core would be essential, if we are to provide a seamless migration path from H.323 based core networks - which already provide equivalent mechanisms for DSS1 based protocols. - ranjith.. -----Original Message----- From: Ranjith Mukundan Sent: Sat 2/8/2003 12:09 AM To: sipping@ietf.org Cc: Subject: RE: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-01.txt Hi, posting WRT http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-01.txt >> >> Why is it so important to be able to tunnel DPNSS in SIP? I'd prefer >> that folks implement a translation to SIP, where SIP can natively carry >> all the information that DPNSS is trying to convey. >> To put things in perspective: 1- DPNSS is a protocol (deployed primarily in UK, NZ, Australia and parts of NA) very similar to QSIG (deployed primarily Europe) for interconnecting PBXs or centrex customers hosted off LEs. DPNSS (like QSIG) finds enormous application towards realizing a local VPN or network-wide VPN services. 2- This draft aims to do exactly what RFC 3204 (MIME objects for QSIG/ISUP) does for QSIG with appropriate/relevant customization for DPNSS - i.e., to provide end-to-end & *complete*, DPNSS Service transparency between pockets of DPNSS based private networks over a SIP based core. 3- Currently, circuit-switched SS7 based cores, provide equivalent DPNSS tunneling mechanisms through (ETSI & ANSI) ISUP *apart from* the concomitant translation/interworking mechanisms to ISUP. The translation/interworking mechanism to ISUP is limited to the basic call and certain ISUP supplementary services where there is a direct/easy equivalent. 4- H.323 also provides equivalent tunneling mechanisms (via the H.450 Annexe procedures) for transparently carrying DSS1 based signaling between DSS1-based network elements/gateways, over a H.323 core. Some specifics: 1- DPNSS supports, as specified in BTNR 188, approximately 240+ supplementary features/services (like Call Back When Free, Call Back When Next Used, Executive Intrusion, Travelling Class of Service, Do Not Disturb, Night Service, Private Network Route Optimization, Centralized Operator, Three Party Takeover, Remote Diversion Registration etc). It would be almost impossible to interwork to equivalent mechanisms in SIP, without losing the service transparency when using an intervening SIP based core. 2- Yes, we definitely need an interworking/translation mechanism to map all the basic call/service paremeters, and procedures for mapping the messages. But this does not preclude the need for a DPNSS MIME type, but would rather be complimentary to the MIME type mechanism. Similar to http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-00.txt , for QSIG, we are in the process of putting together an interworking draft for DPNSS as well - but rather than making it DPNSS specific, we are trying to make it a common draft to cover PRI, DPNSS & DASS2 [as Q.SIG interworking is already a SIPPING WG ID]. Note that, PRI and DASS2 will not need a MIME type as these are, as one might be aware, for PSTN access, unlike DPNSS and QSIG (which are private network protocols). 3- From the SIP perspective, carrying non-SIP applications as MIME objects to ensure end to end service transparency is architecturally less appalling than, say for e.g., tunneling DSS1 protocols in H.323 based network - so the SIP DPNSS MIME proposition as per this I-D is the obvious way forward for DPNSS service transparency over a SIP based core, especially now that we see acute deployment needs to be met. cheers, ranjith.. > -----Original Message----- > From: sipping-admin@ietf.org [ mailto:sipping-admin@ietf.org ]On Behalf > Of > Ranjith Mukundan > Sent: Tuesday, February 04, 2003 5:32 PM > To: sipping@ietf.org > Subject: RE: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-01.txt > > > Hi List, > We would like you take a look at this draft and revert with any > comments/queries that you might have. > > SIPPING Chairs, > The authors feel that the requirement and the need for this MIME type > is > quite acute. Hence we'd like you to consider this for inclusion as a > WG I-D > and suggest the way forward. > > - ranjith.. > > -----Original Message----- > From: sipping-admin@ietf.org [ mailto:sipping-admin@ietf.org ]On Behalf > Of > Internet-Drafts@ietf.org > Sent: Tuesday, February 04, 2003 5:14 PM > To: IETF-Announce: > Cc: sipping@ietf.org > Subject: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : MIME media types for DPNSS Objects > Author(s) : R. Mukundan et al. > Filename : draft-mukundan-sipping-dpnss-01.txt > Pages : 9 > Date : 2003-2-3 > > This document describes Multipart Internet Mail Extensions (MIME) type > for application/Digital Private Network Signaling System (DPNSS) > objects for use in Session Initiation Protocol (SIP) applications, > according to the rules defined in RFC 2048. These types can be used to > identify Digital Private Network Signaling System 1 (DPNSS 1) objects > within a SIP message such as INVITE or INFO, as might be implemented > when using SIP in an environment where part of the call involves > interworking to DPNSS 1 based Private Networks. RFC 3204 addresses a > similar need for Integrated Service Digital Network User Part (ISUP) > and Q Signaling (QSIG). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-01.tx > t > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-mukundan-sipping-dpnss-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-mukundan-sipping-dpnss-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 ------_=_NextPart_001_01C2D276.1D7C8970 Content-Type: text/html; charset="iso-8859-1" QSIG Vs DPNSS MIME
I can't think of any other telephony signalling protocols which would warrent MIME encapsulation in SIP either. Service Transparency is only an issue when it's a peer-to-peer protocol that you are considering (if it's not peer-to-peer e.g. DSS1, then there's no transparency concept in the original protocol to be carried over into SIP - every node needs to understand every feature, in which case a SIP gateway can interwork to appropriate SIP features or correctly terminate the feature on the telephony side).
 
National legacy PSTN signalling aside, the only standard public network signalling is ISUP.
 
The only standard private network signalling systems that I know of are Q.SIG and DPNSS. Of coure there are lot of proprietary ones, but I don't think we should consider MIME types for these.
 
...Mark
-----Original Message-----
From: Ranjith Mukundan [mailto:ranjith.mukundan@wipro.com]
Sent: 12 February 2003 03:40
To: Peterson, Jon; Watson, Mark [MOP:EP10:EXCH]; sipping@ietf.org
Subject: RE: [Sipping] QSIG Vs DPNSS MIME

in so far as inter-PBX/Centrex connectivity goes, amongst the DSS1 derived protocols, DPNSS is, IMO, the *only*  (big) missing piece. Can anyone think of another, standards-based, telephony signaling, the might require a MIME carriage?? (atleast, i can't think of any - not even an arcane, minimally deployed one)
 
As I mentioned earlier, we dont need MIME types for protocols like DASS2, PRI and all the other 'conceivable sort' of telephony signaling thats used for PSTN connectivity (vis-a-vis inter-PBX/centrex connectivity).  Even in the case of telephony protocols used for inter-PBX/centrex connectivity, unless it requires the same end to end, complete service transparency as in the case of private networks interconnected by QSIG or DPNSS, it does not mandate carriage as MIME type (a simple interworking function to SIP would suffice).  
 
So I dont think we'll a slew of MIME types...
 
>> In any event, as another nit, this document should not define the Content-Disposition header, it should reference the definition and BNF in RFC3204.
Should've known. thanks - it was an oversight.
 
cheers,
- ranjith..
-----Original Message-----
From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf Of Peterson, Jon
Sent: Wednesday, February 12, 2003 1:28 AM
To: 'Mark Watson'; sipping@ietf.org
Subject: RE: [Sipping] QSIG Vs DPNSS MIME

 
I begin to sympathize with those who argued that the ISUP/QSIG MIME type should have been a more open-ended envelope for telephony signaling information. I am reluctant to standardize every conceivable sort of telephony signaling as a MIME type with some profile information for encapsulating it in SIP.
 
I suppose the question really is one of how great the need is to standardize this DPNSS encapsulation. I'm not really familiar with it, so I don't have much of an opinion either way.
 
In any event, as another nit, this document should not define the Content-Disposition header, it should reference the definition and BNF in RFC3204.
 
Jon Peterson
NeuStar, Inc.
-----Original Message-----
From: Mark Watson [mailto:mwatson@nortelnetworks.com]
Sent: Tuesday, February 11, 2003 9:29 AM
To: sipping@ietf.org
Subject: RE: [Sipping] QSIG Vs DPNSS MIME

All,
 
I really can't see any difference between DPNSS and Q.SIG when it comes to the need for a MIME type for carriage of this within SIP. Can anyone come up with an argument for/against this draft which does not apply to Q.SIG just as well ?
 
If not, then I certainly think this should be progressed.
 
I have some comments on the draft:
1) DPNSS has now been published by the UK's Network Interoperability Consultative Committee as NICC Document 1301:2001/03. You can find it at http://www.oftel.gov.uk/ind_groups/nicc/Public/interconnectstandards/isc.htm along with lots of other gems.
 
You should reference this version, rather than the somewhat harder to obtain BTNR.
 
2) Why do you need a length octet at the front of the message ? Can't you (or shouldn't you) put a Content-Length in the MIME headers for this MIME part ?
3) I think given the short length of the messages you could get away with mandating that segmented DPNSS messages should always be reassembled before encapsulating in SIP and that receivers must be able to receive such reassembled messages. This removes some unnecessary complexity.
4) Section 3, under table 1, you say 'Floating Point' when you mean 'Decimal'. I think the words 'contiguously increasing' could probably be removed here too. You will have trouble finding the next real number after 6.00!
 
Regards...Mark
 
-----Original Message-----
From: Ranjith Mukundan [mailto:ranjith.mukundan@wipro.com]
Sent: 11 February 2003 08:59
To: sipping@ietf.org
Subject: [Sipping] QSIG Vs DPNSS MIME

we'd appreciate some views on this draft from atleast those who fairly understand QSIG.

of course, others who feel that this MIME type collides directly with the purpose of SIP are encouraged to provide alternatives bearing in mind that providing complete end-to-end service transparency over the intervening SIP based core would be essential, if we are to provide a seamless migration path from H.323 based core networks - which already provide equivalent mechanisms for DSS1 based protocols.

- ranjith..


-----Original Message-----
From:   Ranjith Mukundan
Sent:   Sat 2/8/2003 12:09 AM
To:     sipping@ietf.org
Cc:    
Subject:        RE: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-01.txt

Hi,

posting WRT http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-01.txt


>>
>> Why is it so important to be able to tunnel DPNSS in SIP?  I'd prefer
>> that folks implement a translation to SIP, where SIP can natively carry
>> all the information that DPNSS is trying to convey.
>>

To put things in perspective:

1- DPNSS is a protocol (deployed primarily in UK, NZ, Australia and parts of NA) very similar to QSIG (deployed primarily Europe) for interconnecting PBXs or centrex customers hosted off LEs. DPNSS (like QSIG) finds enormous application towards realizing a local VPN or network-wide VPN services.

2- This draft aims to do exactly what RFC 3204 (MIME objects for QSIG/ISUP) does for QSIG with appropriate/relevant customization for DPNSS - i.e., to provide end-to-end & *complete*, DPNSS Service transparency between pockets of DPNSS based private networks over a SIP based core.

3- Currently, circuit-switched SS7 based cores, provide equivalent DPNSS tunneling mechanisms through (ETSI & ANSI) ISUP *apart from* the concomitant translation/interworking mechanisms to ISUP. The translation/interworking mechanism to ISUP is limited to the basic call and certain ISUP supplementary services where there is a direct/easy equivalent.

4- H.323 also provides equivalent tunneling mechanisms (via the H.450 Annexe procedures) for transparently carrying DSS1 based signaling between DSS1-based network elements/gateways, over a H.323 core.

Some specifics:

1- DPNSS supports, as specified in BTNR 188, approximately 240+ supplementary features/services (like Call Back When Free, Call Back When Next Used, Executive Intrusion, Travelling Class of Service, Do Not Disturb, Night Service, Private Network Route Optimization, Centralized Operator, Three Party Takeover, Remote Diversion Registration etc). It would be almost impossible to interwork to equivalent mechanisms in SIP, without losing the service transparency when using an intervening SIP based core.

2- Yes, we definitely need an interworking/translation mechanism to map all the basic call/service paremeters, and procedures for mapping the messages. But this does not preclude the need for a DPNSS MIME type, but would rather be complimentary to the MIME type mechanism. Similar to http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-00.txt , for QSIG, we are in the process of putting together an interworking draft for DPNSS as well - but rather than making it DPNSS specific, we are trying to make it a common draft to cover PRI, DPNSS & DASS2 [as Q.SIG interworking is already a SIPPING WG ID]. Note that, PRI and DASS2 will not need a MIME type as these are, as one might be aware, for PSTN access, unlike DPNSS and QSIG (which are private network protocols).

3- From the SIP perspective, carrying non-SIP applications as MIME objects to ensure end to end service transparency is architecturally less appalling than, say for e.g., tunneling DSS1 protocols in H.323 based network - so the SIP DPNSS MIME proposition as per this I-D is the obvious way forward for DPNSS service transparency over a SIP based core, especially now that we see acute deployment needs to be met.

cheers,
ranjith..

> -----Original Message-----
> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf
> Of
> Ranjith Mukundan
> Sent: Tuesday, February 04, 2003 5:32 PM
> To: sipping@ietf.org
> Subject: RE: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-01.txt
>
>
> Hi List,
> We would like you take a look at this draft and revert with any
> comments/queries that you might have.
>
> SIPPING Chairs,
> The authors feel that the requirement and the need for this MIME type
> is
> quite acute. Hence we'd like you to consider this for inclusion as a
> WG I-D
> and suggest the way forward.
>
> - ranjith..
>
> -----Original Message-----
> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf
> Of
> Internet-Drafts@ietf.org
> Sent: Tuesday, February 04, 2003 5:14 PM
> To: IETF-Announce:
> Cc: sipping@ietf.org
> Subject: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-01.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>       Title           : MIME media types for DPNSS Objects
>       Author(s)       : R. Mukundan et al.
>       Filename        : draft-mukundan-sipping-dpnss-01.txt
>       Pages           : 9
>       Date            : 2003-2-3
>
> This document describes Multipart Internet Mail Extensions (MIME) type
> for application/Digital Private Network Signaling System (DPNSS)
> objects for use in Session Initiation Protocol (SIP) applications,
> according to the rules defined in RFC 2048. These types can be used to
> identify Digital Private Network Signaling System 1 (DPNSS 1) objects
> within a SIP message such as INVITE or INFO, as might be implemented
> when using SIP in an environment where part of the call involves
> interworking to DPNSS 1 based Private Networks. RFC 3204 addresses a
> similar need for Integrated Service Digital Network User Part (ISUP)
> and Q Signaling (QSIG).
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-01.tx
> t
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the
> message.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>       "get draft-mukundan-sipping-dpnss-01.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
>       mailserv@ietf.org.
> In the body type:
>       "FILE /internet-drafts/draft-mukundan-sipping-dpnss-01.txt".
>
> NOTE: The mail server at ietf.org can return the document in
>       MIME-encoded form by using the "mpack" utility.  To use this
>       feature, insert the command "ENCODING mime" before the "FILE"
>       command.  To decode the response(s), you will need "munpack" or
>       a MIME-compliant mail reader.  Different MIME-compliant mail readers
>       exhibit different behavior, especially when dealing with
>       "multipart" MIME messages (i.e. documents which have been split
>       up into multiple messages), so check your local documentation on
>       how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the 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
------_=_NextPart_001_01C2D276.1D7C8970-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Feb 12 06:04:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28897 for ; Wed, 12 Feb 2003 06:04:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CBEJK06197 for sipping-archive@odin.ietf.org; Wed, 12 Feb 2003 06:14:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CBEJp06194 for ; Wed, 12 Feb 2003 06:14:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28880 for ; Wed, 12 Feb 2003 06:04:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CBDSp06161; Wed, 12 Feb 2003 06:13:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CBCFp06130 for ; Wed, 12 Feb 2003 06:12:15 -0500 Received: from gorilla.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28866 for ; Wed, 12 Feb 2003 06:02:23 -0500 (EST) Received: from moody.mchh.siemens.de ([139.21.205.85]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id MAA09717 for ; Wed, 12 Feb 2003 12:06:05 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de (mchh247e.mchh.siemens.de [139.21.200.57]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id MAA26989 for ; Wed, 12 Feb 2003 12:06:06 +0100 (MET) Received: by mchh247e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id <146827KY>; Wed, 12 Feb 2003 12:05:16 +0100 Message-ID: <5B788FC2CAFBD6118BAE0030848B025C01879A@LNN201E> From: Marjou Xavier To: "'sipping@ietf.org'" Subject: RE: [Sipping] updated conferencing framework Date: Wed, 12 Feb 2003 12:05:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) 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: , Hi, It seems that a sentence is not finished at the end of Page 30: If the focus in the application server receives a conference policy control command from ... Xavier Marjou -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, February 12, 2003 6:53 AM To: sipping@ietf.org Subject: [Sipping] updated conferencing framework Folks, I've submitted an update to the conferencing framework document. THis is the result of a lot of work of the conferencing design team to make things consistent across documents, and to resolve hard problems like how sidebars are handled. Until it appears in the archives you can pick up a copy at: http://www.jdrosen.net/papers/draft-rosenberg-sipping-conferencing-framework-01.txt Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Feb 12 09:26:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03508 for ; Wed, 12 Feb 2003 09:26:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CEZpq19345 for sipping-archive@odin.ietf.org; Wed, 12 Feb 2003 09:35:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CEZpp19342 for ; Wed, 12 Feb 2003 09:35:51 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03493 for ; Wed, 12 Feb 2003 09:25:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CEZ5p19322; Wed, 12 Feb 2003 09:35:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CEWEp19157 for ; Wed, 12 Feb 2003 09:32:14 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03421; Wed, 12 Feb 2003 09:22:18 -0500 (EST) Message-Id: <200302121422.JAA03421@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 12 Feb 2003 09:22:18 -0500 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-req-history-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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : SIP Generic Request History Capability û Requirements Author(s) : M. Barnes, M. Watson, C. Jennings, J. Peterson Filename : draft-ietf-sipping-req-history-02.txt Pages : 11 Date : 2003-2-11 Many services that SIP is anticipated to support require the ability to determine why and how the call arrived at a specific application. Examples of such services include (but are not limited to) sessions initiated to call centers via 'click to talk' SIP URLs on a web page, 'call history/logging' style services within intelligent 'call management' software for SIP UAs and calls to voicemail servers and call centers. While SIP implicitly provides the redirect/retarget capabilities that enable calls to be routed to chosen applications, there is currently no standard mechanism within SIP for communicating the history of such a request. This 'request history' information allows the receiving application to determine hints about how and why the call arrived at the application/user. This draft discusses the motivations in support of a mechanism for recording the 'request history', and proposes detailed requirements for such a generic 'request history' capability. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-req-history-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sipping-req-history-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sipping-req-history-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-11141349.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-req-history-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-req-history-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-11141349.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Feb 12 09:36:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03909 for ; Wed, 12 Feb 2003 09:36:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CEjlj20684 for sipping-archive@odin.ietf.org; Wed, 12 Feb 2003 09:45:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CEjlp20681 for ; Wed, 12 Feb 2003 09:45:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03885 for ; Wed, 12 Feb 2003 09:35:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CEj8p20659; Wed, 12 Feb 2003 09:45:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CEiPp20614 for ; Wed, 12 Feb 2003 09:44:25 -0500 Received: from petasus.ch.intel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03825 for ; Wed, 12 Feb 2003 09:34:27 -0500 (EST) Received: from azsmsxvs040.ch.intel.com (azsmsxvs040.ch.intel.com [10.2.248.11]) by petasus.ch.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.49 2003/01/13 19:45:39 dmccart Exp $) with SMTP id h1CEcc115763 for ; Wed, 12 Feb 2003 14:38:38 GMT Received: from azsmsx023.ch.intel.com ([10.2.248.28]) by azsmsxvs040.ch.intel.com (NAVGW 2.5.2.11) with SMTP id M2003021207381204724 ; Wed, 12 Feb 2003 07:38:12 -0700 Received: by azsmsx023.ch.intel.com with Internet Mail Service (5.5.2653.19) id <1N0BD9B1>; Wed, 12 Feb 2003 07:33:59 -0700 Message-ID: <3D90571297ABD511957400508BF29C43043EA576@pysmsx101.py.intel.com> From: "Miao, Kai" To: "'Ajit Kalele'" , "Miao, Kai" Cc: sipping@ietf.org Subject: RE: [Sipping] Question about call flow in draft-ietf-sipping-serv ice-examples-03 Date: Wed, 12 Feb 2003 07:38:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D2A4.5948FBE0" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2D2A4.5948FBE0 Content-Type: text/plain; charset="iso-8859-1" Hi Ajit, I had noticed in RFC 3264 (right after I sent my email): "If the stream to be placed on hold was previously a sendrecv media stream, it is placed on hold by marking it as sendonly. If the stream to be placed on hold was previously a recvonly media stream, it is placed on hold by marking it inactive. ......... Typically, when a user "presses" hold, the agent will generate an offer with all streams in the SDP indicating a direction of sendonly, and it will also locally mute, so that no media is sent to the far end, and no media is played out." This should explains why the example was that way.........basically it doesn't matter what the answer is because there is no stream sent from User B...... But, my question is why not make things more consistent by using "a=recvonly" (or "a=inactive") instead of the default "a=sendrecv" in the answer? What happen if the case is not stream on hold, for example, if it is changing a stream from "sendrecv" to "sendonly"? Wouldn't this type of answer cause confusion and violate the "rules" stated in RFC3264? Thanks, Kai -----Original Message----- From: Ajit Kalele [mailto:kalele@mahindrabt.com] Sent: Wednesday, February 12, 2003 12:27 AM To: Miao, Kai Cc: sipping@ietf.org Subject: Re: [Sipping] Question about call flow in draft-ietf-sipping-service-examples-03 Hi, I think there is an error in the call flows. Either A has to respond with an "a=inactive", so that there is no RTP flow between the UAs, or else there should be unidirectional RTP flow between the 2 UAs. Best Regards - Ajit "Miao, Kai" wrote: Could someone provide an answer to the following question:In the first example, Call Hold, given in draft-ietf-sipping-service-examples-03.txt, why F10, i.e., INVITE(hold), has a=sendonly in its SDP message and F12, i.e., 200 OK, has no "a=" attribute at all while "No RTP Sent!" is marked in the call flow diagram? Shoudn't F12 contain a=recvonly or a=inactive, following the Offer/Answer model? Why there is "no RTP sent" in the diagram when there is "a=sendonly" in F10?Thanks,Kai MiaoIntel ********************************************************* Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com ------_=_NextPart_001_01C2D2A4.5948FBE0 Content-Type: text/html; charset="iso-8859-1"
Hi Ajit,
 
I had noticed in RFC 3264 (right after I sent my email):
 
   "If the stream to be placed on hold was previously a sendrecv media
   stream, it is placed on hold by marking it as sendonly.  If the
   stream to be placed on hold was previously a recvonly media stream,
   it is placed on hold by marking it inactive.

   .........

   Typically, when a user "presses" hold, the agent will generate an
   offer with all streams in the SDP indicating a direction of sendonly,
   and it will also locally mute, so that no media is sent to the far
   end, and no media is played out."
 

This should explains why the example was that way.........basically it doesn't matter what the answer is because there is no stream sent from User B......
 
But, my question is why not make things more consistent by using "a=recvonly" (or "a=inactive") instead of the default "a=sendrecv" in the answer? What happen if the case is not stream on hold, for example, if it is changing a stream from "sendrecv" to "sendonly"? Wouldn't this type of answer cause confusion and violate the "rules" stated in RFC3264?
 
Thanks,
Kai  
-----Original Message-----
From: Ajit Kalele [mailto:kalele@mahindrabt.com]
Sent: Wednesday, February 12, 2003 12:27 AM
To: Miao, Kai
Cc: sipping@ietf.org
Subject: Re: [Sipping] Question about call flow in draft-ietf-sipping-service-examples-03

Hi,

I think there is an error in the call flows.

Either A has to respond with an "a=inactive", so that there is no RTP flow between the UAs, or else there should be unidirectional RTP flow between the 2 UAs.

Best Regards
- Ajit

"Miao, Kai" wrote:

 Could someone provide an answer to the following question:In the first example, Call Hold, given in draft-ietf-sipping-service-examples-03.txt, why F10, i.e., INVITE(hold), has a=sendonly in its SDP message and F12, i.e., 200 OK, has no "a=" attribute at all while "No RTP Sent!" is marked in the call flow diagram? Shoudn't F12 contain a=recvonly or a=inactive, following the Offer/Answer model? Why there is "no RTP sent" in the diagram when there is "a=sendonly" in F10?Thanks,Kai MiaoIntel 

*********************************************************
Disclaimer

This message (including any attachments) contains
confidential information intended for a specific
individual and purpose, and is protected by law.
If you are not the intended recipient, you should
delete this message and are hereby notified that
any disclosure, copying, or distribution of this
message, or the taking of any action based on it,
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com

------_=_NextPart_001_01C2D2A4.5948FBE0-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Feb 12 10:20:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05940 for ; Wed, 12 Feb 2003 10:20:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CFUG923663 for sipping-archive@odin.ietf.org; Wed, 12 Feb 2003 10:30:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CFUFp23660 for ; Wed, 12 Feb 2003 10:30:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05934 for ; Wed, 12 Feb 2003 10:20:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CFTBp23613; Wed, 12 Feb 2003 10:29:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CFSIp23488 for ; Wed, 12 Feb 2003 10:28:18 -0500 Received: from dgesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05807 for ; Wed, 12 Feb 2003 10:18:22 -0500 (EST) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0HA700I36BUWEM@firewall.wcom.com> for sipping@ietf.org; Wed, 12 Feb 2003 15:18:32 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HA700I01BUW6Z@pmismtp01.wcomnet.com>; Wed, 12 Feb 2003 15:18:32 +0000 (GMT) Received: from ajohnston.wcom.com ([166.42.41.134]) by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HA700H3DBUTZ5@pmismtp01.wcomnet.com>; Wed, 12 Feb 2003 15:18:31 +0000 (GMT) Date: Wed, 12 Feb 2003 09:18:26 -0600 From: Alan Johnston Subject: RE: [Sipping] Question about call flow in draft-ietf-sipping-serv ice-examples-03 In-reply-to: <3D90571297ABD511957400508BF29C43043EA576@pysmsx101.py.inte l.com> X-Sender: Alan.Johnston@pop.mcit.com To: "Miao, Kai" , "'Ajit Kalele'" , "Miao, Kai" Cc: sipping@ietf.org Message-id: <5.1.1.6.0.20030212091502.01ff5a08@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.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: , Hi, Thanks for the comments on the draft. You are correct - the answer to the hold offer (a=sendonly) should be a=recvonly instead of what is currently shown as sendrecv in the draft. This will be fixed in the next version of the document. Thanks, Alan Johnston WorldCom sip:alan@digitalari.com At 07:38 AM 2/12/2003 -0700, Miao, Kai wrote: >Hi Ajit, > >I had noticed in RFC 3264 (right after I sent my email): > > "If the stream to be placed on hold was previously a sendrecv media > stream, it is placed on hold by marking it as sendonly. If the > stream to be placed on hold was previously a recvonly media stream, > it is placed on hold by marking it inactive. > > ......... > > Typically, when a user "presses" hold, the agent will generate an > offer with all streams in the SDP indicating a direction of sendonly, > and it will also locally mute, so that no media is sent to the far > end, and no media is played out." > > >This should explains why the example was that way.........basically it >doesn't matter what the answer is because there is no stream sent from >User B...... > >But, my question is why not make things more consistent by using >"a=recvonly" (or "a=inactive") instead of the default "a=sendrecv" in the >answer? What happen if the case is not stream on hold, for example, if it >is changing a stream from "sendrecv" to "sendonly"? Wouldn't this type of >answer cause confusion and violate the "rules" stated in RFC3264? > >Thanks, >Kai >-----Original Message----- >From: Ajit Kalele [mailto:kalele@mahindrabt.com] >Sent: Wednesday, February 12, 2003 12:27 AM >To: Miao, Kai >Cc: sipping@ietf.org >Subject: Re: [Sipping] Question about call flow in >draft-ietf-sipping-service-examples-03 > >Hi, > >I think there is an error in the call flows. > >Either A has to respond with an "a=inactive", so that there is no RTP flow >between the UAs, or else there should be unidirectional RTP flow between >the 2 UAs. > >Best Regards >- Ajit > >"Miao, Kai" wrote: >> Could someone provide an answer to the following question:In the first >> example, Call Hold, given in draft-ietf-sipping-service-examples-03.txt, >> why F10, i.e., INVITE(hold), has a=sendonly in its SDP message and F12, >> i.e., 200 OK, has no "a=" attribute at all while "No RTP Sent!" is >> marked in the call flow diagram? Shoudn't F12 contain a=recvonly or >> a=inactive, following the Offer/Answer model? Why there is "no RTP sent" >> in the diagram when there is "a=sendonly" in F10?Thanks,Kai MiaoIntel >********************************************************* >Disclaimer > >This message (including any attachments) contains >confidential information intended for a specific >individual and purpose, and is protected by law. >If you are not the intended recipient, you should >delete this message and are hereby notified that >any disclosure, copying, or distribution of this >message, or the taking of any action based on it, >is strictly prohibited. > >********************************************************* >Visit us at http://www.mahindrabt.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 mailnull@www1.ietf.org Wed Feb 12 11:11:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07555 for ; Wed, 12 Feb 2003 11:11:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CGLAR27572 for sipping-archive@odin.ietf.org; Wed, 12 Feb 2003 11:21:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CGLAp27569 for ; Wed, 12 Feb 2003 11:21:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07546 for ; Wed, 12 Feb 2003 11:11:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CGKPp27528; Wed, 12 Feb 2003 11:20:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CGJPp27305 for ; Wed, 12 Feb 2003 11:19:25 -0500 Received: from dgesmtp01.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07532 for ; Wed, 12 Feb 2003 11:09:28 -0500 (EST) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (Iplanet MTA) with ESMTP id <0HA700FCBE4JPR@firewall.wcom.com> for sipping@ietf.org; Wed, 12 Feb 2003 16:07:31 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HA700101E3D0E@pmismtp01.wcomnet.com>; Wed, 12 Feb 2003 16:07:31 +0000 (GMT) Received: from ajohnston.wcom.com ([166.42.41.134]) by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HA700087E3W5K@pmismtp01.wcomnet.com>; Wed, 12 Feb 2003 16:07:10 +0000 (GMT) Date: Wed, 12 Feb 2003 10:07:05 -0600 From: Alan Johnston Subject: Re: [Sipping] New I-D on URI leasing In-reply-to: <3E49E4B5.8010608@dynamicsoft.com> X-Sender: Alan.Johnston@pop.mcit.com To: Jonathan Rosenberg , sipping@ietf.org Message-id: <5.1.1.6.0.20030212095910.0265b808@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.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: , Hi Jonathan, This is a useful discussion of the problem of constructing globally routable Contact URIs. However, if you re-read http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-transfer-00.txt you will see that your proposed solution is almost identical to the "device AOR" proposed in Section 7.5, with the exception of the LEASE method, which, as you mention can (and perhaps should) be done outside of SIP. Thanks, Alan Johnston WorldCom sip:alan@digitalari.com At 01:07 AM 2/12/2003 -0500, Jonathan Rosenberg wrote: >Folks, > >I've just submitted an I-D on the concept of "URI leasing". THis is my >proposed technique for solving the "globally routable UA URI" problem. >SPecifically, for cases like REFER, how do we construct a URI that routes >to a specific UA instance in a domain? At the last ietf meeting, this >issue came up in several contexts. I suggested a single document to >explore the problem. The chairs asked for volunteers, and I said I'd write >one, time permitting, if no one else stepped up. Since no one did, well, >here it is. > >Until it appears in the archives, you can pick it up at: >http://www.jdrosen.net/papers/draft-rosenberg-sipping-lease-00.txt >http://www.jdrosen.net/papers/draft-rosenberg-sipping-lease-00.html > >Thanks, >Jonathan R. >-- >Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.dynamicsoft.com > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Feb 12 12:03:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08877 for ; Wed, 12 Feb 2003 12:03:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CHCgP06468 for sipping-archive@odin.ietf.org; Wed, 12 Feb 2003 12:12:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CHCgp06465 for ; Wed, 12 Feb 2003 12:12:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08850 for ; Wed, 12 Feb 2003 12:02:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CHCAp06361; Wed, 12 Feb 2003 12:12:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CHBYp06298 for ; Wed, 12 Feb 2003 12:11:34 -0500 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08784 for ; Wed, 12 Feb 2003 12:01:35 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h1CH5HQ12854 for ; Wed, 12 Feb 2003 11:05:17 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1LNXD5X2>; Wed, 12 Feb 2003 11:05:18 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7CCFA@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'sipping@ietf.org'" Subject: FW: [Sipping] I-D ACTION:draft-ietf-sipping-req-history-02.txt Date: Wed, 12 Feb 2003 11:05:15 -0600 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Hi all, There's really only one minor change to this document: - The last paragraph in section 5 was re-worded based on Mark suggestion per the email discussion on the capturing of request history in outgoing messages: http://www.ietf.org/mail-archive/working-groups/sipping/current/msg03695.htm l John E. had suggested additional wording, but I think the one sentence captures the essence of the requirement and the additional wording is more appropriately addressed in the solution draft (which I think it now is per the updated solution draft - per my next email). There was also some minor changes to correct "funny characters", but I can see that there is still one in the title that I'll fix the next round. But, other than that, this document should be complete. Regards, Mary H. Barnes mbarnes@nortelnetworks.com 972-684-5432 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, February 12, 2003 8:22 AM Cc: sipping@ietf.org Subject: [Sipping] I-D ACTION:draft-ietf-sipping-req-history-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : SIP Generic Request History Capability û Requirements Author(s) : M. Barnes, M. Watson, C. Jennings, J. Peterson Filename : draft-ietf-sipping-req-history-02.txt Pages : 11 Date : 2003-2-11 Many services that SIP is anticipated to support require the ability to determine why and how the call arrived at a specific application. Examples of such services include (but are not limited to) sessions initiated to call centers via 'click to talk' SIP URLs on a web page, 'call history/logging' style services within intelligent 'call management' software for SIP UAs and calls to voicemail servers and call centers. While SIP implicitly provides the redirect/retarget capabilities that enable calls to be routed to chosen applications, there is currently no standard mechanism within SIP for communicating the history of such a request. This 'request history' information allows the receiving application to determine hints about how and why the call arrived at the application/user. This draft discusses the motivations in support of a mechanism for recording the 'request history', and proposes detailed requirements for such a generic 'request history' capability. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-req-history-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sipping-req-history-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sipping-req-history-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ----- To: Subject: Date: Wed, 12 Feb 2003 09:25:18 -0600 X-Mailer: Internet Mail Service (5.5.2653.19) begin 600 ATT12027 M0V]N=&5N="UT>7!E.B!M97-S86=E+V5X=&5R;F%L+6)O9'D[#0H)86-C97-S M+71Y<&4](FUA:6PM'0O<&QA:6X-"D-O;G1E;G0M240Z M"3PR,#`S+3(M,3$Q-#$S-#DN22U$0&EE=&8N;W)G/@T*#0I%3D-/1$E.1R!M M:6UE#0I&24Q%("]I;G1E; Wed, 12 Feb 2003 12:05:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CHErp06702 for sipping-archive@odin.ietf.org; Wed, 12 Feb 2003 12:14:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CHErp06699 for ; Wed, 12 Feb 2003 12:14:53 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08925 for ; Wed, 12 Feb 2003 12:04:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CHE5p06650; Wed, 12 Feb 2003 12:14:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CHDxp06591 for ; Wed, 12 Feb 2003 12:13:59 -0500 Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08899 for ; Wed, 12 Feb 2003 12:03:57 -0500 (EST) Received: from znsgy0k8.europe.nortel.com (znsgy0k8.europe.nortel.com [47.165.24.67]) by znsgs01r.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h1CH7dU04659 for ; Wed, 12 Feb 2003 17:07:39 GMT Received: from zwcwc012.europe.nortel.com ([47.160.46.124]) by znsgy0k8.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1Z6D9SMK; Wed, 12 Feb 2003 17:07:38 -0000 Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1LVB6B8H>; Wed, 12 Feb 2003 17:07:25 -0000 Message-ID: X-Sybari-Space: 00000000 00000000 00000000 From: "Mark Ashworth" To: "'Ranjith Mukundan'" Cc: sipping@ietf.org Subject: RE: [Sipping] QSIG Vs DPNSS MIME Date: Wed, 12 Feb 2003 17:07:22 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D2B9.3558CCF0" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2D2B9.3558CCF0 Content-Type: text/plain; charset="iso-8859-1" Ranjith, Seems like a reasonable thing to do. A few comments which I hope are helpful... 1) The discussion of handling segmented information might be clearer if you were to use the terminology of the DPNSS specification such as Selection Block/Selection Field and Information Block/Information Field to refer to the items being manipulated. In the case of the ISRM/SSRM, as others have already commented, you would need to distinguish between the Supplementary Information and the Destination Address which make up the Selection Block; the Supplementary Information can be safely buffered but the Destination Address needs to be handled according to overlap procedures. 2) Using that terminology might make clearer how you propose to perform the buffering. I think you are proposing to concatenate the Information Fields from a sequence of messages to assemble a complete Information Block (or segment thereof if it exceeds your 255 octet limit) with a single message type octet, although I don't see this stated explicitly. If so, then I think your example is slightly inaccurate: combining a sequence of five EEMs each of 45 octets would produce an EEM of 221 octets (as four message type octets are removed)? 3) I'm not sure there is really any need for a version number, since DPNSS has comprehensive compatibility mechanisms? Regards, Mark. -----Original Message----- From: Ranjith Mukundan [mailto:ranjith.mukundan@wipro.com] Sent: 11 February 2003 08:59 To: sipping@ietf.org Subject: [Sipping] QSIG Vs DPNSS MIME we'd appreciate some views on this draft from atleast those who fairly understand QSIG. of course, others who feel that this MIME type collides directly with the purpose of SIP are encouraged to provide alternatives bearing in mind that providing complete end-to-end service transparency over the intervening SIP based core would be essential, if we are to provide a seamless migration path from H.323 based core networks - which already provide equivalent mechanisms for DSS1 based protocols. - ranjith.. -----Original Message----- From: Ranjith Mukundan Sent: Sat 2/8/2003 12:09 AM To: sipping@ietf.org Cc: Subject: RE: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-01.txt Hi, posting WRT http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-01.txt >> >> Why is it so important to be able to tunnel DPNSS in SIP? I'd prefer >> that folks implement a translation to SIP, where SIP can natively carry >> all the information that DPNSS is trying to convey. >> To put things in perspective: 1- DPNSS is a protocol (deployed primarily in UK, NZ, Australia and parts of NA) very similar to QSIG (deployed primarily Europe) for interconnecting PBXs or centrex customers hosted off LEs. DPNSS (like QSIG) finds enormous application towards realizing a local VPN or network-wide VPN services. 2- This draft aims to do exactly what RFC 3204 (MIME objects for QSIG/ISUP) does for QSIG with appropriate/relevant customization for DPNSS - i.e., to provide end-to-end & *complete*, DPNSS Service transparency between pockets of DPNSS based private networks over a SIP based core. 3- Currently, circuit-switched SS7 based cores, provide equivalent DPNSS tunneling mechanisms through (ETSI & ANSI) ISUP *apart from* the concomitant translation/interworking mechanisms to ISUP. The translation/interworking mechanism to ISUP is limited to the basic call and certain ISUP supplementary services where there is a direct/easy equivalent. 4- H.323 also provides equivalent tunneling mechanisms (via the H.450 Annexe procedures) for transparently carrying DSS1 based signaling between DSS1-based network elements/gateways, over a H.323 core. Some specifics: 1- DPNSS supports, as specified in BTNR 188, approximately 240+ supplementary features/services (like Call Back When Free, Call Back When Next Used, Executive Intrusion, Travelling Class of Service, Do Not Disturb, Night Service, Private Network Route Optimization, Centralized Operator, Three Party Takeover, Remote Diversion Registration etc). It would be almost impossible to interwork to equivalent mechanisms in SIP, without losing the service transparency when using an intervening SIP based core. 2- Yes, we definitely need an interworking/translation mechanism to map all the basic call/service paremeters, and procedures for mapping the messages. But this does not preclude the need for a DPNSS MIME type, but would rather be complimentary to the MIME type mechanism. Similar to http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-00.txt , for QSIG, we are in the process of putting together an interworking draft for DPNSS as well - but rather than making it DPNSS specific, we are trying to make it a common draft to cover PRI, DPNSS & DASS2 [as Q.SIG interworking is already a SIPPING WG ID]. Note that, PRI and DASS2 will not need a MIME type as these are, as one might be aware, for PSTN access, unlike DPNSS and QSIG (which are private network protocols). 3- From the SIP perspective, carrying non-SIP applications as MIME objects to ensure end to end service transparency is architecturally less appalling than, say for e.g., tunneling DSS1 protocols in H.323 based network - so the SIP DPNSS MIME proposition as per this I-D is the obvious way forward for DPNSS service transparency over a SIP based core, especially now that we see acute deployment needs to be met. cheers, ranjith.. > -----Original Message----- > From: sipping-admin@ietf.org [ mailto:sipping-admin@ietf.org ]On Behalf > Of > Ranjith Mukundan > Sent: Tuesday, February 04, 2003 5:32 PM > To: sipping@ietf.org > Subject: RE: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-01.txt > > > Hi List, > We would like you take a look at this draft and revert with any > comments/queries that you might have. > > SIPPING Chairs, > The authors feel that the requirement and the need for this MIME type > is > quite acute. Hence we'd like you to consider this for inclusion as a > WG I-D > and suggest the way forward. > > - ranjith.. > > -----Original Message----- > From: sipping-admin@ietf.org [ mailto:sipping-admin@ietf.org ]On Behalf > Of > Internet-Drafts@ietf.org > Sent: Tuesday, February 04, 2003 5:14 PM > To: IETF-Announce: > Cc: sipping@ietf.org > Subject: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : MIME media types for DPNSS Objects > Author(s) : R. Mukundan et al. > Filename : draft-mukundan-sipping-dpnss-01.txt > Pages : 9 > Date : 2003-2-3 > > This document describes Multipart Internet Mail Extensions (MIME) type > for application/Digital Private Network Signaling System (DPNSS) > objects for use in Session Initiation Protocol (SIP) applications, > according to the rules defined in RFC 2048. These types can be used to > identify Digital Private Network Signaling System 1 (DPNSS 1) objects > within a SIP message such as INVITE or INFO, as might be implemented > when using SIP in an environment where part of the call involves > interworking to DPNSS 1 based Private Networks. RFC 3204 addresses a > similar need for Integrated Service Digital Network User Part (ISUP) > and Q Signaling (QSIG). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-01.tx > t > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-mukundan-sipping-dpnss-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-mukundan-sipping-dpnss-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 ------_=_NextPart_001_01C2D2B9.3558CCF0 Content-Type: text/html; charset="iso-8859-1" QSIG Vs DPNSS MIME
Ranjith,
 
Seems like a reasonable thing to do. A few comments which I hope are helpful...
 
1) The discussion of handling segmented information might be clearer if you were to use the terminology of the DPNSS specification such as Selection Block/Selection Field and Information Block/Information Field to refer to the items being manipulated. In the case of the ISRM/SSRM, as others have already commented, you would need to distinguish between the Supplementary Information and the Destination Address which make up the Selection Block; the Supplementary Information can be safely buffered but the Destination Address needs to be handled according to overlap procedures.
 
2) Using that terminology might make clearer how you propose to perform the buffering. I think you are proposing to concatenate the Information Fields from a sequence of messages to assemble a complete Information Block (or segment thereof if it exceeds your 255 octet limit) with a single message type octet, although I don't see this stated explicitly. If so, then I think your example is slightly inaccurate: combining a sequence of five EEMs each of 45 octets would produce an EEM of 221 octets (as four message type octets are removed)?
 
3) I'm not sure there is really any need for a version number, since DPNSS has comprehensive compatibility mechanisms?
 
Regards,
Mark.
-----Original Message-----
From: Ranjith Mukundan [mailto:ranjith.mukundan@wipro.com]
Sent: 11 February 2003 08:59
To: sipping@ietf.org
Subject: [Sipping] QSIG Vs DPNSS MIME

we'd appreciate some views on this draft from atleast those who fairly understand QSIG.

of course, others who feel that this MIME type collides directly with the purpose of SIP are encouraged to provide alternatives bearing in mind that providing complete end-to-end service transparency over the intervening SIP based core would be essential, if we are to provide a seamless migration path from H.323 based core networks - which already provide equivalent mechanisms for DSS1 based protocols.

- ranjith..


-----Original Message-----
From:   Ranjith Mukundan
Sent:   Sat 2/8/2003 12:09 AM
To:     sipping@ietf.org
Cc:    
Subject:        RE: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-01.txt

Hi,

posting WRT http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-01.txt


>>
>> Why is it so important to be able to tunnel DPNSS in SIP?  I'd prefer
>> that folks implement a translation to SIP, where SIP can natively carry
>> all the information that DPNSS is trying to convey.
>>

To put things in perspective:

1- DPNSS is a protocol (deployed primarily in UK, NZ, Australia and parts of NA) very similar to QSIG (deployed primarily Europe) for interconnecting PBXs or centrex customers hosted off LEs. DPNSS (like QSIG) finds enormous application towards realizing a local VPN or network-wide VPN services.

2- This draft aims to do exactly what RFC 3204 (MIME objects for QSIG/ISUP) does for QSIG with appropriate/relevant customization for DPNSS - i.e., to provide end-to-end & *complete*, DPNSS Service transparency between pockets of DPNSS based private networks over a SIP based core.

3- Currently, circuit-switched SS7 based cores, provide equivalent DPNSS tunneling mechanisms through (ETSI & ANSI) ISUP *apart from* the concomitant translation/interworking mechanisms to ISUP. The translation/interworking mechanism to ISUP is limited to the basic call and certain ISUP supplementary services where there is a direct/easy equivalent.

4- H.323 also provides equivalent tunneling mechanisms (via the H.450 Annexe procedures) for transparently carrying DSS1 based signaling between DSS1-based network elements/gateways, over a H.323 core.

Some specifics:

1- DPNSS supports, as specified in BTNR 188, approximately 240+ supplementary features/services (like Call Back When Free, Call Back When Next Used, Executive Intrusion, Travelling Class of Service, Do Not Disturb, Night Service, Private Network Route Optimization, Centralized Operator, Three Party Takeover, Remote Diversion Registration etc). It would be almost impossible to interwork to equivalent mechanisms in SIP, without losing the service transparency when using an intervening SIP based core.

2- Yes, we definitely need an interworking/translation mechanism to map all the basic call/service paremeters, and procedures for mapping the messages. But this does not preclude the need for a DPNSS MIME type, but would rather be complimentary to the MIME type mechanism. Similar to http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-00.txt , for QSIG, we are in the process of putting together an interworking draft for DPNSS as well - but rather than making it DPNSS specific, we are trying to make it a common draft to cover PRI, DPNSS & DASS2 [as Q.SIG interworking is already a SIPPING WG ID]. Note that, PRI and DASS2 will not need a MIME type as these are, as one might be aware, for PSTN access, unlike DPNSS and QSIG (which are private network protocols).

3- From the SIP perspective, carrying non-SIP applications as MIME objects to ensure end to end service transparency is architecturally less appalling than, say for e.g., tunneling DSS1 protocols in H.323 based network - so the SIP DPNSS MIME proposition as per this I-D is the obvious way forward for DPNSS service transparency over a SIP based core, especially now that we see acute deployment needs to be met.

cheers,
ranjith..

> -----Original Message-----
> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf
> Of
> Ranjith Mukundan
> Sent: Tuesday, February 04, 2003 5:32 PM
> To: sipping@ietf.org
> Subject: RE: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-01.txt
>
>
> Hi List,
> We would like you take a look at this draft and revert with any
> comments/queries that you might have.
>
> SIPPING Chairs,
> The authors feel that the requirement and the need for this MIME type
> is
> quite acute. Hence we'd like you to consider this for inclusion as a
> WG I-D
> and suggest the way forward.
>
> - ranjith..
>
> -----Original Message-----
> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf
> Of
> Internet-Drafts@ietf.org
> Sent: Tuesday, February 04, 2003 5:14 PM
> To: IETF-Announce:
> Cc: sipping@ietf.org
> Subject: [Sipping] I-D ACTION:draft-mukundan-sipping-dpnss-01.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>       Title           : MIME media types for DPNSS Objects
>       Author(s)       : R. Mukundan et al.
>       Filename        : draft-mukundan-sipping-dpnss-01.txt
>       Pages           : 9
>       Date            : 2003-2-3
>
> This document describes Multipart Internet Mail Extensions (MIME) type
> for application/Digital Private Network Signaling System (DPNSS)
> objects for use in Session Initiation Protocol (SIP) applications,
> according to the rules defined in RFC 2048. These types can be used to
> identify Digital Private Network Signaling System 1 (DPNSS 1) objects
> within a SIP message such as INVITE or INFO, as might be implemented
> when using SIP in an environment where part of the call involves
> interworking to DPNSS 1 based Private Networks. RFC 3204 addresses a
> similar need for Integrated Service Digital Network User Part (ISUP)
> and Q Signaling (QSIG).
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-01.tx
> t
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the
> message.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>       "get draft-mukundan-sipping-dpnss-01.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
>       mailserv@ietf.org.
> In the body type:
>       "FILE /internet-drafts/draft-mukundan-sipping-dpnss-01.txt".
>
> NOTE: The mail server at ietf.org can return the document in
>       MIME-encoded form by using the "mpack" utility.  To use this
>       feature, insert the command "ENCODING mime" before the "FILE"
>       command.  To decode the response(s), you will need "munpack" or
>       a MIME-compliant mail reader.  Different MIME-compliant mail readers
>       exhibit different behavior, especially when dealing with
>       "multipart" MIME messages (i.e. documents which have been split
>       up into multiple messages), so check your local documentation on
>       how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the 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
------_=_NextPart_001_01C2D2B9.3558CCF0-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Feb 12 12:25:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09464 for ; Wed, 12 Feb 2003 12:25:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CHZCV07729 for sipping-archive@odin.ietf.org; Wed, 12 Feb 2003 12:35:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CHZCp07726 for ; Wed, 12 Feb 2003 12:35:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09430 for ; Wed, 12 Feb 2003 12:25:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CHYNp07670; Wed, 12 Feb 2003 12:34:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CHX5p07626 for ; Wed, 12 Feb 2003 12:33:05 -0500 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09400 for ; Wed, 12 Feb 2003 12:23:05 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h1CHQlQ16237 for ; Wed, 12 Feb 2003 11:26:47 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1LNXD6KB>; Wed, 12 Feb 2003 11:26:48 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A05A7CCFB@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'sipping@ietf.org'" Date: Wed, 12 Feb 2003 11:26:46 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C2D2BB.EAE5C800" Subject: [Sipping] FW: I-D ACTION:draft-barnes-sipping-history-info-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: , 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_000_01C2D2BB.EAE5C800 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D2BB.EAE5C800" ------_=_NextPart_001_01C2D2BB.EAE5C800 Content-Type: text/plain; charset="ISO-8859-1" Hi all, This document has had several changes as a result of the feedback on the mailing list: - Section 2.1 - corrected the terminology to be consistent with the capturing of the single targeted-to-URI and corrected the syntax of the index as highlighted by Paul K. - In section 2.3, clarified that History-Info can be included in provisional responses per John E.'s comment - Additional normative text around the maintenance of the Index added to section 2.3.1 and 2.3.3 per Paul K's comment. - Added additional sections to 2.3.3 to further clarify the Request and Response processing - Updated the example in section 2.5 to include the use of the Index - Added a high level flow to Appendix C, highlighting a scenario whereby local policy prevents the History-Info from being sent in the Responses. Per my previous posting on the -01 updates, the Security solution required for History-Info will be addressed in a separate draft (which hopefully can be put forth before the deadline) and the call flows (although one additional one has been added) still do need more work, but again, I'd like agreement on the syntax before adding too much more. One area that perhaps require further consideration is whether the Index should be mandatory since we are now only capturing the Targeted-to-URI, it won't be possible to really interpret a series of captured Request URIs without an Index. Right now, the inclusion of an Index is a SHOULD, with the caveat that if there is no History-Info in a request received by a Proxy, that it adds an entry based upon the received Request before it retargets. For this scenario, an INDEX MUST not be added because there's no way to know what it should be AND the lack of an index highlights a missing entry, which might be useful to an end application. Please do review and provide feedback. Regards, Mary H. Barnes mbarnes@nortelnetworks.com -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, February 12, 2003 8:20 AM Subject: I-D ACTION:draft-barnes-sipping-history-info-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Extension to the Session Initiation Protocol for Request History Information Author(s) : M. Barnes, M. Watson Filename : draft-barnes-sipping-history-info-02.txt Pages : 20 Date : 2003-2-11 This draft defines a standard mechanism for capturing the history information associated with a SIP request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This draft defines a new optional SIP header, History-Info, for capturing the history information in requests. A new option tag, HistInfo, to be included in the Supported header is defined to allow UAs to indicate whether the HistInfo should be returned in responses to a request which has captured the history information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-barnes-sipping-history-info-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-barnes-sipping-history-info-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-barnes-sipping-history-info-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C2D2BB.EAE5C800 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable FW: I-D ACTION:draft-barnes-sipping-history-info-02.txt

Hi all,

This document has had several changes as a result of = the feedback on the mailing list:

- Section 2.1 - corrected the terminology to be = consistent with the capturing of the single targeted-to-URI and = corrected the syntax of the index as highlighted by Paul K.

- In section 2.3, clarified that History-Info can be = included in provisional responses per John E.'s comment

- Additional normative text around the maintenance of = the Index added to section 2.3.1 and 2.3.3 per Paul K's comment.
 
- Added additional sections to 2.3.3 to further = clarify the Request and Response processing

- Updated the example in section 2.5 to include the = use of the Index

- Added a high level flow to Appendix C, highlighting = a scenario whereby local policy prevents the History-Info from being = sent in the Responses.

Per my previous posting on the -01 updates, the = Security solution required for History-Info will be addressed in a = separate draft (which hopefully can be put forth before the deadline) = and the call flows (although one additional one has been added) still = do need more work, but again, I'd like agreement on the syntax before = adding too much more.

One area that perhaps require further consideration = is whether the Index should be mandatory since we are now only = capturing the Targeted-to-URI, it won't be possible to really interpret = a series of captured Request URIs without an Index.  Right now, = the inclusion of an Index is a SHOULD, with the caveat that if there is = no History-Info in a request received by a Proxy, that it adds an entry = based upon the received Request before it retargets.  For this = scenario, an INDEX MUST not be added because there's no way to know = what it should be AND the lack of an index highlights a missing entry, = which might be useful to an end application. 

Please do review and provide feedback.

Regards,
Mary H. Barnes
mbarnes@nortelnetworks.com

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org= ]
Sent: Wednesday, February 12, 2003 8:20 AM
Subject: I-D = ACTION:draft-barnes-sipping-history-info-02.txt


A New Internet-Draft is available from the on-line = Internet-Drafts directories.


        Title           : = An Extension to the Session Initiation Protocol
        =         =           for = Request History Information
        Author(s)       : M. Barnes, M. = Watson
        Filename        : = draft-barnes-sipping-history-info-02.txt
        Pages           : = 20
        Date    =         : 2003-2-11
       =20
This draft defines a standard mechanism for = capturing the history
information associated with a SIP request.  = This capability enables
many enhanced services by providing the information = as to how and
why a call arrives at a specific application or = user.  This draft
defines a new optional SIP header, History-Info, for = capturing the
history information in requests. A new option tag, = HistInfo, to be
included in the Supported header is defined to allow = UAs to
indicate whether the HistInfo should be returned in = responses to a
request which has captured the history = information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-barnes-sippi= ng-history-info-02.txt

To remove yourself from the IETF Announcement list, = send a message to
ietf-announce-request with the word unsubscribe in = the body of the message.

Internet-Drafts are also available by anonymous FTP. = Login with the username
"anonymous" and a password of your e-mail = address. After logging in,
type "cd internet-drafts" and then
        "get = draft-barnes-sipping-history-info-02.txt".

A list of Internet-Drafts directories can be found = in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by = e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE = /internet-drafts/draft-barnes-sipping-history-info-02.txt".
       =20
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.
            &= nbsp;  =20
        =        =20
Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of the
Internet-Draft.

  ------_=_NextPart_001_01C2D2BB.EAE5C800-- ------_=_NextPart_000_01C2D2BB.EAE5C800 Content-Type: message/rfc822 To: Subject: Date: Wed, 12 Feb 2003 09:25:18 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C2D2BB.EAE5C800" ------_=_NextPart_002_01C2D2BB.EAE5C800 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C2D2BB.EAE5C800" ------_=_NextPart_003_01C2D2BB.EAE5C800 Content-Type: text/plain ------_=_NextPart_003_01C2D2BB.EAE5C800 Content-Type: text/html

  ------_=_NextPart_003_01C2D2BB.EAE5C800-- ------_=_NextPart_002_01C2D2BB.EAE5C800 Content-Type: application/octet-stream; name="ATT12049" Content-Disposition: attachment; filename="ATT12049" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-11141009.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-barnes-sipping-history-info-02.txt ------_=_NextPart_002_01C2D2BB.EAE5C800 Content-Type: message/external-body; site="internet-drafts"; dir="draft-barnes-sipping-history-info-02"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C2D2BB.EAE5C800-- ------_=_NextPart_000_01C2D2BB.EAE5C800-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Feb 12 12:38:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09754 for ; Wed, 12 Feb 2003 12:38:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CHluh09023 for sipping-archive@odin.ietf.org; Wed, 12 Feb 2003 12:47:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CHltp09020 for ; Wed, 12 Feb 2003 12:47:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09744 for ; Wed, 12 Feb 2003 12:37:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CHl8p08994; Wed, 12 Feb 2003 12:47:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CHkqp08962 for ; Wed, 12 Feb 2003 12:46:52 -0500 Received: from wiprom2mx1.wipro.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09721 for ; Wed, 12 Feb 2003 12:36:45 -0500 (EST) Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id h1CHeQv29078 for ; Wed, 12 Feb 2003 23:10:26 +0530 (IST) Received: from blr-ec-msg01.wipro.com ([10.200.50.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 12 Feb 2003 23:10:21 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sipping] QSIG Vs DPNSS MIME Date: Wed, 12 Feb 2003 23:10:21 +0530 Message-ID: <5CD22C179E0D7C49954F3ACCA07E4EDE09D1B0@blr-ec-msg01.wipro.com> Thread-Topic: [Sipping] QSIG Vs DPNSS MIME Thread-Index: AcLSuUfspYMh9wzNTOSiJFhM5xnpVQAAN9Cs From: "Ranjith Mukundan" To: "Ashworth, Mark [MOP:MA01:EXCH]" Cc: X-OriginalArrivalTime: 12 Feb 2003 17:40:21.0887 (UTC) FILETIME=[D11E48F0:01C2D2BD] 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: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable RE: [Sipping] QSIG Vs DPNSS MIME

Mark,

OK, 1) & 2) seems to be a good suggestion as it would indeed help = clarify the buffering mechanism better. Yes, you are right, the example = is inaccurate - it would add up to 221 instead of 225.

regarding 3), though the version field would seem apparently redundant = (as you've aptly noted the protocol is, spec-wise, perfectly compatible = with other versions), we believe that it would help debug the protocol = better - esp, when connecting networks implementing different versions. = We've known, in the legacy implementations, some debugging issues that = cropped up, whilst interwoking issue 4 PBX to an issue 6 PBX. So, we'd = suggest that we retain this parameter. But as Mark (Watson) pointed out, = the text describing the version field type needs to be made more = accurate

cheers,
- ranjith..

-----Original Message-----
From:   Ashworth, Mark [MOP:MA01:EXCH] [mailto:mashwort@europem01.nt.co= m]
Sent:   Wed 2/12/2003 10:37 PM
To:     Ranjith Mukundan
Cc:     sipping@ietf.org
Subject:        RE: [Sipping] QSIG Vs = DPNSS MIME
Ranjith,

Seems like a reasonable thing to do. A few comments which I hope are
helpful...

1) The discussion of handling segmented information might be clearer if = you
were to use the terminology of the DPNSS specification such as = Selection
Block/Selection Field and Information Block/Information Field to refer = to
the items being manipulated. In the case of the ISRM/SSRM, as others = have
already commented, you would need to distinguish between the = Supplementary
Information and the Destination Address which make up the Selection = Block;
the Supplementary Information can be safely buffered but the = Destination
Address needs to be handled according to overlap procedures.

2) Using that terminology might make clearer how you propose to perform = the
buffering. I think you are proposing to concatenate the Information = Fields
from a sequence of messages to assemble a complete Information Block = (or
segment thereof if it exceeds your 255 octet limit) with a single = message
type octet, although I don't see this stated explicitly. If so, then I = think
your example is slightly inaccurate: combining a sequence of five EEMs = each
of 45 octets would produce an EEM of 221 octets (as four message type = octets
are removed)?

3) I'm not sure there is really any need for a version number, since = DPNSS
has comprehensive compatibility mechanisms?

Regards,
Mark.

-----Original Message-----
From: Ranjith Mukundan [mailto:ranjith.mukundan@wipro.= com]
Sent: 11 February 2003 08:59
To: sipping@ietf.org
Subject: [Sipping] QSIG Vs DPNSS MIME



we'd appreciate some views on this draft from atleast those who = fairly
understand QSIG.

of course, others who feel that this MIME type collides directly with = the
purpose of SIP are encouraged to provide alternatives bearing in mind = that
providing complete end-to-end service transparency over the intervening = SIP
based core would be essential, if we are to provide a seamless = migration
path from H.323 based core networks - which already provide = equivalent
mechanisms for DSS1 based protocols.

- ranjith..


-----Original Message-----
From:   Ranjith Mukundan
Sent:   Sat 2/8/2003 12:09 AM
To:     sipping@ietf.org
Cc:   
Subject:        RE: [Sipping] I-D = ACTION:draft-mukundan-sipping-dpnss-01.txt

Hi,

posting WRT
http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-= 01.txt
<http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-= 01.txt>


>>
>> Why is it so important to be able to tunnel DPNSS in SIP?  = I'd prefer
>> that folks implement a translation to SIP, where SIP can = natively carry
>> all the information that DPNSS is trying to convey.
>>

To put things in perspective:

1- DPNSS is a protocol (deployed primarily in UK, NZ, Australia and = parts of
NA) very similar to QSIG (deployed primarily Europe) for = interconnecting
PBXs or centrex customers hosted off LEs. DPNSS (like QSIG) finds = enormous
application towards realizing a local VPN or network-wide VPN = services.

2- This draft aims to do exactly what RFC 3204 (MIME objects for = QSIG/ISUP)
does for QSIG with appropriate/relevant customization for DPNSS - i.e., = to
provide end-to-end & *complete*, DPNSS Service transparency between = pockets
of DPNSS based private networks over a SIP based core.

3- Currently, circuit-switched SS7 based cores, provide equivalent = DPNSS
tunneling mechanisms through (ETSI & ANSI) ISUP *apart from* the = concomitant
translation/interworking mechanisms to ISUP. The = translation/interworking
mechanism to ISUP is limited to the basic call and certain ISUP
supplementary services where there is a direct/easy equivalent.

4- H.323 also provides equivalent tunneling mechanisms (via the H.450 = Annexe
procedures) for transparently carrying DSS1 based signaling between
DSS1-based network elements/gateways, over a H.323 core.

Some specifics:

1- DPNSS supports, as specified in BTNR 188, approximately 240+
supplementary features/services (like Call Back When Free, Call Back = When
Next Used, Executive Intrusion, Travelling Class of Service, Do Not = Disturb,
Night Service, Private Network Route Optimization, Centralized = Operator,
Three Party Takeover, Remote Diversion Registration etc). It would be = almost
impossible to interwork to equivalent mechanisms in SIP, without losing = the
service transparency when using an intervening SIP based core.

2- Yes, we definitely need an interworking/translation mechanism to map = all
the basic call/service paremeters, and procedures for mapping the = messages.
But this does not preclude the need for a DPNSS MIME type, but would = rather
be complimentary to the MIME type mechanism. Similar to
http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-00= .txt
<http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-00= .txt>  ,
for QSIG, we are in the process of putting together an interworking = draft
for DPNSS as well - but rather than making it DPNSS specific, we are = trying
to make it a common draft to cover PRI, DPNSS & DASS2 [as Q.SIG = interworking
is already a SIPPING WG ID]. Note that, PRI and DASS2 will not need a = MIME
type as these are, as one might be aware, for PSTN access, unlike DPNSS = and
QSIG (which are private network protocols).

3- From the SIP perspective, carrying non-SIP applications as MIME = objects
to ensure end to end service transparency is architecturally less = appalling
than, say for e.g., tunneling DSS1 protocols in H.323 based network - so = the
SIP DPNSS MIME proposition as per this I-D is the obvious way forward = for
DPNSS service transparency over a SIP based core, especially now that we = see
acute deployment needs to be met.

cheers,
ranjith..

> -----Original Message-----
> From: sipping-admin@ietf.org [ mailto:sipping-admin@ietf.org<= BR> <mailto:sipping-admin@ietf.org&= gt; ]On Behalf
> Of
> Ranjith Mukundan
> Sent: Tuesday, February 04, 2003 5:32 PM
> To: sipping@ietf.org
> Subject: RE: [Sipping] I-D = ACTION:draft-mukundan-sipping-dpnss-01.txt
>
>
> Hi List,
> We would like you take a look at this draft and revert with any
> comments/queries that you might have.
>
> SIPPING Chairs,
> The authors feel that the requirement and the need for this MIME = type
> is
> quite acute. Hence we'd like you to consider this for inclusion as = a
> WG I-D
> and suggest the way forward.
>
> - ranjith..
>
> -----Original Message-----
> From: sipping-admin@ietf.org [ mailto:sipping-admin@ietf.org<= BR> <mailto:sipping-admin@ietf.org&= gt; ]On Behalf
> Of
> Internet-Drafts@ietf.org
> Sent: Tuesday, February 04, 2003 5:14 PM
> To: IETF-Announce:
> Cc: sipping@ietf.org
> Subject: [Sipping] I-D = ACTION:draft-mukundan-sipping-dpnss-01.txt
>
>
> A New Internet-Draft is available from the on-line = Internet-Drafts
> directories.
>
>
>       = Title           : MIME = media types for DPNSS Objects
>       = Author(s)       : R. Mukundan et al.
>       = Filename        : = draft-mukundan-sipping-dpnss-01.txt
>       = Pages           : = 9
>       = Date            : = 2003-2-3
>
> This document describes Multipart Internet Mail Extensions (MIME) = type
> for application/Digital Private Network Signaling System = (DPNSS)
> objects for use in Session Initiation Protocol (SIP) = applications,
> according to the rules defined in RFC 2048. These types can be used = to
> identify Digital Private Network Signaling System 1 (DPNSS 1) = objects
> within a SIP message such as INVITE or INFO, as might be = implemented
> when using SIP in an environment where part of the call = involves
> interworking to DPNSS 1 based Private Networks. RFC 3204 addresses = a
> similar need for Integrated Service Digital Network User Part = (ISUP)
> and Q Signaling (QSIG).
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-0= 1.tx
<http://www.ietf.org/internet-drafts/draft-mukundan-sipping-dpnss-0= 1.tx>
> t
>
> To remove yourself from the IETF Announcement list, send a message = to
> ietf-announce-request with the word unsubscribe in the body of = the
> message.
>
> Internet-Drafts are also available by anonymous FTP. Login with = the
> username
> "anonymous" and a password of your e-mail address. After = logging in,
> type "cd internet-drafts" and then
>       "get = draft-mukundan-sipping-dpnss-01.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html<= /A> <http://www.ietf.org/shadow.html<= /A>>  or
> ftp://ftp.ietf.org/iet= f/1shadow-sites.txt
<ftp://ftp.ietf.org/iet= f/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-mukundan-sipping-dpnss-01.txt".
>
> NOTE: The mail server at ietf.org can return the document in
>       MIME-encoded form by using the = "mpack" utility.  To use this
>       feature, insert the command = "ENCODING mime" before the "FILE"
>       command.  To decode the = response(s), you will need "munpack" or
>       a MIME-compliant mail = reader.  Different MIME-compliant mail readers
>       exhibit different behavior, = especially when dealing with
>       "multipart" MIME = messages (i.e. documents which have been split
>       up into multiple messages), so = check your local documentation on
>       how to manipulate these = messages.
>
>
> Below is the data which will enable a MIME compliant mail = reader
> implementation to automatically retrieve the ASCII version of = the
> Internet-Draft.
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf= .org/mailman/listinfo/sipping
<https://www1.ietf= .org/mailman/listinfo/sipping>
> This list is for NEW development of the 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 mailnull@www1.ietf.org Wed Feb 12 14:48:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13476 for ; Wed, 12 Feb 2003 14:48:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CJwEH16485 for sipping-archive@odin.ietf.org; Wed, 12 Feb 2003 14:58:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CJwEp16482 for ; Wed, 12 Feb 2003 14:58:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13452 for ; Wed, 12 Feb 2003 14:48:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CJuOp16404; Wed, 12 Feb 2003 14:56:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CJt3p16335 for ; Wed, 12 Feb 2003 14:55:03 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13322 for ; Wed, 12 Feb 2003 14:45:01 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h1CJkvBO015540; Wed, 12 Feb 2003 14:46:57 -0500 (EST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <1WPBN0M6>; Wed, 12 Feb 2003 13:48:40 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A644AE@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Ranjith Mukundan'" , "Peterson, Jon" , Jonathan Rosenberg Cc: sipping@ietf.org, "'Mark Watson'" Subject: RE: [Sipping] QSIG Vs DPNSS MIME Date: Wed, 12 Feb 2003 13:48:39 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , > -----Original Message----- > From: Ranjith Mukundan [mailto:ranjith.mukundan@wipro.com] > > In case of DPNSS too the message semantics matches SIP > messages - atleast to > the same extent as it does for ISUP. I think you mean "at least to the same extent as it does for QSIG." DPNSS, QSIG, and ISDN are all UNI protocols. ISUP is an NNI protocol. SIP is end-to-end, which really ends up acting more like an NNI protocol than a UNI protocol. /a _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Feb 12 21:09:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21383 for ; Wed, 12 Feb 2003 21:09:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1D2Iok05783 for sipping-archive@odin.ietf.org; Wed, 12 Feb 2003 21:18:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D2Iop05780 for ; Wed, 12 Feb 2003 21:18:50 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21365 for ; Wed, 12 Feb 2003 21:08:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D2IIp05764; Wed, 12 Feb 2003 21:18:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D2HBp05723 for ; Wed, 12 Feb 2003 21:17:11 -0500 Received: from dgesmtp01.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21338 for ; Wed, 12 Feb 2003 21:07:00 -0500 (EST) Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.wcom.com (Iplanet MTA) with ESMTP id <0HA800MDO5TTFK@firewall.wcom.com> for sipping@ietf.org; Thu, 13 Feb 2003 02:05:54 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HA800M015TT8O@pmismtp02.wcomnet.com>; Thu, 13 Feb 2003 02:05:53 +0000 (GMT) Received: from ajohnston.wcom.com ([166.42.32.203]) by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HA800L4O5TRTM@pmismtp02.wcomnet.com>; Thu, 13 Feb 2003 02:05:53 +0000 (GMT) Date: Wed, 12 Feb 2003 20:05:38 -0600 From: Alan Johnston Subject: Re: [Sipping] New I-D on URI leasing In-reply-to: <3E49E4B5.8010608@dynamicsoft.com> X-Sender: Alan.Johnston@pop.mcit.com To: Jonathan Rosenberg , sipping@ietf.org Message-id: <5.1.1.6.0.20030212193806.02032098@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.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: , Just to clarify and expand on my earlier short comments... I'm not unhappy that the solution proposed in the draft is similar to the one discussed in cc-transfer. The method does work, and we can discuss whether it should be two REGISTERs or one LEASE and one REGISTER. However, both approaches are multi-step, which others objected to when it was discussed at IETF-55. I had hoped that a new proposal was coming, or a way to make Rohan's escaped Route header in a Contact work. This approach, (4.4 in this draft) does not actually suffer from the problems listed - if multiple proxies must be traversed, multiple URIs can be escaped into the Route header. The real problem with this approach is that it violates Table 1 in RFC 3261 so would be ignored by all RFC 3261 compliant UAs. The backwards compatibility problem with pre-bis-04 UAs is even worse. Since under the old Record-Route rules the Contact is included in the Route header, you could potentially have a URI in a Route header with an escaped Route header - yuk! However, there might be a clever solution to work around this problem. This is the only solution that I know of that meets REQ-8. REQ-9 is a bit strange - the anonymity of a Contact is a very small part of the total anonymity picture. It seems this requirement could simply be met by having the user portion of the Contact be a random string. The privacy discussion in 4.2 about the call center operator is simplistic - for privacy, much more than just fixing Contact is required and would be used in practice. I'm not sure understand the motivation for REQ-11. I don't know why a UA would want to generate a unique Contact for each dialog - it seems like quite a burden on the UA and a difficult requirement for a solution to meet. It seems like there is some sort of security reason for this, but it is not stated. One minor correction - the transfer problem is with attended transfer only, not blind transfer or transfer in general. As this is an important topic for many applications, it is important that we get some good discussion going on the requirements and possible solutions. Thanks, Alan Johnston WorldCom sip:alan@digitalari.com At 01:07 AM 2/12/2003 -0500, Jonathan Rosenberg wrote: >Folks, > >I've just submitted an I-D on the concept of "URI leasing". THis is my >proposed technique for solving the "globally routable UA URI" problem. >SPecifically, for cases like REFER, how do we construct a URI that routes >to a specific UA instance in a domain? At the last ietf meeting, this >issue came up in several contexts. I suggested a single document to >explore the problem. The chairs asked for volunteers, and I said I'd write >one, time permitting, if no one else stepped up. Since no one did, well, >here it is. > >Until it appears in the archives, you can pick it up at: >http://www.jdrosen.net/papers/draft-rosenberg-sipping-lease-00.txt >http://www.jdrosen.net/papers/draft-rosenberg-sipping-lease-00.html > >Thanks, >Jonathan R. >-- >Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.dynamicsoft.com > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Feb 12 23:47:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24377 for ; Wed, 12 Feb 2003 23:47:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1D4usJ14095 for sipping-archive@odin.ietf.org; Wed, 12 Feb 2003 23:56:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D4usp14092 for ; Wed, 12 Feb 2003 23:56:54 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24370 for ; Wed, 12 Feb 2003 23:46:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D4uFp14081; Wed, 12 Feb 2003 23:56:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D4sSp14025 for ; Wed, 12 Feb 2003 23:54:28 -0500 Received: from wiprom2mx1.wipro.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24285 for ; Wed, 12 Feb 2003 23:44:13 -0500 (EST) Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id h1D4lrv11001 for ; Thu, 13 Feb 2003 10:17:53 +0530 (IST) Received: from blr-ec-msg01.wipro.com ([10.200.50.99]) by blr-ec-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 13 Feb 2003 10:17:49 +0530 Received: from ranjith2 ([192.168.178.234]) by blr-ec-msg01.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 13 Feb 2003 10:17:49 +0530 From: "Ranjith Mukundan" To: "Adam Roach" , "Peterson, Jon" , "Jonathan Rosenberg" Cc: , "'Mark Watson'" Subject: RE: [Sipping] QSIG Vs DPNSS MIME Date: Thu, 13 Feb 2003 10:21:45 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A644AE@dyn-tx-exch-001.dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 13 Feb 2003 04:47:49.0739 (UTC) FILETIME=[0F7F8BB0:01C2D31B] 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit PRI, DASS2 etc are all 'true' UNI protocols - but not QSIG and DPNSS. I would qualifiy DPNSS & QSIG as UUI (user-to-user) protocols as they are used between PBXs (PINX in QSIG terminology) in a private network (PISN in QSIG terminology). I mean, you could view QSIG and DPNSS as an ISUP-protocol-equivalent for private networks. QSIG and ISDN are peer-to-peer/end-to-end protocols unlike PRI (and DASS2) - making it both SIP-like (atleast to the same extent as ISUP) from the *protocol architecture* point of view. From the protocol message semantic point of view, DPNSS matches SIP messages to a larger extent than QSIG - esp wrt the session setup/progress/tear-down messages (as opposed to the link/circuit maintenance messages) used for the basic call *and* supplementary services like call transfer, three way conference etc. As an example that I cited in an earlier mail, mid call QSIG messages like INFO, NOTIFY & FAC would *all* get carried in SIP INFO method - where as, in case of DPNSS, the only mid call message, and which has a direct parlance to SIP INFO is EEM (end to end message; equivalent to ISUP PAM and to some extent ISUP APM). For this reason, I'd think, DPNSS message semantics matches SIP atleast to the same extent as it does for ISUP. cheers, - ranjith.. -----Original Message----- From: Adam Roach [mailto:adam@dynamicsoft.com] Sent: Thursday, February 13, 2003 1:19 AM To: 'Ranjith Mukundan'; Peterson, Jon; Jonathan Rosenberg Cc: sipping@ietf.org; 'Mark Watson' Subject: RE: [Sipping] QSIG Vs DPNSS MIME > -----Original Message----- > From: Ranjith Mukundan [mailto:ranjith.mukundan@wipro.com] > > In case of DPNSS too the message semantics matches SIP > messages - atleast to > the same extent as it does for ISUP. I think you mean "at least to the same extent as it does for QSIG." DPNSS, QSIG, and ISDN are all UNI protocols. ISUP is an NNI protocol. SIP is end-to-end, which really ends up acting more like an NNI protocol than a UNI protocol. /a _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 13 00:18:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24703 for ; Thu, 13 Feb 2003 00:18:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1D5S9t15699 for sipping-archive@odin.ietf.org; Thu, 13 Feb 2003 00:28:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D5S8p15696 for ; Thu, 13 Feb 2003 00:28:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24688 for ; Thu, 13 Feb 2003 00:17:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D5RSp15593; Thu, 13 Feb 2003 00:27:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D5QLp15551 for ; Thu, 13 Feb 2003 00:26:21 -0500 Received: from proxy-blr.primus-india.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24642 for ; Thu, 13 Feb 2003 00:16:05 -0500 (EST) Received: from dexceldesigns.com (ptil-67-160-ind.primus-india.net [203.196.160.67] (may be forged)) by proxy-blr.primus-india.com (8.11.2/8.11.2) with ESMTP id h1DAm1v15440 for ; Thu, 13 Feb 2003 16:18:01 +0530 Message-ID: <00da01c2d31a$5afe4960$dd9a83ca@DOMAIN.dexceldesigns.com> From: margaretmary To: Date: Thu, 13 Feb 2003 10:11:53 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D6_01C2D348.54C4B9C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailserver: Sent using PostMaster (v4.1.13) Subject: [Sipping] query on conference server Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_00D6_01C2D348.54C4B9C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello sir, The draft specifed below for conference server model framework SIPPING Working Group =20 Internet Draft =20 Document: draft-ietf-sipping-cc-framework-01.txt =20 June 2002 = =20 Expires: December 2002 =20 This statement is taken form the above mentioned draft. Please some one elaborate this statement "Below are listed several call control "actions" which establish or modify dialogs and relate the participants in a conversation space. The names of the actions listed are for descriptive purposes only (they are not normative). This list of actions is not meant to be exhaustive." This section 5.0 of the draft is only theoritical or practical = implementation can be done. please try to provide a solution for this Regards, Margaret ------=_NextPart_000_00D6_01C2D348.54C4B9C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello sir,
 
The draft specifed below for conference = server=20 model framework
 
SIPPING Working = Group  
Internet Draft  
Document:=20 draft-ietf-sipping-cc-framework-01.txt     =20
June=20 2002           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p; =20
Expires: December=20 2002           &nb= sp;           &nbs= p;      =20
 
This statement is taken form the above = mentioned=20 draft.
Please some one elaborate this=20 statement
 
"Below are listed several call = control=20 "actions" which establish or
    modify dialogs and = relate the=20 participants in a conversation space.
    The names of = the=20 actions listed are for descriptive purposes only
    = (they are=20 not normative).  This list of actions is not meant to=20 be
    exhaustive."
 
This section 5.0 of the draft is only = theoritical=20 or practical implementation can be done.
 
please try to provide a solution for=20 this
 
 
 
Regards,
Margaret

--------------------------------------------------------------
Dexcel Electronics Designs (P) Ltd., Bangalore, India
------=_NextPart_000_00D6_01C2D348.54C4B9C0-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 13 01:47:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25764 for ; Thu, 13 Feb 2003 01:47:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1D6vL119829 for sipping-archive@odin.ietf.org; Thu, 13 Feb 2003 01:57:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D6vLp19826 for ; Thu, 13 Feb 2003 01:57:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25759 for ; Thu, 13 Feb 2003 01:47:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D6ujp19780; Thu, 13 Feb 2003 01:56:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D6rgp19716 for ; Thu, 13 Feb 2003 01:53:42 -0500 Received: from btlmail.bplmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25732 for ; Thu, 13 Feb 2003 01:43:24 -0500 (EST) Received: from [10.10.13.58] (helo=rkumar) by btlmail.bplmail.com with smtp (Exim 3.22 #1 (Red Hat Linux)) id 18jCyU-0006kq-00; Thu, 13 Feb 2003 12:05:58 +0530 Reply-To: From: "Ranjit Kumar Avasarala" To: "margaretmary" , Subject: RE: [Sipping] query on conference server Date: Thu, 13 Feb 2003 12:16:15 +0530 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01C2D359.B4AEF470" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <00da01c2d31a$5afe4960$dd9a83ca@DOMAIN.dexceldesigns.com> Importance: Normal Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0033_01C2D359.B4AEF470 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit for conference framework, refer this draft http://www.jdrosen.net/papers/draft-rosenberg-sipping-conferencing-framework -01.txt Ranjit -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf Of margaretmary Sent: Thursday, February 13, 2003 10:12 AM To: sipping@ietf.org Subject: [Sipping] query on conference server Hello sir, The draft specifed below for conference server model framework SIPPING Working Group Internet Draft Document: draft-ietf-sipping-cc-framework-01.txt June 2002 Expires: December 2002 This statement is taken form the above mentioned draft. Please some one elaborate this statement "Below are listed several call control "actions" which establish or modify dialogs and relate the participants in a conversation space. The names of the actions listed are for descriptive purposes only (they are not normative). This list of actions is not meant to be exhaustive." This section 5.0 of the draft is only theoritical or practical implementation can be done. please try to provide a solution for this Regards, Margaret -------------------------------------------------------------- Dexcel Electronics Designs (P) Ltd., Bangalore, India ------=_NextPart_000_0033_01C2D359.B4AEF470 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
for=20 conference framework, refer this draft

http://www.jdrosen.net/papers/draft-rosenberg-sipping-conferenci= ng-framework-01.txt

Ranjit

 

-----Original Message-----
From: = sipping-admin@ietf.org=20 [mailto:sipping-admin@ietf.org]On Behalf Of=20 margaretmary
Sent: Thursday, February 13, 2003 10:12=20 AM
To: sipping@ietf.org
Subject: [Sipping] query = on=20 conference server

Hello sir,
 
The draft specifed below for = conference server=20 model framework
 
SIPPING Working = Group  
Internet = Draft  
Document:=20 draft-ietf-sipping-cc-framework-01.txt     =20
June=20 = 2002           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p; =20
Expires: December=20 = 2002           &nb= sp;           &nbs= p;      =20
 
This statement is taken form the = above mentioned=20 draft.
Please some one elaborate this=20 statement
 
"Below are listed several = call control=20 "actions" which establish or
    modify dialogs and = relate=20 the participants in a conversation space.
    The = names of=20 the actions listed are for descriptive purposes = only
   =20 (they are not normative).  This list of actions is not meant to=20 be
    exhaustive."
 
This section 5.0 of the draft is only = theoritical=20 or practical implementation can be done.
 
please try to provide a solution for=20 this
 
 
 
Regards,
Margaret

---------------------------= -----------------------------------
Dexcel=20 Electronics Designs (P) Ltd., Bangalore, = India
------=_NextPart_000_0033_01C2D359.B4AEF470-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 13 04:25:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07816 for ; Thu, 13 Feb 2003 04:25:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1D9Ytq06145 for sipping-archive@odin.ietf.org; Thu, 13 Feb 2003 04:34:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D9Ysp06138 for ; Thu, 13 Feb 2003 04:34:54 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07812 for ; Thu, 13 Feb 2003 04:24:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D9YFp06122; Thu, 13 Feb 2003 04:34:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1D9Xkp06092 for ; Thu, 13 Feb 2003 04:33:46 -0500 Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07790 for ; Thu, 13 Feb 2003 04:23:26 -0500 (EST) Received: from znsgy0k8.europe.nortel.com (znsgy0k8.europe.nortel.com [47.165.24.67]) by znsgs01r.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h1D9Qm029585; Thu, 13 Feb 2003 09:26:48 GMT Received: from zwcwc012.europe.nortel.com ([47.160.46.124]) by znsgy0k8.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1Z6D0ZQR; Thu, 13 Feb 2003 09:26:49 -0000 Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1LVB6MD8>; Thu, 13 Feb 2003 09:25:43 -0000 Message-ID: X-Sybari-Space: 00000000 00000000 00000000 From: "Mark Watson" To: "'Ranjith Mukundan'" , Adam Roach , "Peterson, Jon" , Jonathan Rosenberg Cc: sipping@ietf.org Subject: RE: [Sipping] QSIG Vs DPNSS MIME Date: Thu, 13 Feb 2003 09:25:42 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D341.AD979484" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2D341.AD979484 Content-Type: text/plain; charset="iso-8859-1" Q.SIG and DPNSS are private NNI protocols, certainly not UNIs. They can both be used for connection of private networks to virtual private network services offered by the public network, but in these cases the public network 'emulates' a private network exchange, so although there is a physical connection between private and public networks, it is still logically a private NNI. ...Mark > -----Original Message----- > From: Ranjith Mukundan [mailto:ranjith.mukundan@wipro.com] > Sent: 13 February 2003 04:52 > To: Adam Roach; Peterson, Jon; Jonathan Rosenberg > Cc: sipping@ietf.org; Watson, Mark [MOP:EP10:EXCH] > Subject: RE: [Sipping] QSIG Vs DPNSS MIME > > > PRI, DASS2 etc are all 'true' UNI protocols - but not QSIG > and DPNSS. I > would qualifiy DPNSS & QSIG as UUI (user-to-user) protocols > as they are used > between PBXs (PINX in QSIG terminology) in a private network > (PISN in QSIG > terminology). I mean, you could view QSIG and DPNSS as an > ISUP-protocol-equivalent for private networks. QSIG and ISDN are > peer-to-peer/end-to-end protocols unlike PRI (and DASS2) - > making it both > SIP-like (atleast to the same extent as ISUP) from the *protocol > architecture* point of view. > > From the protocol message semantic point of view, DPNSS > matches SIP messages > to a larger extent than QSIG - esp wrt the session > setup/progress/tear-down > messages (as opposed to the link/circuit maintenance > messages) used for the > basic call *and* supplementary services like call transfer, three way > conference etc. As an example that I cited in an earlier > mail, mid call QSIG > messages like INFO, NOTIFY & FAC would *all* get carried in SIP INFO > method - where as, in case of DPNSS, the only mid call > message, and which > has a direct parlance to SIP INFO is EEM (end to end message; > equivalent to > ISUP PAM and to some extent ISUP APM). For this reason, I'd > think, DPNSS > message semantics matches SIP atleast to the same extent as > it does for > ISUP. > > cheers, > - ranjith.. > > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Thursday, February 13, 2003 1:19 AM > To: 'Ranjith Mukundan'; Peterson, Jon; Jonathan Rosenberg > Cc: sipping@ietf.org; 'Mark Watson' > Subject: RE: [Sipping] QSIG Vs DPNSS MIME > > > > -----Original Message----- > > From: Ranjith Mukundan [mailto:ranjith.mukundan@wipro.com] > > > > In case of DPNSS too the message semantics matches SIP > > messages - atleast to > > the same extent as it does for ISUP. > > I think you mean "at least to the same extent as it does > for QSIG." > > DPNSS, QSIG, and ISDN are all UNI protocols. ISUP is > an NNI protocol. SIP is end-to-end, which really > ends up acting more like an NNI protocol than a UNI > protocol. > > /a > > ------_=_NextPart_001_01C2D341.AD979484 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sipping] QSIG Vs DPNSS MIME

Q.SIG and DPNSS are private NNI protocols, certainly = not UNIs. They can both be used for connection of private networks to = virtual private network services offered by the public network, but in = these cases the public network 'emulates' a private network exchange, = so although there is a physical connection between private and public = networks, it is still logically a private NNI.

...Mark

> -----Original Message-----
> From: Ranjith Mukundan [mailto:ranjith.mukundan@wipro= .com]
> Sent: 13 February 2003 04:52
> To: Adam Roach; Peterson, Jon; Jonathan = Rosenberg
> Cc: sipping@ietf.org; Watson, Mark = [MOP:EP10:EXCH]
> Subject: RE: [Sipping] QSIG Vs DPNSS = MIME
>
>
> PRI, DASS2 etc are all 'true' UNI protocols - = but not QSIG
> and DPNSS. I
> would qualifiy DPNSS & QSIG as UUI = (user-to-user) protocols
> as they are used
> between PBXs (PINX in QSIG terminology) in a = private network
> (PISN in QSIG
> terminology). I mean, you could view QSIG and = DPNSS as an
> ISUP-protocol-equivalent for private networks. = QSIG and ISDN are
> peer-to-peer/end-to-end protocols unlike PRI = (and DASS2) -
> making it both
> SIP-like (atleast to the same extent as ISUP) = from the *protocol
> architecture* point of view.
>
> From the protocol message semantic point of = view, DPNSS
> matches SIP messages
> to a larger extent than QSIG - esp wrt the = session
> setup/progress/tear-down
> messages (as opposed to the link/circuit = maintenance
> messages) used for the
> basic call *and* supplementary services like = call transfer, three way
> conference etc. As an example that I cited in = an earlier
> mail, mid call QSIG
> messages like INFO, NOTIFY & FAC would = *all* get carried in SIP INFO
> method - where as, in case of DPNSS, the only = mid call
> message, and which
> has a direct parlance to SIP INFO is EEM (end = to end message;
> equivalent to
> ISUP PAM and to some extent ISUP APM). For this = reason, I'd
> think, DPNSS
> message semantics matches SIP atleast to the = same extent as
> it does for
> ISUP.
>
> cheers,
> - ranjith..
>
> -----Original Message-----
> From: Adam Roach [mailto:adam@dynamicsoft.com]
> Sent: Thursday, February 13, 2003 1:19 = AM
> To: 'Ranjith Mukundan'; Peterson, Jon; Jonathan = Rosenberg
> Cc: sipping@ietf.org; 'Mark Watson'
> Subject: RE: [Sipping] QSIG Vs DPNSS = MIME
>
>
> > -----Original Message-----
> > From: Ranjith Mukundan [mailto:ranjith.mukundan@wipro= .com]
> >
> > In case of DPNSS too the message semantics = matches SIP
> > messages - atleast to
> > the same extent as it does for = ISUP.
>
> I think you mean "at least to the same = extent as it does
> for QSIG."
>
> DPNSS, QSIG, and ISDN are all UNI protocols. = ISUP is
> an NNI protocol. SIP is end-to-end, which = really
> ends up acting more like an NNI protocol than a = UNI
> protocol.
>
> /a
>
>

------_=_NextPart_001_01C2D341.AD979484-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 13 05:00:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08344 for ; Thu, 13 Feb 2003 05:00:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DAA3l08551 for sipping-archive@odin.ietf.org; Thu, 13 Feb 2003 05:10:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DAA3p08548 for ; Thu, 13 Feb 2003 05:10:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08325 for ; Thu, 13 Feb 2003 04:59:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DA9Gp08522; Thu, 13 Feb 2003 05:09:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DA88p08476 for ; Thu, 13 Feb 2003 05:08:08 -0500 Received: from wiprom2mx1.wipro.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08283 for ; Thu, 13 Feb 2003 04:57:43 -0500 (EST) Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id h1DA1Qv11747 for ; Thu, 13 Feb 2003 15:31:26 +0530 (IST) Received: from blr-ec-msg01.wipro.com ([10.200.50.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 13 Feb 2003 15:31:20 +0530 Received: from ranjith2 ([192.168.178.234]) by blr-ec-msg01.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 13 Feb 2003 15:31:20 +0530 From: "Ranjith Mukundan" To: "Watson, Mark [MOP:EP10:EXCH]" , "Adam Roach" , "Peterson, Jon" , "Jonathan Rosenberg" Cc: Subject: RE: [Sipping] QSIG Vs DPNSS MIME Date: Thu, 13 Feb 2003 15:35:17 +0530 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-040fb114-3dcd-11d7-ba7f-006067005148" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 13 Feb 2003 10:01:20.0550 (UTC) FILETIME=[DB9D8460:01C2D346] Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPartTM-000-040fb114-3dcd-11d7-ba7f-006067005148 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0066_01C2D375.82BD17A0" ------=_NextPart_000_0066_01C2D375.82BD17A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: [Sipping] QSIG Vs DPNSS MIMEyes. this *private NNI* was what i was refering to as "UUI". -----Original Message----- From: Watson, Mark [MOP:EP10:EXCH] [mailto:mwatson@europem01.nt.com] Sent: Thursday, February 13, 2003 2:56 PM To: 'Ranjith Mukundan'; Adam Roach; Peterson, Jon; Jonathan Rosenberg Cc: sipping@ietf.org Subject: RE: [Sipping] QSIG Vs DPNSS MIME Q.SIG and DPNSS are private NNI protocols, certainly not UNIs. They can both be used for connection of private networks to virtual private network services offered by the public network, but in these cases the public network 'emulates' a private network exchange, so although there is a physical connection between private and public networks, it is still logically a private NNI. ...Mark > -----Original Message----- > From: Ranjith Mukundan [mailto:ranjith.mukundan@wipro.com] > Sent: 13 February 2003 04:52 > To: Adam Roach; Peterson, Jon; Jonathan Rosenberg > Cc: sipping@ietf.org; Watson, Mark [MOP:EP10:EXCH] > Subject: RE: [Sipping] QSIG Vs DPNSS MIME > > > PRI, DASS2 etc are all 'true' UNI protocols - but not QSIG > and DPNSS. I > would qualifiy DPNSS & QSIG as UUI (user-to-user) protocols > as they are used > between PBXs (PINX in QSIG terminology) in a private network > (PISN in QSIG > terminology). I mean, you could view QSIG and DPNSS as an > ISUP-protocol-equivalent for private networks. QSIG and ISDN are > peer-to-peer/end-to-end protocols unlike PRI (and DASS2) - > making it both > SIP-like (atleast to the same extent as ISUP) from the *protocol > architecture* point of view. > > From the protocol message semantic point of view, DPNSS > matches SIP messages > to a larger extent than QSIG - esp wrt the session > setup/progress/tear-down > messages (as opposed to the link/circuit maintenance > messages) used for the > basic call *and* supplementary services like call transfer, three way > conference etc. As an example that I cited in an earlier > mail, mid call QSIG > messages like INFO, NOTIFY & FAC would *all* get carried in SIP INFO > method - where as, in case of DPNSS, the only mid call > message, and which > has a direct parlance to SIP INFO is EEM (end to end message; > equivalent to > ISUP PAM and to some extent ISUP APM). For this reason, I'd > think, DPNSS > message semantics matches SIP atleast to the same extent as > it does for > ISUP. > > cheers, > - ranjith.. > > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Thursday, February 13, 2003 1:19 AM > To: 'Ranjith Mukundan'; Peterson, Jon; Jonathan Rosenberg > Cc: sipping@ietf.org; 'Mark Watson' > Subject: RE: [Sipping] QSIG Vs DPNSS MIME > > > > -----Original Message----- > > From: Ranjith Mukundan [mailto:ranjith.mukundan@wipro.com] > > > > In case of DPNSS too the message semantics matches SIP > > messages - atleast to > > the same extent as it does for ISUP. > > I think you mean "at least to the same extent as it does > for QSIG." > > DPNSS, QSIG, and ISDN are all UNI protocols. ISUP is > an NNI protocol. SIP is end-to-end, which really > ends up acting more like an NNI protocol than a UNI > protocol. > > /a > > ------=_NextPart_000_0066_01C2D375.82BD17A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sipping] QSIG Vs DPNSS MIME
yes.=20 this *private NNI* was what i was refering to as "UUI". =
-----Original Message-----
From: Watson, Mark = [MOP:EP10:EXCH]=20 [mailto:mwatson@europem01.nt.com]
Sent: Thursday, February = 13, 2003=20 2:56 PM
To: 'Ranjith Mukundan'; Adam Roach; Peterson, Jon; = Jonathan=20 Rosenberg
Cc: sipping@ietf.org
Subject: RE: = [Sipping] QSIG=20 Vs DPNSS MIME

Q.SIG and DPNSS are private NNI protocols, certainly = not UNIs.=20 They can both be used for connection of private networks to virtual = private=20 network services offered by the public network, but in these cases the = public=20 network 'emulates' a private network exchange, so although there is a = physical=20 connection between private and public networks, it is still logically = a=20 private NNI.

...Mark

> -----Original Message-----
>=20 From: Ranjith Mukundan [mailto:ranjith.mukundan@wipro.= com]=20
> Sent: 13 February 2003 04:52
> To: Adam Roach; Peterson, Jon; Jonathan Rosenberg =
> Cc: sipping@ietf.org; Watson, Mark = [MOP:EP10:EXCH]=20
> Subject: RE: [Sipping] QSIG Vs DPNSS = MIME=20
>
> =
> PRI, DASS2 etc are all 'true' UNI protocols - but not = QSIG=20
> and DPNSS. I
> would=20 qualifiy DPNSS & QSIG as UUI (user-to-user) protocols =
> as they are used
> between = PBXs (PINX=20 in QSIG terminology) in a private network
> (PISN=20 in QSIG
> terminology). I mean, you could = view QSIG=20 and DPNSS as an
> = ISUP-protocol-equivalent for=20 private networks. QSIG and ISDN are
>=20 peer-to-peer/end-to-end protocols unlike PRI (and DASS2) - =
> making it both
> SIP-like = (atleast to=20 the same extent as ISUP) from the *protocol
>=20 architecture* point of view.
> =
> From the protocol message semantic point of view, DPNSS=20
> matches SIP messages
>=20 to a larger extent than QSIG - esp wrt the session
> setup/progress/tear-down
> = messages (as=20 opposed to the link/circuit maintenance
> = messages)=20 used for the
> basic call *and* = supplementary=20 services like call transfer, three way
> = conference=20 etc. As an example that I cited in an earlier
>=20 mail, mid call QSIG
> messages like INFO, = NOTIFY=20 & FAC would *all* get carried in SIP INFO
>=20 method - where as, in case of DPNSS, the only mid call =
> message, and which
> has a = direct=20 parlance to SIP INFO is EEM (end to end message;
>=20 equivalent to
> ISUP PAM and to some = extent ISUP=20 APM). For this reason, I'd
> think, = DPNSS=20
> message semantics matches SIP atleast to the = same extent=20 as
> it does for
>=20 ISUP.
>
> = cheers,=20
> - ranjith..
>=20
> -----Original Message----- =
> From: Adam Roach [mailto:adam@dynamicsoft.com]=20
> Sent: Thursday, February 13, 2003 1:19 = AM=20
> To: 'Ranjith Mukundan'; Peterson, Jon; = Jonathan=20 Rosenberg
> Cc: sipping@ietf.org; 'Mark=20 Watson'
> Subject: RE: [Sipping] QSIG Vs = DPNSS=20 MIME
>
>=20
> > -----Original Message----- =
> > From: Ranjith Mukundan [mailto:ranjith.mukundan@wipro.= com]=20
> >
> > In = case of DPNSS=20 too the message semantics matches SIP
> = >=20 messages - atleast to
> > the same = extent as it=20 does for ISUP.
>
> I=20 think you mean "at least to the same extent as it does =
> for QSIG."
> =
> DPNSS, QSIG, and ISDN are all UNI protocols. ISUP = is=20
> an NNI protocol. SIP is end-to-end, which = really=20
> ends up acting more like an NNI protocol than = a=20 UNI
> protocol.
>=20
> /a
> =
>

------=_NextPart_000_0066_01C2D375.82BD17A0-- ------=_NextPartTM-000-040fb114-3dcd-11d7-ba7f-006067005148-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 13 06:47:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09987 for ; Thu, 13 Feb 2003 06:47:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DBv1n14233 for sipping-archive@odin.ietf.org; Thu, 13 Feb 2003 06:57:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DBv1p14230 for ; Thu, 13 Feb 2003 06:57:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09981 for ; Thu, 13 Feb 2003 06:46:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DBuSp14209; Thu, 13 Feb 2003 06:56:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DBtnp14185 for ; Thu, 13 Feb 2003 06:55:49 -0500 Received: from dgesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09971 for ; Thu, 13 Feb 2003 06:45:27 -0500 (EST) Received: from dgismtp06.wcomnet.com ([166.38.58.89]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0HA800DFFWP92L@firewall.wcom.com> for sipping@ietf.org; Thu, 13 Feb 2003 11:46:21 +0000 (GMT) Received: from dgismtp06.wcomnet.com by dgismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HA800H01WP8WT@dgismtp06.wcomnet.com>; Thu, 13 Feb 2003 11:46:21 +0000 (GMT) Received: from dgmexch09.wcomnet.com ([166.38.58.240]) by dgismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HA800H4SWP84B@dgismtp06.wcomnet.com>; Thu, 13 Feb 2003 11:46:20 +0000 (GMT) Received: by DGMEXCH09.wcomnet.com with Internet Mail Service (5.5.2653.19) id <1Y68BC6K>; Thu, 13 Feb 2003 11:46:20 +0000 Content-return: allowed Date: Thu, 13 Feb 2003 11:42:54 +0000 From: "Brierre, Jean Joseph" To: "Sinnreich, Henry" , "'sipforum-discussion@lists.su.se'" , "'sipping@ietf.org'" Message-id: <4E4F4B7EF2A53842971777670C0E513C01C88869@DGEXCH05.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1DBtnp14186 Subject: [Sipping] RE: [Sipforum-discussion] SIP Telephony Device Requirements, Conf iguration and Data Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Henry, below are my comments to the Somefolks draft. Integrated Switch/Hub SIP devices designed for wired Ethernet SHOULD have an uplink port such that another IP device, such as a personal computer, MAY share the network connection. SIP clients MUST prioritize the transmission of RTP traffic over the shared network connection. comment 1: Wish you would remove the Hub reference since this is a shared collision domain concept which I do not recommend for sip client that has real time requirements sharing this shared Ethernet environment with a host device that may also have real time data on the same hub. Switch is the only way to go since ethernet HUB collisions between 2 devices can effect throughput "IP Requirements IP-1: SIP telephony devices MUST be able to acquire an IP address by: Automatic IP address configuration using DHCP, or Manual IP address entry from the device. " Comment 2 Why did you not reference RFC3361 DHCP option for sip ftp://ftp.rfc-editor.org/in-notes/rfc3361.txt this a great MAY RFC to support for sip clients to learn SIP proxy servers Comment 3 No mention was made of support for Visual and Hearing Impaired Special Equipment or even RFC3351 ftp://ftp.rfc-editor.org/in-notes/rfc3351.txt Comment 4 You mention management but only for provisioning, why can we not have SNMP v3 support for network LAN statistics, SIP traffic stats or even RTCP info on the SIP phone. > -----Original Message----- > From: sipforum-discussion-admin@lists.su.se > [mailto:sipforum-discussion-admin@lists.su.se] On Behalf Of > Henry Sinnreich > Sent: Monday, February 10, 2003 8:49 AM > To: 'Jörgen Björkner'; sipforum-discussion@lists.su.se > Subject: [Sipforum-discussion] SIP Telephony Device > Requirements, Configuration and Data > > > For everyone interested SIP phones and other SIP > communication devices, and the 56 IETF coming next month, > please see if you like or dislike or don't care about the draft: > http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-00.txt The idea is to have discussions on the lists, and if there is interest and rough consensus to move ahead with an informational RFC. Would appreciate your comments to sipping@ietf.org , and also to sipforum-discussion@lists.su.se Thanks, Henry Henry Sinnreich WorldCom 400 International Parkway Richardson, Texas 75081 USA _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 13 10:26:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15640 for ; Thu, 13 Feb 2003 10:26:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DFa1b27989 for sipping-archive@odin.ietf.org; Thu, 13 Feb 2003 10:36:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DFa1p27986 for ; Thu, 13 Feb 2003 10:36:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15617 for ; Thu, 13 Feb 2003 10:25:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DFZOp27937; Thu, 13 Feb 2003 10:35:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DFYrp27884 for ; Thu, 13 Feb 2003 10:34:53 -0500 Received: from pmesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15594 for ; Thu, 13 Feb 2003 10:24:26 -0500 (EST) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0HA900KL86YZEY@firewall.wcom.com> for sipping@ietf.org; Thu, 13 Feb 2003 15:28:11 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HA900I016W7PT@dgismtp02.wcomnet.com>; Thu, 13 Feb 2003 15:28:11 +0000 (GMT) Received: from hsinnreich2 ([166.42.33.2]) by dgismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HA900IFR6Y53W@dgismtp02.wcomnet.com>; Thu, 13 Feb 2003 15:27:42 +0000 (GMT) Date: Thu, 13 Feb 2003 09:27:41 -0600 From: Henry Sinnreich In-reply-to: <4E4F4B7EF2A53842971777670C0E513C01C88869@DGEXCH05.wcomnet.com> To: "'Brierre, Jean Joseph'" , sipforum-discussion@lists.su.se, sipping@ietf.org Message-id: <000001c2d374$7367e150$02212aa6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=iso-8859-1 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1DFYrp27885 Subject: [Sipping] RE: [Sipforum-discussion] SIP Telephony Device Requirements, Conf iguration and Data Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Comments 1, 2, and 3 seem obvious - will edit in the next version. Thanks for pointing out. As for comment 4: "why can we not have SNMP v3 support for network LAN statistics, SIP traffic stats or even RTCP info on the SIP phone", it would be interesting to see if SIP phone manufacturers think this is OK for any type of SIP device, or only for certain devices, such as SIP telephony adaptors that support key sets. I believe it makes sense only for latter. Opinions? Thanks, Henry > -----Original Message----- > From: Brierre, Jean Joseph [mailto:Jean.Joseph.Brierre@wcom.com] > Sent: Thursday, February 13, 2003 5:43 AM > To: Sinnreich, Henry; 'sipforum-discussion@lists.su.se'; > 'sipping@ietf.org' > Subject: RE: [Sipforum-discussion] SIP Telephony Device > Requirements, Conf iguration and Data > > > Henry, > > below are my comments to the Somefolks draft. > > > > Integrated Switch/Hub SIP devices designed for wired Ethernet > SHOULD have an uplink port such that another IP device, such > as a personal computer, MAY share the network connection. SIP > clients MUST prioritize the transmission of RTP traffic over > the shared network connection. > > comment 1: > Wish you would remove the Hub reference since this is a > shared collision domain concept which I do not recommend for > sip client that has real time requirements sharing this > shared Ethernet environment with a host device that may also > have real time data on the same hub. Switch is the only way > to go since ethernet HUB collisions between 2 devices can > effect throughput > > "IP Requirements IP-1: SIP telephony devices MUST be able to > acquire an IP address by: Automatic IP address configuration > using DHCP, or Manual IP address entry from the device. " > > Comment 2 > Why did you not reference RFC3361 DHCP option for sip > ftp://ftp.rfc-editor.org/in-notes/rfc3361.txt this a great > MAY RFC to support for sip clients to learn SIP proxy servers > > Comment 3 > No mention was made of support for Visual and Hearing > Impaired Special Equipment or even RFC3351 ftp://ftp.rfc-editor.org/in-notes/rfc3351.txt Comment 4 You mention management but only for provisioning, why can we not have SNMP v3 support for network LAN statistics, SIP traffic stats or even RTCP info on the SIP phone. > -----Original Message----- > From: sipforum-discussion-admin@lists.su.se > [mailto:sipforum-discussion-admin@lists.su.se] On Behalf Of > Henry Sinnreich > Sent: Monday, February 10, 2003 8:49 AM > To: 'Jörgen Björkner'; sipforum-discussion@lists.su.se > Subject: [Sipforum-discussion] SIP Telephony Device > Requirements, Configuration and Data > > > For everyone interested SIP phones and other SIP > communication devices, and the 56 IETF coming next month, > please see if you like or dislike or don't care about the draft: > http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-00.txt The idea is to have discussions on the lists, and if there is interest and rough consensus to move ahead with an informational RFC. Would appreciate your comments to sipping@ietf.org , and also to sipforum-discussion@lists.su.se Thanks, Henry Henry Sinnreich WorldCom 400 International Parkway Richardson, Texas 75081 USA _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 13 10:39:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15965 for ; Thu, 13 Feb 2003 10:39:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DFmv429330 for sipping-archive@odin.ietf.org; Thu, 13 Feb 2003 10:48:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DFmvp29327 for ; Thu, 13 Feb 2003 10:48:57 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15958 for ; Thu, 13 Feb 2003 10:38:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DFm8p29283; Thu, 13 Feb 2003 10:48:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DFlkp29260 for ; Thu, 13 Feb 2003 10:47:46 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15929 for ; Thu, 13 Feb 2003 10:37:19 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA18477; Thu, 13 Feb 2003 10:41:03 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA16953; Thu, 13 Feb 2003 10:41:03 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Feb 2003 10:41:03 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5E35@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henry Sinnreich'" , "'Brierre, Jean Joseph'" , sipforum-discussion@lists.su.se, sipping@ietf.org Date: Thu, 13 Feb 2003 10:41:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1DFlkp29261 Subject: [Sipping] RE: [Sipforum-discussion] SIP Telephony Device Requirements, Conf iguration and Data Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I think it makes sense for any network device. I'm not sure how far I would go, but our network management systems want to know the devices that are out there, and have the basic info any device gives you. Certainly we've been asked by customers for tools that network management can use to determine what is happening when users say "I got a call, but I couldn't hear them". We've offered syslogs and they got amused. I'll admit that my "sipphone" engineers think this is silly. My customers beg to differ. I think the only thing there is to discuss is: How much info is available Are there alarms/traps And, of course, it MUST be SNMPv3 Brian > -----Original Message----- > From: Henry Sinnreich [mailto:Henry.Sinnreich@wcom.com] > Sent: Thursday, February 13, 2003 10:28 AM > To: 'Brierre, Jean Joseph'; sipforum-discussion@lists.su.se; > sipping@ietf.org > Subject: RE: [Sipforum-discussion] SIP Telephony Device Requirements, > Conf iguration and Data > > > Comments 1, 2, and 3 seem obvious - will edit in the next version. > Thanks for pointing out. > > As for comment 4: "why can we not have SNMP v3 support for network LAN > statistics, SIP traffic stats or even RTCP info on the SIP phone", > > it would be interesting to see if SIP phone manufacturers > think this is > OK for any type of SIP device, or only for certain devices, > such as SIP > telephony adaptors that support key sets. I believe it makes > sense only > for latter. Opinions? > > Thanks, Henry > > > -----Original Message----- > > From: Brierre, Jean Joseph [mailto:Jean.Joseph.Brierre@wcom.com] > > Sent: Thursday, February 13, 2003 5:43 AM > > To: Sinnreich, Henry; 'sipforum-discussion@lists.su.se'; > > 'sipping@ietf.org' > > Subject: RE: [Sipforum-discussion] SIP Telephony Device > > Requirements, Conf iguration and Data > > > > > > Henry, > > > > below are my comments to the Somefolks draft. > > > > > > > > Integrated Switch/Hub SIP devices designed for wired Ethernet > > SHOULD have an uplink port such that another IP device, such > > as a personal computer, MAY share the network connection. SIP > > clients MUST prioritize the transmission of RTP traffic over > > the shared network connection. > > > > comment 1: > > Wish you would remove the Hub reference since this is a > > shared collision domain concept which I do not recommend for > > sip client that has real time requirements sharing this > > shared Ethernet environment with a host device that may also > > have real time data on the same hub. Switch is the only way > > to go since ethernet HUB collisions between 2 devices can > > effect throughput > > > > "IP Requirements IP-1: SIP telephony devices MUST be able to > > acquire an IP address by: Automatic IP address configuration > > using DHCP, or Manual IP address entry from the device. " > > > > Comment 2 > > Why did you not reference RFC3361 DHCP option for sip > > ftp://ftp.rfc-editor.org/in-notes/rfc3361.txt this a great > > MAY RFC to support for sip clients to learn SIP proxy servers > > > > Comment 3 > > No mention was made of support for Visual and Hearing > > Impaired Special Equipment or even RFC3351 > ftp://ftp.rfc-editor.org/in-notes/rfc3351.txt > > Comment 4 > You mention management but only for provisioning, why can we not have > SNMP v3 support for network LAN statistics, SIP traffic stats or even > RTCP info on the SIP phone. > > > > > > > > -----Original Message----- > > From: sipforum-discussion-admin@lists.su.se > > [mailto:sipforum-discussion-admin@lists.su.se] On Behalf Of > > Henry Sinnreich > > Sent: Monday, February 10, 2003 8:49 AM > > To: 'Jörgen Björkner'; sipforum-discussion@lists.su.se > > Subject: [Sipforum-discussion] SIP Telephony Device > > Requirements, Configuration and Data > > > > > > For everyone interested SIP phones and other SIP > > communication devices, and the 56 IETF coming next month, > > please see if you like or dislike or don't care about the draft: > > > http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-00.txt > > The idea is to have discussions on the lists, and if there is interest > and rough consensus to move ahead with an informational RFC. Would > appreciate your comments to > > sipping@ietf.org , and also to > > sipforum-discussion@lists.su.se > > Thanks, Henry > > Henry Sinnreich > WorldCom > 400 International Parkway > Richardson, Texas 75081 > USA > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 13 11:17:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16699 for ; Thu, 13 Feb 2003 11:17:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DGRAA31860 for sipping-archive@odin.ietf.org; Thu, 13 Feb 2003 11:27:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DGRAp31857 for ; Thu, 13 Feb 2003 11:27:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16674 for ; Thu, 13 Feb 2003 11:16:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DGQTp31754; Thu, 13 Feb 2003 11:26:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DGPgp31674 for ; Thu, 13 Feb 2003 11:25:42 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16593; Thu, 13 Feb 2003 11:15:14 -0500 (EST) Message-Id: <200302131615.LAA16593@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 13 Feb 2003 11:15:14 -0500 Subject: [Sipping] I-D ACTION:draft-rosenberg-sipping-lease-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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : URI Leasing in the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-rosenberg-sipping-lease-00.txt Pages : 23 Date : 2003-2-12 Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI which can be used by anyone on the Internet to route a call to that specific UA instance. An example of such an application is call transfer, based on the REFER method. To date, a variety of techniques have been proposed for the contruction of such URI. All of them have fatal drawbacks. This document proposes that the problem is actually one of URI leasing - a feature whereby a UA can dynamically request the creation of an address-of-record (AOR) within a domain. Requirements for a URI leasing mechanism are outlined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-lease-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rosenberg-sipping-lease-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-rosenberg-sipping-lease-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-12075046.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosenberg-sipping-lease-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosenberg-sipping-lease-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-12075046.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 13 11:17:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16714 for ; Thu, 13 Feb 2003 11:17:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DGRM431885 for sipping-archive@odin.ietf.org; Thu, 13 Feb 2003 11:27:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DGRMp31882 for ; Thu, 13 Feb 2003 11:27:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16694 for ; Thu, 13 Feb 2003 11:16:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DGQOp31734; Thu, 13 Feb 2003 11:26:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DGPNp31664 for ; Thu, 13 Feb 2003 11:25:23 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16518; Thu, 13 Feb 2003 11:14:55 -0500 (EST) Message-Id: <200302131614.LAA16518@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 13 Feb 2003 11:14:55 -0500 Subject: [Sipping] I-D ACTION:draft-rosenberg-sipping-conferencing-framework-01.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Framework for Conferencing with the Session Initiation Protocol Author(s) : J. Rosenberg Filename : draft-rosenberg-sipping-conferencing-framework-01.txt Pages : 39 Date : 2003-2-12 The Session Initiation Protocol (SIP) supports the initiation, modification, and termination of media sessions between user agents. These sessions are managed by SIP dialogs, which represent a SIP relationship between a pair of user agents. Because dialogs are between pairs of user agents, SIP's usage for two-party communications (such as a phone call), is obvious. Communications sessions with multiple participants, generally known as conferencing, are more complicated. This document defines a framework for how such conferencing can occur. This framework describes the overall architecture, terminology, and protocol components needed for multi- party conferencing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-conferencing-framework-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rosenberg-sipping-conferencing-framework-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rosenberg-sipping-conferencing-framework-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-12074957.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosenberg-sipping-conferencing-framework-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosenberg-sipping-conferencing-framework-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-12074957.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 13 12:55:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20055 for ; Thu, 13 Feb 2003 12:55:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DI5rp06436 for sipping-archive@odin.ietf.org; Thu, 13 Feb 2003 13:05:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DI5rp06431 for ; Thu, 13 Feb 2003 13:05:53 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20032 for ; Thu, 13 Feb 2003 12:55:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DHwap05946; Thu, 13 Feb 2003 12:58:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DHvvp05908 for ; Thu, 13 Feb 2003 12:57:57 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19487; Thu, 13 Feb 2003 12:47:28 -0500 (EST) Message-Id: <200302131747.MAA19487@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 13 Feb 2003 12:47:28 -0500 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-cc-transfer-01.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : Session Initiation Protocol Call Control - Transfer Author(s) : R. Sparks, A. Johnston Filename : draft-ietf-sipping-cc-transfer-01.txt Pages : 32 Date : 2003-2-12 This document describes providing Call Transfer capabilities in the Session Initiation Protocol (SIP). This work is part of the SIP Multiparty Call Control Framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-transfer-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sipping-cc-transfer-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sipping-cc-transfer-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-13130639.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-cc-transfer-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-cc-transfer-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-13130639.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 13 13:37:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21587 for ; Thu, 13 Feb 2003 13:37:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DIepn10151 for sipping-archive@odin.ietf.org; Thu, 13 Feb 2003 13:40:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DIepp10148 for ; Thu, 13 Feb 2003 13:40:51 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21550 for ; Thu, 13 Feb 2003 13:37:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DIdCp09999; Thu, 13 Feb 2003 13:39:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DIWMp08990 for ; Thu, 13 Feb 2003 13:32:22 -0500 Received: from dgesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21055 for ; Thu, 13 Feb 2003 13:28:35 -0500 (EST) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0HA90097HFCDWU@firewall.wcom.com> for sipping@ietf.org; Thu, 13 Feb 2003 18:29:01 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HA900601F70U4@pmismtp01.wcomnet.com> for sipping@ietf.org; Thu, 13 Feb 2003 18:29:01 +0000 (GMT) Received: from ajohnston.wcom.com ([166.42.33.198]) by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HA9006B1FBWYW@pmismtp01.wcomnet.com> for sipping@ietf.org; Thu, 13 Feb 2003 18:28:46 +0000 (GMT) Date: Thu, 13 Feb 2003 12:28:20 -0600 From: Alan Johnston Subject: Re: [Sipping] I-D ACTION:draft-ietf-sipping-cc-transfer-01.txt In-reply-to: <200302131747.MAA19487@ietf.org> X-Sender: Alan.Johnston@pop.mcit.com To: sipping@ietf.org Message-id: <5.1.1.6.0.20030213122231.0411d8d0@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.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: , All, The major changes from the previous draft are the addition of: - Section on use of Referred-By header. - Selected message details. - Flow for attended transfer with non-globally routable Contact URI - Flow for attended transfer fallback to unattended transfer. - Security Considerations Section. Otherwise, the draft is quite stable and has no open issues or To Do items that the authors are aware of. Thanks, Alan Johnston WorldCom sip:alan@digitalari.com At 12:47 PM 2/13/2003 -0500, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Session Initiation Proposal Investigation >Working Group of the IETF. > > Title : Session Initiation Protocol Call Control - Transfer > Author(s) : R. Sparks, A. Johnston > Filename : draft-ietf-sipping-cc-transfer-01.txt > Pages : 32 > Date : 2003-2-12 > >This document describes providing Call Transfer capabilities in the >Session Initiation Protocol (SIP). This work is part of the SIP >Multiparty Call Control Framework. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-transfer-01.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-sipping-cc-transfer-01.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-sipping-cc-transfer-01.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2003-2-13130639.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-sipping-cc-transfer-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 mailnull@www1.ietf.org Thu Feb 13 14:25:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22784 for ; Thu, 13 Feb 2003 14:25:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DJT4v13000 for sipping-archive@odin.ietf.org; Thu, 13 Feb 2003 14:29:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DJT3p12997 for ; Thu, 13 Feb 2003 14:29:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22776 for ; Thu, 13 Feb 2003 14:25:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DJSKp12946; Thu, 13 Feb 2003 14:28:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DJPtp12831 for ; Thu, 13 Feb 2003 14:25:55 -0500 Received: from fox.iptel.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22706 for ; Thu, 13 Feb 2003 14:22:07 -0500 (EST) Received: from jku07.fokus.fraunhofer.de (dhcp203.fokus.gmd.de [195.37.78.203]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id h1DJPjJ04910; Thu, 13 Feb 2003 20:25:45 +0100 Message-Id: <5.2.0.9.0.20030213195339.03150b98@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 13 Feb 2003 19:54:14 +0100 To: Henry Sinnreich , "'Gonzalo Camarillo'" , "'sipping'" From: Jiri Kuthan Subject: RE: [Sipping] New version of the SIP-AAA reqs draft Cc: "'John Loughney'" In-Reply-To: <001201c2d174$03ac7300$358032a6@hsinnreich2> References: <3E47912B.CE58BFB5@lmf.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , At 03:19 AM 2/11/2003, Henry Sinnreich wrote: >> We will now try to get the work on the diameter-based solution going. > >As has been mentioned here, 99.999% (five nines :-0>) of existing >implementations and deployment are RADIUS. After RADIUS come the web >services. > >I suggest therefore to start with RADIUS instead. I'm sharing the same deployment experience and second the same plan: RADIUS. -Jiri _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 13 14:27:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22845 for ; Thu, 13 Feb 2003 14:27:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DJUxm13089 for sipping-archive@odin.ietf.org; Thu, 13 Feb 2003 14:30:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DJUwp13085 for ; Thu, 13 Feb 2003 14:30:58 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22824 for ; Thu, 13 Feb 2003 14:27:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DJUSp13068; Thu, 13 Feb 2003 14:30:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DJPup12835 for ; Thu, 13 Feb 2003 14:25:56 -0500 Received: from fox.iptel.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22708 for ; Thu, 13 Feb 2003 14:22:08 -0500 (EST) Received: from jku07.fokus.fraunhofer.de (dhcp203.fokus.gmd.de [195.37.78.203]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id h1DJPjJ04918; Thu, 13 Feb 2003 20:25:45 +0100 Message-Id: <5.2.0.9.0.20030213195458.04501ea0@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 13 Feb 2003 19:56:42 +0100 To: john.loughney@nokia.com, , , From: Jiri Kuthan Subject: RE: [Sipping] New version of the SIP-AAA reqs draft In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , At 07:46 PM 2/11/2003, john.loughney@nokia.com wrote: >Hi Henry, > >> >but one option is develop a solution using >> > Diameter in RADIUS-compatibility mode. >> >> OK, this is better than nothing. We'll take what we can :-) >> >> As mentioned, the installed base is RADIUS, no matter how >> voluminous the DIAMETER literature may be. > >I think the issues is that the IETF should recommend what is the >right thing to do & why. If people choose to do something else, >well, that is life. Remember that running code does not necessarily mean something known to compile -- that is something known to be deployed. >I understand what you are asking but I do note that some >people have thought that the potential for AAA is much greater >than the existing installed base. I actually think that the deployment argument is a very important one. -Jiri _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 13 15:29:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26549 for ; Thu, 13 Feb 2003 15:29:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DKWdh17652 for sipping-archive@odin.ietf.org; Thu, 13 Feb 2003 15:32:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DKWdp17649 for ; Thu, 13 Feb 2003 15:32:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26499 for ; Thu, 13 Feb 2003 15:28:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DKVcp17563; Thu, 13 Feb 2003 15:31:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DKUkp17507 for ; Thu, 13 Feb 2003 15:30:46 -0500 Received: from dgesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26339 for ; Thu, 13 Feb 2003 15:26:56 -0500 (EST) Received: from pmismtp06.wcomnet.com ([166.38.62.54]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0HA900M3TKU2ZW@firewall.wcom.com> for sipping@ietf.org; Thu, 13 Feb 2003 20:27:38 +0000 (GMT) Received: from pmismtp06.wcomnet.com by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HA900301KU1MY@pmismtp06.wcomnet.com>; Thu, 13 Feb 2003 20:27:38 +0000 (GMT) Received: from hsinnreich2 ([166.35.136.36]) by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HA9002GQKTQZ9@pmismtp06.wcomnet.com>; Thu, 13 Feb 2003 20:27:27 +0000 (GMT) Date: Thu, 13 Feb 2003 14:27:27 -0600 From: Henry Sinnreich In-reply-to: To: "=?iso-8859-1?Q?'Gunnar_Hellstr=F6m'?=" , "=?iso-8859-1?Q?'J=F6rgen_Bj=F6rkner'?=" , sipforum-discussion@lists.su.se Cc: sipping@ietf.org Message-id: <001101c2d39e$5378e2c0$248823a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=iso-8859-1 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1DKUkp17508 Subject: [Sipping] RE: [Sipforum-discussion] SIP Telephony Device Requirements, Configuration and Data Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Gunnar Hellström wrote: > SIP-xx, analogue text support: > SIP-zz, digital text support: > In 4.11 Ringer Behaviour > Add to References > ----------------- > [y] G. Hellstrom: "RTP Payload for Text Conversation.", RFC > 2793, IETF, May 2000. [z] ITU-T Recommendation V.18 Are all excellent points that we will add. Thanks for the comments! Henry > -----Original Message----- > From: Gunnar Hellström [mailto:gunnar.hellstrom@omnitor.se] > Sent: Thursday, February 13, 2003 2:22 PM > To: Henry Sinnreich; 'Jörgen Björkner'; > sipforum-discussion@lists.su.se > Cc: sipping@ietf.org > Subject: Re: [Sipforum-discussion] SIP Telephony Device > Requirements, Configuration and Data > > > Henry, > > It is mentioned in the introduction to the document that > "text shall be kept in mind". > > I suggest some specific text items to be entered that are in > line with existing standardisation, and accessibility needs > and useful for all: > > -------------------------------------------------------------- > -------------- > ------------------- > SIP-xx, analogue text support: SIP adapter devices (for > analog phone lines) > MUST support conversion between real time text transmission > using RFC 2793 [y] > and text telephones according to ITU-T V.18 [x] allowing > alternating use of > text and voice. SIP clients MUST fallback to G.711 if > RFC2793 connection fails. > > > SIP-zz, digital text support: SIP telephone devices MUST support > real time text conversation using RFC 2793 [y] for the text stream. > It MUST be possible to use text simultaneously with voice. > > > > --------------------------------------------- > In 4.11 Ringer Behaviour : add the section below for the > purpose of deaf, hearing impaired, deaf-blind people and > people in the garden and noisy > locations: > > SIP Telephony devices MUST provide an external interface to > an external alerting system. > > > > Add to References > ----------------- > [y] G. Hellstrom: "RTP Payload for Text Conversation.", RFC > 2793, IETF, May 2000. [z] ITU-T Recommendation V.18 > "Operational and interworking requirements for DCEs operating > in the text telephone mode", November 2000 with amendment > November 2002. > > -------------------------------------------------------------- > -------------- > ------- > > > > > Thanks > ------------------------------------------- > Gunnar Hellström > Omnitor AB > Renathvägen 2 > SE 121 37 Johanneshov > SWEDEN > +46 8 556 002 03 > Mob: +46 708 204 288 > www.omnitor.se > Gunnar.Hellstrom@Omnitor.se > -------------------------------------------- > > > -----Ursprungligt meddelande----- > > Från: sipforum-discussion-admin@lists.su.se > > [mailto:sipforum-discussion-admin@lists.su.se]För Henry Sinnreich > > Skickat: den 10 februari 2003 15:49 > > Till: 'Jörgen Björkner'; sipforum-discussion@lists.su.se > > Ämne: [Sipforum-discussion] SIP Telephony Device Requirements, > > Configuration and Data > > > > > > For everyone interested SIP phones and other SIP communication > > devices, and the 56 IETF coming next month, please see if > you like or > > dislike or don't care about the draft: > > > > > http://www.ietf.org/internet-> drafts/draft-sinnreich-sipdev-req-00.txt > > > > The idea is to have discussions on the lists, and if there > is interest > > and rough consensus to move ahead with an informational RFC. Would > > appreciate your comments to > > > > sipping@ietf.org , and also to > > > > sipforum-discussion@lists.su.se > > > > Thanks, Henry > > > > Henry Sinnreich > > WorldCom > > 400 International Parkway > > Richardson, Texas 75081 > > USA > > > > > > > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 14 02:56:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12849 for ; Fri, 14 Feb 2003 02:56:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1E7xcD03843 for sipping-archive@odin.ietf.org; Fri, 14 Feb 2003 02:59:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1E7xbp03840 for ; Fri, 14 Feb 2003 02:59:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12781 for ; Fri, 14 Feb 2003 02:55:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1E7wxp03783; Fri, 14 Feb 2003 02:59:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1E7tBp03668 for ; Fri, 14 Feb 2003 02:55:11 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12708 for ; Fri, 14 Feb 2003 02:51:08 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.139]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h1E7suYH025351; Fri, 14 Feb 2003 02:54:56 -0500 (EST) Message-ID: <3E4CA0CB.80305@dynamicsoft.com> Date: Fri, 14 Feb 2003 02:54:51 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Johnston CC: sipping@ietf.org Subject: Re: [Sipping] New I-D on URI leasing References: <5.1.1.6.0.20030212193806.02032098@pop.mcit.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alan Johnston wrote: > Just to clarify and expand on my earlier short comments... > > I'm not unhappy that the solution proposed in the draft is similar to > the one discussed in cc-transfer. The method does work, and we can > discuss whether it should be two REGISTERs or one LEASE and one > REGISTER. However, both approaches are multi-step, which others > objected to when it was discussed at IETF-55. I don't see a problem in adding steps if its done asynchronously with calls. That is, with the mechanism I discuss, you would be allocated a namespace from which you can choose URI. THerefore, for each call, there is zero additional protocol operations needed. > > I had hoped that a new proposal was coming, or a way to make Rohan's > escaped Route header in a Contact work. I'm not sure whether you are trying to imply that there is nothign new in my draft? > This approach, (4.4 in this > draft) does not actually suffer from the problems listed - if multiple > proxies must be traversed, multiple URIs can be escaped into the Route > header. How does a UA learn the route headers to include? If you say that they are taken from the route set of the dialog, then how does a UA know which ones need to be included? How does a UA know whether a different caller is supposed to use that same set of proxies? The route set from the dialog is also purposefully scoped to that dialog, so that proxies can include information in it that is related to the dialog. So, would a UA discard that user part? The URI might not work without that. A smart proxy that embeds dialog information in the user part, so that it can reject calls with route headers it never generated, would cause that to fail. > The real problem with this approach is that it violates Table 1 > in RFC 3261 so would be ignored by all RFC 3261 compliant UAs. There are some additional problems, as above. > The > backwards compatibility problem with pre-bis-04 UAs is even worse. > Since under the old Record-Route rules the Contact is included in the > Route header, you could potentially have a URI in a Route header with > an escaped Route header - yuk! However, there might be a clever > solution to work around this problem. This is the only solution that I > know of that meets REQ-8. No, thats not true. The mechanism I proposed, if the lease and register operations are combined, can be made to work without network state. > > REQ-9 is a bit strange - the anonymity of a Contact is a very small part > of the total anonymity picture. We have already discussed, in the context of rfc3323, several different notions of what encompasses privacy. This requirement is meant to rule out solutions that, for example, would require the user's AOR to be used. It seems this requirement could > simply be met by having the user portion of the Contact be a random > string. Yes. The privacy discussion in 4.2 about the call center operator is > simplistic - for privacy, much more than just fixing Contact is required > and would be used in practice. As I mentioned, there are various levels of privacy that we have recognized as useful. > > I'm not sure understand the motivation for REQ-11. I don't know why a > UA would want to generate a unique Contact for each dialog - it seems > like quite a burden on the UA and a difficult requirement for a solution > to meet. It seems like there is some sort of security reason for this, > but it is not stated. This is what I had in mind. You and I are talking. I want to transfer you to Robert. You don't want anyone to generally be able to call your device - they should go through your normal SIP AOR that identifies you as a user. However, for the transfer to work, I need a URI for your device. If you could create those contact URIs, you could create one that contains a hash of the dialog ID with me, or a timestamp embedded. This way, if you should receive an INVITE to that URI, you could check it to make sure it still valid. If not, you reject the INVITE. > > One minor correction - the transfer problem is with attended transfer > only, not blind transfer or transfer in general. Yes, that is right. My error. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 14 06:50:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17467 for ; Fri, 14 Feb 2003 06:50:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1EBrk519080 for sipping-archive@odin.ietf.org; Fri, 14 Feb 2003 06:53:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EBrkp19077 for ; Fri, 14 Feb 2003 06:53:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17429 for ; Fri, 14 Feb 2003 06:49:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EBr8p19033; Fri, 14 Feb 2003 06:53:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EBqpp18961 for ; Fri, 14 Feb 2003 06:52:51 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17375; Fri, 14 Feb 2003 06:48:44 -0500 (EST) Message-Id: <200302141148.GAA17375@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 14 Feb 2003 06:48:44 -0500 Subject: [Sipping] I-D ACTION:draft-johnston-sipping-cc-conferencing-01.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Session Initiation Protocol Call Control - Conferencing for User Agents Author(s) : A. Johnston, O. Levin Filename : draft-johnston-sipping-cc-conferencing-01.txt Pages : 24 Date : 2003-2-11 This document defines conferencing call control features for the Session Initiation Protocol (SIP). This document builds on the Conferencing Requirements and Framework documents to define how a tightly coupled SIP conference works. The approach is explored from different user agent (UA) types perspective: conference-unaware, conference-aware and focus UAs. The use of URIs in conferencing, OPTIONS for capabilities discovery, and call control using REFER are covered in detail with example call flow diagrams. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-johnston-sipping-cc-conferencing-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-johnston-sipping-cc-conferencing-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-johnston-sipping-cc-conferencing-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-14070713.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-johnston-sipping-cc-conferencing-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-johnston-sipping-cc-conferencing-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-14070713.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 14 10:40:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25011 for ; Fri, 14 Feb 2003 10:40:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1EFiDA02108 for sipping-archive@odin.ietf.org; Fri, 14 Feb 2003 10:44:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EFiDp02105 for ; Fri, 14 Feb 2003 10:44:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24995 for ; Fri, 14 Feb 2003 10:39:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EFhWp02079; Fri, 14 Feb 2003 10:43:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EFgcp02040 for ; Fri, 14 Feb 2003 10:42:38 -0500 Received: from mail-blue.research.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24946 for ; Fri, 14 Feb 2003 10:38:25 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 5FD604CEA0 for ; Fri, 14 Feb 2003 10:42:11 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id KAA26212; Fri, 14 Feb 2003 10:42:08 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id KAA68016; Fri, 14 Feb 2003 10:41:41 -0500 (EST) Date: Fri, 14 Feb 2003 10:41:41 -0500 (EST) Message-Id: <200302141541.KAA68016@fish.research.att.com> To: sipping@ietf.org Subject: Re: [Sipping] Expert review for draft-burger-sipping-netann-04.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , There is one issue in dealing with announcements and announcement servers that doesn't arise with normal sessions - the timing of the session termination. In a normal media session, the media is being generated in real time and transmitted via RTP to the UAC. When the source of the media stops, the session is terminated with a BYE, and the UAC closes both the signaling and media paths. While there is potential for a race, it is not significant. However, when the media is an announcement, contained likely within a single (possibly large) file, it is conceivable that the server will send the (large) RTP packets to the UAC, and then send a BYE while the UAC has most of the announcement still unplayed. The basic architectural question is whether it is the responsibility of the UAC to drain any pending media before closing a session. I do not know of any such requirement in RFC3261. Is it considered a common implementation practice to do so? Alternatively, it could be the responsibility of the announcement server to delay sending the BYE (or 4xx response) based on the expected playout time, though it is not clear how that would be calculated. One choice or the other needs to be stated, and required, in order to achieve interoperability. I also have concerns about the use of 487 to terminate early media sessions. This has been raised by others. Bill Marshall wtm@research.att.com -----original message----- Date: Mon, 10 Feb 2003 12:39:56 +0200 From: Gonzalo Camarillo To: sipping Subject: [Sipping] Expert review for draft-burger-sipping-netann-04.txt Folks, We would like the SIPPING working group to provide expert review of: http://www.ietf.org/internet-drafts/draft-burger-sipping-netann-04.txt The authors have requested individual publication of this document. Expert Review will close on March 10th, 2003 Thanks, Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 14 17:37:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07933 for ; Fri, 14 Feb 2003 17:37:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1EMfQE32410 for sipping-archive@odin.ietf.org; Fri, 14 Feb 2003 17:41:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EMfQp32407 for ; Fri, 14 Feb 2003 17:41:26 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07893 for ; Fri, 14 Feb 2003 17:37:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EMeQp32324; Fri, 14 Feb 2003 17:40:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EMd6p32144 for ; Fri, 14 Feb 2003 17:39:06 -0500 Received: from dgesmtp01.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07798 for ; Fri, 14 Feb 2003 17:34:44 -0500 (EST) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (Iplanet MTA) with ESMTP id <0HAB00B0ZLDSXH@firewall.wcom.com> for sipping@ietf.org; Fri, 14 Feb 2003 22:34:40 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HAB00801LDSCL@pmismtp01.wcomnet.com>; Fri, 14 Feb 2003 22:34:40 +0000 (GMT) Received: from ajohnston.wcom.com ([166.50.98.4]) by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HAB00685LDPVF@pmismtp01.wcomnet.com>; Fri, 14 Feb 2003 22:34:39 +0000 (GMT) Date: Fri, 14 Feb 2003 16:33:38 -0600 From: Alan Johnston Subject: Re: [Sipping] New I-D on URI leasing In-reply-to: <3E4CA0CB.80305@dynamicsoft.com> X-Sender: Alan.Johnston@pop.mcit.com To: Jonathan Rosenberg Cc: sipping@ietf.org Message-id: <5.1.1.6.0.20030214152549.01f45600@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; charset=us-ascii; format=flowed References: <5.1.1.6.0.20030212193806.02032098@pop.mcit.com> Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , At 02:54 AM 2/14/2003 -0500, Jonathan Rosenberg wrote: >Alan Johnston wrote: >>Just to clarify and expand on my earlier short comments... >>I'm not unhappy that the solution proposed in the draft is similar to >>the one discussed in cc-transfer. The method does work, and we can >>discuss whether it should be two REGISTERs or one LEASE and one >>REGISTER. However, both approaches are multi-step, which others objected >>to when it was discussed at IETF-55. > >I don't see a problem in adding steps if its done asynchronously with >calls. That is, with the mechanism I discuss, you would be allocated a >namespace from which you can choose URI. THerefore, for each call, there >is zero additional protocol operations needed. >>I had hoped that a new proposal was coming, or a way to make Rohan's >>escaped Route header in a Contact work. > >I'm not sure whether you are trying to imply that there is nothign new in >my draft? Of course not. >>This approach, (4.4 in this draft) does not actually suffer from the >>problems listed - if multiple proxies must be traversed, multiple URIs >>can be escaped into the Route header. > >How does a UA learn the route headers to include? If you say that they are >taken from the route set of the dialog, then how does a UA know which ones >need to be included? How does a UA know whether a different caller is >supposed to use that same set of proxies? The route set from the dialog is >also purposefully scoped to that dialog, so that proxies can include >information in it that is related to the dialog. So, would a UA discard >that user part? The URI might not work without that. A smart proxy that >embeds dialog information in the user part, so that it can reject calls >with route headers it never generated, would cause that to fail. > The Route URI wouldn't be extracted from a dialog, it would have to be learned or provisioned similar to a pre-loaded Route URI. The Route header used also would be similar to a pre-loaded Route in that it would never contain any specific dialog information. Think of how a normal user's AOR is routed. Usually, a DNS SRV lookup (or similar) is performed on the host name which initially routes the request to a set of proxies. These proxies then take care of all the routing between the proxy and the endpoint. If multiple proxies need to be traversed, the proxy first proxy inserts them. All an embedded Route header in a Contact needs to do is to cause essentially the same DNS lookups to occur so the request reaches the same initial set of proxies. This another way of stating your requirement that the device URI be in the same domain as the AOR URI for the user - they must resolve to a similar set of proxies, unless the topology is trivial in which case it doesn't matter. >>The real problem with this approach is that it violates Table 1 in RFC >>3261 so would be ignored by all RFC 3261 compliant UAs. > >There are some additional problems, as above. > > >>The backwards compatibility problem with pre-bis-04 UAs is even worse. >>Since under the old Record-Route rules the Contact is included in the >>Route header, you could potentially have a URI in a Route header with >>an escaped Route header - yuk! However, there might be a clever solution >>to work around this problem. This is the only solution that I know of >>that meets REQ-8. > >No, thats not true. The mechanism I proposed, if the lease and register >operations are combined, can be made to work without network state. There is still a binding between the device URI template and the device itself. Regardless of whether this is done through a REGISTER or a LEASE, it is still state information and is effectively the same as a registration. >>REQ-9 is a bit strange - the anonymity of a Contact is a very small part >>of the total anonymity picture. > >We have already discussed, in the context of rfc3323, several different >notions of what encompasses privacy. This requirement is meant to rule out >solutions that, for example, would require the user's AOR to be used. The use of the user's AOR is already ruled out by the most important requirement that it resolve uniquely to a device without forking. By the way, that requirement is mentioned in the definition section 2 but not in the requirements section 6. A user's AOR in a Contact would also cause all sorts of other problems with respect to forking of re-INVITEs, etc. > It seems this requirement could >>simply be met by having the user portion of the Contact be a random string. > >Yes. > > The privacy discussion in 4.2 about the call center operator is >>simplistic - for privacy, much more than just fixing Contact is required >>and would be used in practice. > >As I mentioned, there are various levels of privacy that we have >recognized as useful. > >>I'm not sure understand the motivation for REQ-11. I don't know why a UA >>would want to generate a unique Contact for each dialog - it seems like >>quite a burden on the UA and a difficult requirement for a solution to >>meet. It seems like there is some sort of security reason for this, but >>it is not stated. > >This is what I had in mind. You and I are talking. I want to transfer you >to Robert. You don't want anyone to generally be able to call your device >- they should go through your normal SIP AOR that identifies you as a >user. However, for the transfer to work, I need a URI for your device. If >you could create those contact URIs, you could create one that contains a >hash of the dialog ID with me, or a timestamp embedded. This way, if you >should receive an INVITE to that URI, you could check it to make sure it >still valid. If not, you reject the INVITE. Usually, the use of a Contact URI is involves in a dialog. For example, in an attended transfer, there is a Replaces header. The UA then knows which dialog is being replaced - there is no requirement for the Contact to be limited to the duration of the dialog - the rejection is based on the Replaces header and whether the requester is permitted to replace dialogs. The same thing for a conference - the focus will know if the conference is still valid and whether the requester may join based on the conference policy for that URI - not based on the URI itself which just references the conference instance. In SIP, we have always said that a Contact URI may not be valid outside the dialog. It has never been a requirement that it never be valid outside a dialog. I'm still not seeing enough justification for this requirement - seems like a lot of pain for little gain, but I'd be interested in other's opinions. If this requirement could be met easily, I'd be happy with it, but it introduce a whole set of name space requirements on a UA - seems like a lot of complexity. >>One minor correction - the transfer problem is with attended transfer >>only, not blind transfer or transfer in general. > >Yes, that is right. My error. > >-Jonathan R. >-- >Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.dynamicsoft.com > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sat Feb 15 00:57:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16339 for ; Sat, 15 Feb 2003 00:57:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1F61eG23913 for sipping-archive@odin.ietf.org; Sat, 15 Feb 2003 01:01:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1F61ep23910 for ; Sat, 15 Feb 2003 01:01:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16334 for ; Sat, 15 Feb 2003 00:57:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1F610p23871; Sat, 15 Feb 2003 01:01:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1F5xWp23798 for ; Sat, 15 Feb 2003 00:59:32 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16295 for ; Sat, 15 Feb 2003 00:55:01 -0500 (EST) Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18jvLW-000HAk-00; Fri, 14 Feb 2003 21:58:42 -0800 To: Jiri Kuthan cc: john.loughney@nokia.com, Henry.Sinnreich@wcom.com, Gonzalo.Camarillo@lmf.ericsson.se, sipping@ietf.org, aboba@internaut.com Subject: Re: [Sipping] New version of the SIP-AAA reqs draft In-Reply-To: Message from Jiri Kuthan of "Thu, 13 Feb 2003 19:56:42 +0100." <5.2.0.9.0.20030213195458.04501ea0@mailhost.fokus.gmd.de> Date: Fri, 14 Feb 2003 21:58:40 -0800 From: Allison Mankin Message-Id: Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Jiri, It always seems good to be able to stay with installed base, but there's a factor against our supporting RADIUS drafts for SIP's accounting - safety. Even though there is deployment, there are some extremely bad cases of damage in production, and the IETF has concluded that RADIUS is not suitable for usage-based accounting (RFC2975). Unless there is no intention of having in SIP accounting usage-based, monetary, auditable applications, RADIUS is not the solution. The protocol just does not preserve a complete stream of reliable accounting records that are auditable on any level, especially with any roaming. As Bernard Aboba stated to this WG, quoting Mike O'Dell, the use of RADIUS may even be illegal in situations where there is an authority over the billing. Records are too easily lost by the protocol. This is stated clearly by RFC2975. This is the reason why the Operations and Mgt Area developed Diameter. On these technical* grounds, that the RADIUS protocol does not have enough reliability, the work must be based on the Diameter protocol, which is now approved. Alternatively, work could be done that does not include usage-based accounting, but this does not seem to be what is envisioned in the SIPPING AAA requirements. Allison P.S. There's a current investigation of RADIUS compatibility mode in Diameter for this - more needs to be thought about it. > > At 07:46 PM 2/11/2003, john.loughney@nokia.com wrote: > >Hi Henry, > > > >> >but one option is develop a solution using > >> > Diameter in RADIUS-compatibility mode. > >> > >> OK, this is better than nothing. We'll take what we can :-) > >> > >> As mentioned, the installed base is RADIUS, no matter how > >> voluminous the DIAMETER literature may be. > > > >I think the issues is that the IETF should recommend what is the > >right thing to do & why. If people choose to do something else, > >well, that is life. > > Remember that running code does not necessarily mean something known > to compile -- that is something known to be deployed. > > >I understand what you are asking but I do note that some > >people have thought that the potential for AAA is much greater > >than the existing installed base. > > I actually think that the deployment argument is a very important one. > > -Jiri > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 mailnull@www1.ietf.org Mon Feb 17 08:43:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22113 for ; Mon, 17 Feb 2003 08:43:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1HDmi627393 for sipping-archive@odin.ietf.org; Mon, 17 Feb 2003 08:48:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HDmip27390 for ; Mon, 17 Feb 2003 08:48:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22106 for ; Mon, 17 Feb 2003 08:43:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HDlhp27334; Mon, 17 Feb 2003 08:47:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HDj3p27271 for ; Mon, 17 Feb 2003 08:45:03 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22065 for ; Mon, 17 Feb 2003 08:39:24 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1HDhCAv022758 for ; Mon, 17 Feb 2003 14:43:12 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVLW430; Mon, 17 Feb 2003 14:43:12 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h1HDhCll019705 for ; Mon, 17 Feb 2003 15:43:12 +0200 (EET) Message-ID: <3E50E6EE.AD3DDE28@lmf.ericsson.se> Date: Mon, 17 Feb 2003 15:43:10 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sipping Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] New version of transcoding 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, the transcoding design team has produced a new version of the draft below: http://standards.ericsson.net/gonzalo/papers/draft-camarillo-sip-deaf-02.txt http://standards.ericsson.net/gonzalo/papers/draft-camarillo-sip-deaf-02.pdf Comments and suggestions are welcome. Regards, Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Feb 17 10:58:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24578 for ; Mon, 17 Feb 2003 10:58:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1HG45E02703 for sipping-archive@odin.ietf.org; Mon, 17 Feb 2003 11:04:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HG45p02700 for ; Mon, 17 Feb 2003 11:04:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24570 for ; Mon, 17 Feb 2003 10:58:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HG3Pp02678; Mon, 17 Feb 2003 11:03:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HG2bp02627 for ; Mon, 17 Feb 2003 11:02:37 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24544 for ; Mon, 17 Feb 2003 10:56:57 -0500 (EST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-msg-core-2.cisco.com (8.12.2/8.12.6) with ESMTP id h1HG0Usv010194 for ; Mon, 17 Feb 2003 08:00:30 -0800 (PST) Received: from [10.32.254.183] (stealth-10-32-254-183.cisco.com [10.32.254.183]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id ABN11328; Mon, 17 Feb 2003 08:00:43 -0800 (PST) Date: Mon, 17 Feb 2003 11:00:37 -0500 From: "David R. Oran" To: sipping@ietf.org Subject: Re: [Sipping] I-D ACTION:draft-rosenberg-sipping-lease-00.txt Message-ID: <269039778.1045479637@[10.32.254.183]> In-Reply-To: <200302131615.LAA16593@ietf.org> References: <200302131615.LAA16593@ietf.org> X-Mailer: Mulberry/3.0.0 (Win32) 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Title : URI Leasing in the Session Initiation Protocol (SIP) > Author(s) : J. Rosenberg > Filename : draft-rosenberg-sipping-lease-00.txt > Pages : 23 > Date : 2003-2-12 > In general I like the direction this is going. I have a query. Did you consider making the creation and communication of the GRUU simply a side-effect of a REGISTER operation as opposed to a separate method? In other words, the REGISTER would optionally request the construction of a (range of/template for) GRUUs for the UA, and the response would contain the constructed values. This would seem to meet all of the requirements, including, at least provisionally, the requirement for not substantially increasing the domain-level state stored by proxies. One small point bears upon the above. In the text you say that a lease should not extend beyond the registration expiration of a registered UA. However, the requirement is weaker; it only says that the domain has final say over the lease duration. Was this intentional? If so I would think this complicates the life of a registrar somewhat, compared with managing GRUUs just like registrations, or state directly bound to registrations. I can see a rather straightforward implementation if leases are simply extra stuff associated with a registration. I have a harder time seeing a simple implementation if a new method or some completely separate mechanism is used. Dave. Dave. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Feb 17 11:07:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24767 for ; Mon, 17 Feb 2003 11:07:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1HGD0003782 for sipping-archive@odin.ietf.org; Mon, 17 Feb 2003 11:13:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HGD0p03777 for ; Mon, 17 Feb 2003 11:13:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24761 for ; Mon, 17 Feb 2003 11:07:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HGCAp03733; Mon, 17 Feb 2003 11:12:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HGB9p03671 for ; Mon, 17 Feb 2003 11:11:09 -0500 Received: from pmesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24694 for ; Mon, 17 Feb 2003 11:05:28 -0500 (EST) Received: from pmismtp06.wcomnet.com ([166.38.62.54]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0HAG00JJBNH1V1@firewall.wcom.com> for sipping@ietf.org; Mon, 17 Feb 2003 16:07:49 +0000 (GMT) Received: from pmismtp06.wcomnet.com by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HAG00501NH1EA@pmismtp06.wcomnet.com>; Mon, 17 Feb 2003 16:07:49 +0000 (GMT) Received: from hsinnreich2 ([166.50.136.49]) by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HAG0046ZNGYK3@pmismtp06.wcomnet.com>; Mon, 17 Feb 2003 16:07:48 +0000 (GMT) Date: Mon, 17 Feb 2003 10:07:46 -0600 From: Henry Sinnreich Subject: RE: [Sipping] New version of the SIP-AAA reqs draft In-reply-to: To: "'Allison Mankin'" , "'Jiri Kuthan'" Cc: john.loughney@nokia.com, Gonzalo.Camarillo@lmf.ericsson.se, sipping@ietf.org, aboba@internaut.com, Henning Schulzrinne , "'John R. Vollbrecht'" , "'Cees deLaat'" , Henning Schulzrinne Message-id: <000001c2d69e$b7366f50$318832a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Why not get help from the aaaarch RG on what the next generation of AAA should be? I have taken the liberty to copy here John Vollbrecht and Cees deLat to see if some consultation with the aaarch folks is doable during the March IETF. The aaaarch charter addresses exactly the dilemma we are discussing here: The NG AAA. http://www.aaaarch.org/charter.html Note: RADIUS may not be perfect but is used for 100's of millions of Internet dial-up users all over the world, so maybe it is just good enough - valid IETF principle if I remember well. This is the reason, several of us like the I-D on SIP and RADIUS by Henning Schulzrinne. It is for real and I suggest it should be advanced to an informational RFC. See also http://www.cs.columbia.edu/~hgs/sip/drafts/draft-byerly-sip-radius-00.tx t http://www.cs.columbia.edu/~hgs/sip/drafts/draft-sterman-sip-radius-00.t xt http://www.cs.columbia.edu/~hgs/research/IRT/cinema/release/radius_notes .html But let's see what we can learn from aaaarch. What do you all think? Thanks, Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of Allison Mankin > Sent: Friday, February 14, 2003 11:59 PM > To: Jiri Kuthan > Cc: john.loughney@nokia.com; Henry.Sinnreich@wcom.com; > Gonzalo.Camarillo@lmf.ericsson.se; sipping@ietf.org; > aboba@internaut.com > Subject: Re: [Sipping] New version of the SIP-AAA reqs draft > > > > Jiri, > > It always seems good to be able to stay with installed base, > but there's a factor against our supporting RADIUS drafts for > SIP's accounting - safety. Even though there is deployment, > there are some extremely bad cases of damage in production, > and the IETF > has concluded that RADIUS is not suitable for usage-based > accounting (RFC2975). > > Unless there is no intention of having in SIP accounting > usage-based, monetary, auditable applications, RADIUS is not > the solution. The protocol just does not preserve a complete > stream of reliable accounting records that are auditable on > any level, especially with any roaming. As Bernard Aboba > stated to this WG, quoting Mike O'Dell, the use of RADIUS may > even be illegal in situations where there is an authority > over the billing. Records are too easily lost by the > protocol. This is stated clearly by RFC2975. This is the > reason why the Operations and Mgt Area developed Diameter. > On these technical* grounds, that the RADIUS protocol does > not have enough reliability, the work must be based on the > Diameter protocol, which is now approved. Alternatively, > work could be done that does not include usage-based > accounting, but this does not seem to be what is > envisioned in the SIPPING AAA requirements. > > Allison > > P.S. There's a current investigation of RADIUS compatibility > mode in Diameter for this - more needs to be thought about it. > > > > At 07:46 PM 2/11/2003, john.loughney@nokia.com wrote: > > >Hi Henry, > > > > > >> >but one option is develop a solution using > > >> > Diameter in RADIUS-compatibility mode. > > >> > > >> OK, this is better than nothing. We'll take what we can :-) > > >> > > >> As mentioned, the installed base is RADIUS, no matter how > > >> voluminous the DIAMETER literature may be. > > > > > >I think the issues is that the IETF should recommend what is the > > >right thing to do & why. If people choose to do something else, > > >well, that is life. > > > > Remember that running code does not necessarily mean > something known > > to compile -- that is something known to be deployed. > > > > >I understand what you are asking but I do note that some > people have > > >thought that the potential for AAA is much greater than > the existing > > >installed base. > > > > I actually think that the deployment argument is a very > important one. > > > > -Jiri > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the 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 mailnull@www1.ietf.org Mon Feb 17 14:22:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29123 for ; Mon, 17 Feb 2003 14:22:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1HJRPx16436 for sipping-archive@odin.ietf.org; Mon, 17 Feb 2003 14:27:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HJRPp16433 for ; Mon, 17 Feb 2003 14:27:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29101 for ; Mon, 17 Feb 2003 14:21:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HJQgp16394; Mon, 17 Feb 2003 14:26:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HJPOp16347 for ; Mon, 17 Feb 2003 14:25:24 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29041 for ; Mon, 17 Feb 2003 14:19:38 -0500 (EST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h1HJNQap000632; Mon, 17 Feb 2003 11:23:26 -0800 (PST) Received: from [10.32.254.183] (stealth-10-32-254-183.cisco.com [10.32.254.183]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id ABN18196; Mon, 17 Feb 2003 11:23:25 -0800 (PST) Date: Mon, 17 Feb 2003 14:23:15 -0500 From: "David R. Oran" To: William Marshall , sipping@ietf.org Subject: Re: [Sipping] Expert review for draft-burger-sipping-netann-04.txt Message-ID: <281198141.1045491795@[10.32.254.183]> In-Reply-To: <200302141541.KAA68016@fish.research.att.com> References: <200302141541.KAA68016@fish.research.att.com> X-Mailer: Mulberry/3.0.0 (Win32) 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --On Friday, February 14, 2003 10:41 AM -0500 William Marshall wrote: > There is one issue in dealing with announcements and announcement > servers that doesn't arise with normal sessions - the timing of the > session termination. > > In a normal media session, the media is being generated in real time > and transmitted via RTP to the UAC. When the source of the media > stops, the session is terminated with a BYE, and the UAC closes > both the signaling and media paths. While there is potential for > a race, it is not significant. > > However, when the media is an announcement, contained likely within > a single (possibly large) file, it is conceivable that the server > will send the (large) RTP packets to the UAC, and then send a BYE > while the UAC has most of the announcement still unplayed. > > The basic architectural question is whether it is the responsibility > of the UAC to drain any pending media before closing a session. I > do not know of any such requirement in RFC3261. Is it considered > a common implementation practice to do so? > In the real world, don't announcment servers just replay the message over and over until the user hangs up? Or, if they don't hang up for a longish time, they just time out and send a BYE to conserve resources or avoid the "John Clayton memorial PBX bug". > Alternatively, it could be the responsibility of the announcement > server to delay sending the BYE (or 4xx response) based on the > expected playout time, though it is not clear how that would be > calculated. > Well, you could be conservative. > One choice or the other needs to be stated, and required, in order > to achieve interoperability. > > I also have concerns about the use of 487 to terminate early media > sessions. This has been raised by others. > > Bill Marshall > wtm@research.att.com > > -----original message----- > Date: Mon, 10 Feb 2003 12:39:56 +0200 > From: Gonzalo Camarillo > To: sipping > Subject: [Sipping] Expert review for draft-burger-sipping-netann-04.txt > > Folks, > > We would like the SIPPING working group to provide expert review of: > > http://www.ietf.org/internet-drafts/draft-burger-sipping-netann-04.txt > > The authors have requested individual publication of this document. > Expert Review will close on March 10th, 2003 > > Thanks, > > Gonzalo > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@cisco.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 mailnull@www1.ietf.org Tue Feb 18 15:07:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06990 for ; Tue, 18 Feb 2003 15:07:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1IKDSE22951 for sipping-archive@odin.ietf.org; Tue, 18 Feb 2003 15:13:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1IKDSp22948 for ; Tue, 18 Feb 2003 15:13:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06955 for ; Tue, 18 Feb 2003 15:07:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1IKCap22899; Tue, 18 Feb 2003 15:12:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1IKB1p22830 for ; Tue, 18 Feb 2003 15:11:01 -0500 Received: from fox.iptel.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06914 for ; Tue, 18 Feb 2003 15:04:45 -0500 (EST) Received: from jku07.fokus.fraunhofer.de (port-212-202-220-34.reverse.qdsl-home.de [212.202.220.34]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id h1IK8MJ31381; Tue, 18 Feb 2003 21:08:22 +0100 Message-Id: <5.2.0.9.0.20030218204807.02924108@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 18 Feb 2003 20:50:04 +0100 To: Allison Mankin From: Jiri Kuthan Subject: Re: [Sipping] New version of the SIP-AAA reqs draft Cc: john.loughney@nokia.com, Henry.Sinnreich@wcom.com, Gonzalo.Camarillo@lmf.ericsson.se, sipping@ietf.org, aboba@internaut.com In-Reply-To: References: <5.2.0.9.0.20030213195458.04501ea0@mailhost.fokus.gmd.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Allison, I am no way opposed to the critique of RADIUS -- but where is the DIAMETER running code? -jiri At 06:58 AM 2/15/2003, Allison Mankin wrote: >Jiri, > >It always seems good to be able to stay with installed base, but >there's a factor against our supporting RADIUS drafts for SIP's >accounting - safety. Even though there is deployment, there are >some extremely bad cases of damage in production, and the IETF >has concluded that RADIUS is not suitable for usage-based accounting >(RFC2975). > >Unless there is no intention of having in SIP accounting usage-based, >monetary, auditable applications, RADIUS is not the solution. The >protocol just does not preserve a complete stream of reliable >accounting records that are auditable on any level, especially with >any roaming. As Bernard Aboba stated to this WG, quoting Mike O'Dell, >the use of RADIUS may even be illegal in situations where there is an >authority over the billing. Records are too easily lost by the >protocol. This is stated clearly by RFC2975. This is the reason why >the Operations and Mgt Area developed Diameter. On these technical* >grounds, that the RADIUS protocol does not have enough reliability, >the work must be based on the Diameter protocol, which is now >approved. Alternatively, work could be done that does not include >usage-based accounting, but this does not seem to be what is >envisioned in the SIPPING AAA requirements. > >Allison > >P.S. There's a current investigation of RADIUS compatibility mode >in Diameter for this - more needs to be thought about it. >> >> At 07:46 PM 2/11/2003, john.loughney@nokia.com wrote: >> >Hi Henry, >> > >> >> >but one option is develop a solution using >> >> > Diameter in RADIUS-compatibility mode. >> >> >> >> OK, this is better than nothing. We'll take what we can :-) >> >> >> >> As mentioned, the installed base is RADIUS, no matter how >> >> voluminous the DIAMETER literature may be. >> > >> >I think the issues is that the IETF should recommend what is the >> >right thing to do & why. If people choose to do something else, >> >well, that is life. >> >> Remember that running code does not necessarily mean something known >> to compile -- that is something known to be deployed. >> >> >I understand what you are asking but I do note that some >> >people have thought that the potential for AAA is much greater >> >than the existing installed base. >> >> I actually think that the deployment argument is a very important one. >> >> -Jiri >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the 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 mailnull@www1.ietf.org Wed Feb 19 00:35:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19147 for ; Wed, 19 Feb 2003 00:35:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1J5ewS28739 for sipping-archive@odin.ietf.org; Wed, 19 Feb 2003 00:40:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J5ewp28736 for ; Wed, 19 Feb 2003 00:40:58 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19123 for ; Wed, 19 Feb 2003 00:34:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J5e1p28689; Wed, 19 Feb 2003 00:40:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J5cCp28628 for ; Wed, 19 Feb 2003 00:38:12 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19091 for ; Wed, 19 Feb 2003 00:31:41 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.36 #1 (Debian)) id 18lMtD-00021M-00; Wed, 19 Feb 2003 07:35:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15955.6047.468360.246276@harjus.eng.song.fi> Date: Wed, 19 Feb 2003 07:35:27 +0200 To: Henry Sinnreich Cc: "'Gonzalo Camarillo'" , "'sipping'" , "'John Loughney'" Subject: RE: [Sipping] New version of the SIP-AAA reqs draft In-Reply-To: <001201c2d174$03ac7300$358032a6@hsinnreich2> References: <3E47912B.CE58BFB5@lmf.ericsson.se> <001201c2d174$03ac7300$358032a6@hsinnreich2> X-Mailer: VM 7.07 under Emacs 21.2.1 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henry Sinnreich writes: > I suggest therefore to start with RADIUS instead. i fully agree, juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Feb 19 00:46:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19310 for ; Wed, 19 Feb 2003 00:46:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1J5qLL29187 for sipping-archive@odin.ietf.org; Wed, 19 Feb 2003 00:52:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J5qLp29184 for ; Wed, 19 Feb 2003 00:52:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19303 for ; Wed, 19 Feb 2003 00:45:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J5pGp29136; Wed, 19 Feb 2003 00:51:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J5oQp29090 for ; Wed, 19 Feb 2003 00:50:26 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19293 for ; Wed, 19 Feb 2003 00:43:59 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.36 #1 (Debian)) id 18lN59-0002Jw-00; Wed, 19 Feb 2003 07:47:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15955.6787.386942.122296@harjus.eng.song.fi> Date: Wed, 19 Feb 2003 07:47:47 +0200 To: john.loughney@nokia.com Cc: , , Subject: RE: [Sipping] New version of the SIP-AAA reqs draft In-Reply-To: References: X-Mailer: VM 7.07 under Emacs 21.2.1 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit john.loughney@nokia.com writes: > RADIUS is extremely limited in a number of cases - security, transport > issues, reliability and is most likely illegal in many jurisdictions > for use with token-based accounting (due to the non-reliable nature > of RADIUS). how does that differ from sip itself? one can always run radius over ipsec. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Feb 19 01:06:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19770 for ; Wed, 19 Feb 2003 01:06:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1J6CJQ30986 for sipping-archive@odin.ietf.org; Wed, 19 Feb 2003 01:12:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J6CJp30983 for ; Wed, 19 Feb 2003 01:12:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19764 for ; Wed, 19 Feb 2003 01:05:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J6BCp30843; Wed, 19 Feb 2003 01:11:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J6AYp30804 for ; Wed, 19 Feb 2003 01:10:34 -0500 Received: from dgesmtp01.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19706 for ; Wed, 19 Feb 2003 01:04:07 -0500 (EST) Received: from dgismtp05.wcomnet.com ([166.38.58.88]) by firewall.wcom.com (Iplanet MTA) with ESMTP id <0HAJ00LAWKU1EM@firewall.wcom.com> for sipping@ietf.org; Wed, 19 Feb 2003 06:03:37 +0000 (GMT) Received: from dgismtp05.wcomnet.com by dgismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HAJ00M01KU13U@dgismtp05.wcomnet.com>; Wed, 19 Feb 2003 06:03:37 +0000 (GMT) Received: from hsinnreich2 ([166.50.96.65]) by dgismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HAJ00L25KU0NG@dgismtp05.wcomnet.com>; Wed, 19 Feb 2003 06:03:37 +0000 (GMT) Date: Wed, 19 Feb 2003 00:03:36 -0600 From: Henry Sinnreich Subject: RE: [Sipping] New version of the SIP-AAA reqs draft In-reply-to: <15955.6047.468360.246276@harjus.eng.song.fi> To: jh@lohi.eng.song.fi Cc: "'Gonzalo Camarillo'" , "'sipping'" , "'John Loughney'" Message-id: <000201c2d7dc$a4b138d0$416032a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I still would like to hear if people think a discussion with the AAA architecture RG is a good way to get out of this impasse. Please browse the work at http://www.aaaarch.org/charter.html It appears there is enough push-back on DIAMETER in this WG that this should be given some time for discussion at the next meeting. All messages from the 'audience' favored RADIUS, contrary to the proposed work agenda. I have yet to hear an argument why some form of XML documents over some secure transport, as in Web Services should not be the choice after RADIUS. Or are the authors so committed to a DIAMETER project that this discussion is futile? Thanks, Henry > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: Tuesday, February 18, 2003 11:35 PM > To: Henry Sinnreich > Cc: 'Gonzalo Camarillo'; 'sipping'; 'John Loughney' > Subject: RE: [Sipping] New version of the SIP-AAA reqs draft > > > Henry Sinnreich writes: > > > I suggest therefore to start with RADIUS instead. > > i fully agree, juha > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Feb 19 03:40:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16071 for ; Wed, 19 Feb 2003 03:40:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1J8kNs19199 for sipping-archive@odin.ietf.org; Wed, 19 Feb 2003 03:46:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J8kMp19196 for ; Wed, 19 Feb 2003 03:46:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16066 for ; Wed, 19 Feb 2003 03:39:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J8jMp19116; Wed, 19 Feb 2003 03:45:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J8eDp18829 for ; Wed, 19 Feb 2003 03:40:13 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16014 for ; Wed, 19 Feb 2003 03:33:42 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.36 #1 (Debian)) id 18lPjM-0003Ld-00; Wed, 19 Feb 2003 10:37:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15955.16968.381365.754142@harjus.eng.song.fi> Date: Wed, 19 Feb 2003 10:37:28 +0200 To: jari.arkko@piuha.net Cc: Henry Sinnreich , "'Gonzalo Camarillo'" , "'sipping'" , "'John Loughney'" Subject: Re: [Sipping] New version of the SIP-AAA reqs draft In-Reply-To: <3E5339E4.7030204@piuha.net> References: <000201c2d7dc$a4b138d0$416032a6@hsinnreich2> <3E5339E4.7030204@piuha.net> X-Mailer: VM 7.07 under Emacs 21.2.1 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit is there any open source diameter server implementations similar to freeradius? is there a good number of commercial diameter server implementations for me to choose from? is there any open source diameter client libraries similar to radiusclient? is there any commercial diameter client libraries for me to choose from? i don't mind using diameter for sip once answers to most of the above questions is "yes". as long it isn't, it makes no sense to base sip aaa work on diameter. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Feb 19 04:32:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16961 for ; Wed, 19 Feb 2003 04:32:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1J9cse23742 for sipping-archive@odin.ietf.org; Wed, 19 Feb 2003 04:38:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J9csp23739 for ; Wed, 19 Feb 2003 04:38:54 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16944 for ; Wed, 19 Feb 2003 04:32:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J9cHp23715; Wed, 19 Feb 2003 04:38:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J9bMp23417 for ; Wed, 19 Feb 2003 04:37:22 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16923 for ; Wed, 19 Feb 2003 04:30:49 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1J9XR213529 for ; Wed, 19 Feb 2003 11:33:27 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 19 Feb 2003 11:34:38 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Feb 2003 11:34:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] New version of the SIP-AAA reqs draft Date: Wed, 19 Feb 2003 11:34:38 +0200 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945169@esebe013.ntc.nokia.com> Thread-Topic: [Sipping] New version of the SIP-AAA reqs draft Thread-Index: AcLX89mHRc7w0GgSSluxaaobodi/hgABN9sg To: Cc: , , , , X-OriginalArrivalTime: 19 Feb 2003 09:34:38.0852 (UTC) FILETIME=[1F684C40:01C2D7FA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1J9bMp23418 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Juha, Isn't this a chicken-and-egg problem? Diameter just got to proposed standard - back in 1999 if you had asked the same set of questions about RFC 2543, I bet we'd all be talking about H.323 or something... ;) Cheers, Aki > -----Original Message----- > From: ext jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: 19 February, 2003 10:37 > To: jari.arkko@piuha.net > Cc: Henry Sinnreich; 'Gonzalo Camarillo'; 'sipping'; Loughney John > (NRC/Helsinki) > Subject: Re: [Sipping] New version of the SIP-AAA reqs draft > > > is there any open source diameter server implementations similar to > freeradius? > > is there a good number of commercial diameter server > implementations for > me to choose from? > > is there any open source diameter client libraries similar to > radiusclient? > > is there any commercial diameter client libraries for me to > choose from? > > i don't mind using diameter for sip once answers to most of the above > questions is "yes". as long it isn't, it makes no sense to > base sip aaa > work on diameter. > > -- juha > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Feb 19 05:08:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17753 for ; Wed, 19 Feb 2003 05:08:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JAErV26563 for sipping-archive@odin.ietf.org; Wed, 19 Feb 2003 05:14:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JAErp26560 for ; Wed, 19 Feb 2003 05:14:53 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17726 for ; Wed, 19 Feb 2003 05:08:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JAEGp26532; Wed, 19 Feb 2003 05:14:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JADsp26483 for ; Wed, 19 Feb 2003 05:13:54 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17663 for ; Wed, 19 Feb 2003 05:07:19 -0500 (EST) From: marco.stura@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1JAE7m14345 for ; Wed, 19 Feb 2003 12:14:07 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 19 Feb 2003 12:11:08 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Feb 2003 12:11:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C2D7FF.3781965C" Subject: RE: [Sipping] New version of the SIP-AAA reqs draft Date: Wed, 19 Feb 2003 12:11:06 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C7923@esebe016.ntc.nokia.com> X-MS-Has-Attach: yes Thread-Topic: [Sipping] New version of the SIP-AAA reqs draft Thread-Index: AcLX89mHRc7w0GgSSluxaaobodi/hgABN9sgAAF1WeA= To: , Cc: , , , , X-OriginalArrivalTime: 19 Feb 2003 10:11:07.0423 (UTC) FILETIME=[37E5BAF0:01C2D7FF] Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C2D7FF.3781965C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I agree with Aki. Perhaps some answer to Juha question could be found from the Open source Diameter project (see attached mail). http://opendiameter.org. Br Marco=20 > -----Original Message----- > From: ext aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > Sent: 19 February, 2003 11:35 > To: jh@lohi.eng.song.fi > Cc: Henry.Sinnreich@wcom.com; Gonzalo.Camarillo@lmf.ericsson.se; > sipping@ietf.org; Loughney John (NRC/Helsinki); jari.arkko@piuha.net > Subject: RE: [Sipping] New version of the SIP-AAA reqs draft >=20 >=20 > Hi Juha, >=20 > Isn't this a chicken-and-egg problem? Diameter just got to=20 > proposed standard - back in 1999 if you had asked the same=20 > set of questions about RFC 2543, I bet we'd all be talking=20 > about H.323 or something... ;) >=20 > Cheers, > Aki >=20 > > -----Original Message----- > > From: ext jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > > Sent: 19 February, 2003 10:37 > > To: jari.arkko@piuha.net > > Cc: Henry Sinnreich; 'Gonzalo Camarillo'; 'sipping'; Loughney John > > (NRC/Helsinki) > > Subject: Re: [Sipping] New version of the SIP-AAA reqs draft > >=20 > >=20 > > is there any open source diameter server implementations similar to > > freeradius? =20 > >=20 > > is there a good number of commercial diameter server=20 > > implementations for > > me to choose from? > >=20 > > is there any open source diameter client libraries similar to > > radiusclient? > >=20 > > is there any commercial diameter client libraries for me to=20 > > choose from? > >=20 > > i don't mind using diameter for sip once answers to most=20 > of the above > > questions is "yes". as long it isn't, it makes no sense to=20 > > base sip aaa > > work on diameter. > >=20 > > -- juha > >=20 > > _______________________________________________ > > Sipping mailing list =20 > https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 ------_=_NextPart_001_01C2D7FF.3781965C Content-Type: message/rfc822 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Received: from esebe021.NOE.Nokia.com ([172.21.138.104]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 9 Oct 2002 17:23:52 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebe021.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 9 Oct 2002 17:23:51 +0300 Received: from esvir05nok.ntc.nokia.com ([172.21.143.37]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 9 Oct 2002 17:23:50 +0300 Received: from mgw-x3.nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 9 Oct 2002 17:21:57 +0300 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g99EMF212268; Wed, 9 Oct 2002 17:22:15 +0300 (EET DST) Received: by trapdoor.merit.edu (Postfix) id C6E1F91218; Wed, 9 Oct 2002 10:21:33 -0400 (EDT) content-class: urn:content-classes:message Subject: [AAA-WG]: OpenDiameter announcement Date: Wed, 9 Oct 2002 16:21:10 +0200 Message-ID: <20021009142110.GA1596@catfish> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AAA-WG]: OpenDiameter announcement Thread-Index: AcJvn33wZlW5EpTMRuCmHvW6qve/9Q== From: To: Content-Transfer-Encoding: 7bit Hi, Let me allow to post this announce on the AAA mailing list. A new project for develpping open source Diameter software has been created. A Diameter message parser library is available in the first release. We will actively work on releasing new stuff and updating them. If you are interested in this project, visit http://opendiameter.org. For further questions, please send email to diameter-devel@opendiameter.org, not to this list. Thanks, Yoshihiro Ohba ------_=_NextPart_001_01C2D7FF.3781965C-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Feb 19 05:16:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17878 for ; Wed, 19 Feb 2003 05:16:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JAMk727041 for sipping-archive@odin.ietf.org; Wed, 19 Feb 2003 05:22:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JAMkp27038 for ; Wed, 19 Feb 2003 05:22:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17869 for ; Wed, 19 Feb 2003 05:16:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JAM7p26986; Wed, 19 Feb 2003 05:22:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JALLp26947 for ; Wed, 19 Feb 2003 05:21:21 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17863 for ; Wed, 19 Feb 2003 05:14:48 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.36 #1 (Debian)) id 18lRJD-0003RH-00; Wed, 19 Feb 2003 12:18:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15955.23035.307593.879822@harjus.eng.song.fi> Date: Wed, 19 Feb 2003 12:18:35 +0200 To: Cc: , , , , Subject: RE: [Sipping] New version of the SIP-AAA reqs draft In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945169@esebe013.ntc.nokia.com> References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945169@esebe013.ntc.nokia.com> X-Mailer: VM 7.07 under Emacs 21.2.1 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit aki.niemi@nokia.com writes: > Isn't this a chicken-and-egg problem? Diameter just got to proposed > standard - back in 1999 if you had asked the same set of questions > about RFC 2543, I bet we'd all be talking about H.323 or > something... ;) sure it is ok to develop new protocols. however, nobody takes a protocol seriously that doesn't have a good number of interoperable implementations. thus i consider it a mistake to make the sip community a guinea pig for the diameter protocol and would stick to radius until diameter has proven itself in products and real world deployments. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Feb 19 06:33:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19168 for ; Wed, 19 Feb 2003 06:33:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JBdut00505 for sipping-archive@odin.ietf.org; Wed, 19 Feb 2003 06:39:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JBdup00502 for ; Wed, 19 Feb 2003 06:39:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19165 for ; Wed, 19 Feb 2003 06:33:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JBcnp00436; Wed, 19 Feb 2003 06:38:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JBb6p32254 for ; Wed, 19 Feb 2003 06:37:06 -0500 Received: from p2.piuha.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19137 for ; Wed, 19 Feb 2003 06:30:32 -0500 (EST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 57D246A906; Wed, 19 Feb 2003 13:34:19 +0200 (EET) Message-ID: <3E536B9C.2020503@piuha.net> Date: Wed, 19 Feb 2003 13:33:48 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henry Sinnreich Cc: jh@lohi.eng.song.fi, "'Gonzalo Camarillo'" , "'sipping'" , "'John Loughney'" Subject: Re: [Sipping] New version of the SIP-AAA reqs draft References: <000201c2d7dc$a4b138d0$416032a6@hsinnreich2> 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I don't think the AAA architecture RG is an engineering alternative the SIP WG can consider, assuming we want to get this thing deployed and running in a relatively short time period with many vendors supporting it. My preference is DIAMETER. I do agree that we probably need to look at RADIUS compatibility as well. Perhaps this is the compromise we need for us to continue? (I don't see a major technical obstacle to the compatibility; the DIAMETER NASREQ application has been defined to work with existing RADIUS NASes. If SIP AAA is defined with this in mind, we can get at least some amount of functionality over RADIUS. The main problem is perhaps finding standardized RADIUS attribute numbers, of which we have almost run out... Also naturally, some new functions of DIAMETER can not be realized through translation to RADIUS, such as the what requirement 2.3.4 in the SIP AAA requirements draft indicates. And I would reserve RADIUS mode mainly for compatibility with old products, not as the mandatory-to-implement feature in some future RFC. It is seen as the weakest component in the security of planned network access systems, for instance.) Perhaps I'm biased for being involved in the DIAMETER work myself. However, I am also involved with some planned very large scale applications of SIP, and those folks intend to use DIAMETER -- they are also building products in this space. Finally, a few comments to the SIP-AAA requirements: - The security requirements might be expanded a bit. Are proxies going to be needed? Is end-to-end security through proxies necessary for some reason? - The document does not mention anything about reliability of AAA transactions, accounting in particular. I would think this is of high interest, as Allison also noted. - Do we really need both cumulative and non-cumulative accounting? - 2.4.2 and 2.4.3 are unclear to me. What is really required here? - Section 3.2 example is a bit thin. I suspect there's more to it than this. - John's address has a non-ASCII character. Jari Henry Sinnreich wrote: > I still would like to hear if people think a discussion with the AAA > architecture RG is a good way to get out of this impasse. Please browse > the work at http://www.aaaarch.org/charter.html > > It appears there is enough push-back on DIAMETER in this WG that this > should be given some time for discussion at the next meeting. All > messages from the 'audience' favored RADIUS, contrary to the proposed > work agenda. > > I have yet to hear an argument why some form of XML documents over some > secure transport, as in Web Services should not be the choice after > RADIUS. > > Or are the authors so committed to a DIAMETER project that this > discussion is futile? > > Thanks, Henry > > > > >>-----Original Message----- >>From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] >>Sent: Tuesday, February 18, 2003 11:35 PM >>To: Henry Sinnreich >>Cc: 'Gonzalo Camarillo'; 'sipping'; 'John Loughney' >>Subject: RE: [Sipping] New version of the SIP-AAA reqs draft >> >> >>Henry Sinnreich writes: >> >> > I suggest therefore to start with RADIUS instead. >> >>i fully agree, juha >> > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Feb 19 20:47:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15276 for ; Wed, 19 Feb 2003 20:47:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1K1ruc26137 for sipping-archive@odin.ietf.org; Wed, 19 Feb 2003 20:53:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K1rup26134 for ; Wed, 19 Feb 2003 20:53:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15273 for ; Wed, 19 Feb 2003 20:47:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K1qmp26102; Wed, 19 Feb 2003 20:52:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K1pgp26045 for ; Wed, 19 Feb 2003 20:51:42 -0500 Received: from pmesmtp01.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15242 for ; Wed, 19 Feb 2003 20:44:51 -0500 (EST) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HAL00HDP3JF2C@firewall.wcom.com> for sipping@ietf.org; Thu, 20 Feb 2003 01:45:15 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HAL001013JFI7@pmismtp01.wcomnet.com>; Thu, 20 Feb 2003 01:45:15 +0000 (GMT) Received: from ajohnston.wcom.com ([166.42.33.209]) by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HAL0001I3JDTK@pmismtp01.wcomnet.com>; Thu, 20 Feb 2003 01:45:14 +0000 (GMT) Date: Wed, 19 Feb 2003 19:44:54 -0600 From: Alan Johnston Subject: Re: [Sipping] I-D ACTION:draft-rosenberg-sipping-lease-00.txt In-reply-to: <269039778.1045479637@[10.32.254.183]> X-Sender: Alan.Johnston@pop.mcit.com To: "David R. Oran" , sipping@ietf.org Cc: Jonathan Rosenberg Message-id: <5.1.1.6.0.20030219193436.00bae500@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; charset=us-ascii; format=flowed References: <200302131615.LAA16593@ietf.org> <200302131615.LAA16593@ietf.org> Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , At 11:00 AM 2/17/2003 -0500, David R. Oran wrote: >> Title : URI Leasing in the Session Initiation Protocol >> (SIP) >> Author(s) : J. Rosenberg >> Filename : draft-rosenberg-sipping-lease-00.txt >> Pages : 23 >> Date : 2003-2-12 >> >In general I like the direction this is going. I have a query. Did you >consider making the creation and communication of the GRUU simply a >side-effect of a REGISTER operation as opposed to a separate method? In >other words, the REGISTER would optionally request the construction of a >(range of/template for) GRUUs for the UA, and the response would contain >the constructed values. This would seem to meet all of the requirements, >including, at least provisionally, the requirement for not substantially >increasing the domain-level state stored by proxies. I like this approach. It also solves the problem of how a UA finds out if it needs to lease a URI or not and whether the registrar supports it. Otherwise, it must either send an OPTIONS to the registrar or find out with a 501 that the registrar does not support a LEASE method. I also don't think a UA can tell if it's Contact is routeable, but the registrar can (or should). As a result UA might lease a URI that it in fact doesn't need if its Contact is already globally routeable which would needless increase stored state. If the leased URI is returned in a new header or Contact parameter, the registrar would only do so if the UA needs it - if the Contact URI in the REGISTER is already globally routeable (no screening proxies, firewalls/NATs, etc.) then the registrar would not return any value. UAs that didn't support the extension would simply ignore. A UA supporting the extension would use the returned leased URI instead of the one that it registered with. >One small point bears upon the above. In the text you say that a lease >should not extend beyond the registration expiration of a registered UA. >However, the requirement is weaker; it only says that the domain has final >say over the lease duration. Was this intentional? If so I would think >this complicates the life of a registrar somewhat, compared with managing >GRUUs just like registrations, or state directly bound to registrations. I >can see a rather straightforward implementation if leases are simply extra >stuff associated with a registration. I have a harder time seeing a simple >implementation if a new method or some completely separate mechanism is used. And the separation can cause problems - a UA that wishes to watch the state of its registration and lease would have to watch both because if either one fails, then requests will fail. Seems better to combine the two for the reasons Dave mentions. Thanks, Alan Johnston WorldCom sip:alan@digitalari.com >Dave. > > >Dave. >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the 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 mailnull@www1.ietf.org Wed Feb 19 22:39:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17732 for ; Wed, 19 Feb 2003 22:39:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1K3k4I32072 for sipping-archive@odin.ietf.org; Wed, 19 Feb 2003 22:46:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K3k4p32069 for ; Wed, 19 Feb 2003 22:46:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17729 for ; Wed, 19 Feb 2003 22:39:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K3jOp32032; Wed, 19 Feb 2003 22:45:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K3iBp31945 for ; Wed, 19 Feb 2003 22:44:11 -0500 Received: from imo-m03.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17511 for ; Wed, 19 Feb 2003 22:37:17 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-m03.mx.aol.com (mail_out_v34.21.) id l.17.362f595b (3890) for ; Wed, 19 Feb 2003 22:41:05 -0500 (EST) Message-ID: <17.362f595b.2b85a851@aol.com> Date: Wed, 19 Feb 2003 22:41:05 EST To: sipping@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_17.362f595b.2b85a851_boundary" X-Mailer: 6.0 for Windows XP sub 10501 Subject: [Sipping] Comments on Overlap-04 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --part1_17.362f595b.2b85a851_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Comments on draft-ietf-sipping-overlap-04: General: The ability of one call to result in multiple IAMs being sent into the PSTN continues to be a serious problem for overlap which must be solved. Section 3.1: All references to one number being a "prefix" of another should be deleted. This text indicates that overlap can not be used where this "prefix" situation can occur, however, one of the purposes of overlap is to handle the situation in which there are varying lengths of numbers in some destination area, something that would naturally exist if one number really could be a "prefix" of another. This creates a major contradiction. However, there is still no identified case in the world-wide numbering plan in which one number is a "prefix" of another. If there were, overlap signaling to get to it would certainly be allowed just as it would be in the existing PSTN. If one believes that this "prefix" situation really exists, then the overlap procedures defined in this draft must correctly support it. Section 3.3 contains the statement: As a general rule, a media stream corresponding to the response to an INVITE with a greater number of digits should be given more priority than media streams from responses with less digits. This continues to be a problem, since it is not always the case. If the originator dialed more digits than were needed when overlap was being used, the media stream corresponding to the response with the fewer digits would be the one to use. The PSTN had no problem with this. SIP is going to have to figure out a way to correctly handle it. Section 3.5 contains the statement: If the gateway is attached to the PSTN in an area where en-bloc signalling is used, a REL for the previous IAM and a new IAM should be generated. This causes confusion since all areas would allow en-bloc, although some do not allow overlap, for example, an area where US SS#7 according to T1.113 is used. In those areas, since overlap is not allowed, the gateway or switch which provides interworking into that non-overlap area must perform the overlap to en-bloc procedures (by time outs, detecting enough digits, etc.) There can not be a "previous IAM" sent to the PSTN, since the gateway or switch would not have sent one until it knew it had enough digits to send a complete IAM, after which it would stop accepting or sending any further digits. This paragraph should be worded as: If the gateway is attached to the PSTN in an area where overlap signalling is not allowed, it must not send an IAM until it determines that it has received the full number in one or more INVITEs, using a process similar to that described in Section 2. It must not send SAMs or additional IAMs after that one IAM. Mike Pierce --part1_17.362f595b.2b85a851_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Comments on draft-ietf-si= pping-overlap-04:

General:

The ability of one call to result in multiple IAMs being sent into the P= STN continues to be a serious problem for overlap which must be solved.

Section 3.1:

All references to one number being a "prefix" of another should be delet= ed. This text indicates that overlap can not be used where this "prefix" sit= uation can occur, however, one of the purposes of overlap is to handle the s= ituation in which there are varying lengths of numbers in some destination a= rea, something that would naturally exist if one number really could be a "p= refix" of another. This creates a major contradiction. However, there is sti= ll no identified case in the world-wide numbering plan in which one number i= s a "prefix" of another. If there were, overlap signaling to get to it would= certainly be allowed just as it would be in the existing PSTN. If one belie= ves that this "prefix" situation really exists, then the overlap procedures=20= defined in this draft must correctly support it.

Section 3.3 contains the statement:

  As a general rule, a media stream corresponding to the resp= onse to an
  INVITE with a greater number of digits should be given more= priority
  than media streams from responses with less digits.

This continues to be a problem, since it is not always the case. If the=20= originator dialed more digits than were needed when overlap was being used,=20= the media stream corresponding to the response with the fewer digits would b= e the one to use. The PSTN had no problem with this. SIP is going to have to= figure out a way to correctly handle it.

Section 3.5 contains the statement:

  If the gateway is attached to the PSTN in an area where en-= bloc
  signalling is used, a REL for the previous IAM and a new IA= M should
  be generated.

This causes confusion since all areas would allow en-bloc, although some= do not allow overlap, for example, an area where US SS#7 according to T1.11= 3 is used. In those areas, since overlap is not allowed, the gateway or swit= ch which provides interworking into that non-overlap area must perform the o= verlap to en-bloc procedures (by time outs, detecting enough digits, etc.) T= here can not be a "previous IAM" sent to the PSTN, since the gateway or swit= ch would not have sent one until it knew it had enough digits to send a comp= lete IAM, after which it would stop accepting or sending any further digits.

This paragraph should be worded as:

  If the gateway is attached to the PSTN in an area where ove= rlap signalling
  is not allowed, it must not send an IAM until it determines= that it has=20
  received the full number in one or more INVITEs, using a pr= ocess similar to  
  that described in Section 2. It must not send SAMs or addit= ional IAMs after
  that one IAM.

Mike Pierce
--part1_17.362f595b.2b85a851_boundary-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 20 04:02:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04630 for ; Thu, 20 Feb 2003 04:02:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1K99Qw28941 for sipping-archive@odin.ietf.org; Thu, 20 Feb 2003 04:09:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K99Qp28938 for ; Thu, 20 Feb 2003 04:09:26 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04622 for ; Thu, 20 Feb 2003 04:02:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K98kp28911; Thu, 20 Feb 2003 04:08:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DG0Wp29819 for ; Thu, 13 Feb 2003 11:00:32 -0500 Received: from mta07-svc.ntlworld.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16111 for ; Thu, 13 Feb 2003 10:50:03 -0500 (EST) Received: from profile-ict.com ([213.106.0.60]) by mta07-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20030213155346.FIIF3191.mta07-svc.ntlworld.com@profile-ict.com>; Thu, 13 Feb 2003 15:53:46 +0000 Message-ID: <3E4BBF23.40707@profile-ict.com> Date: Thu, 13 Feb 2003 15:52:03 +0000 From: Adrian Lewis User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henry Sinnreich CC: "'Brierre, Jean Joseph'" , sipforum-discussion@lists.su.se, sipping@ietf.org References: <000001c2d374$7367e150$02212aa6@hsinnreich2> Content-Type: multipart/alternative; boundary="------------010700070200030407060707" Subject: [Sipping] Re: [Sipforum-discussion] SIP Telephony Device Requirements, Conf iguration and Data Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --------------010700070200030407060707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit I agree! SNMP v3 support for network LAN statistics etc. might just about make sense for SIP telphony adaptors, but it is unlikely that you would convince SIP telephone manufacturers of the need for such support in their products. Adian Lewis Henry Sinnreich wrote: >Comments 1, 2, and 3 seem obvious - will edit in the next version. >Thanks for pointing out. > >As for comment 4: "why can we not have SNMP v3 support for network LAN >statistics, SIP traffic stats or even RTCP info on the SIP phone", > > it would be interesting to see if SIP phone manufacturers think this is >OK for any type of SIP device, or only for certain devices, such as SIP >telephony adaptors that support key sets. I believe it makes sense only >for latter. Opinions? > >Thanks, Henry > > > >>-----Original Message----- >>From: Brierre, Jean Joseph [mailto:Jean.Joseph.Brierre@wcom.com] >>Sent: Thursday, February 13, 2003 5:43 AM >>To: Sinnreich, Henry; 'sipforum-discussion@lists.su.se'; >>'sipping@ietf.org' >>Subject: RE: [Sipforum-discussion] SIP Telephony Device >>Requirements, Conf iguration and Data >> >> >>Henry, >> >>below are my comments to the Somefolks draft. >> >> >> >>Integrated Switch/Hub SIP devices designed for wired Ethernet >>SHOULD have an uplink port such that another IP device, such >>as a personal computer, MAY share the network connection. SIP >>clients MUST prioritize the transmission of RTP traffic over >>the shared network connection. >> >>comment 1: >>Wish you would remove the Hub reference since this is a >>shared collision domain concept which I do not recommend for >>sip client that has real time requirements sharing this >>shared Ethernet environment with a host device that may also >>have real time data on the same hub. Switch is the only way >>to go since ethernet HUB collisions between 2 devices can >>effect throughput >> >>"IP Requirements IP-1: SIP telephony devices MUST be able to >>acquire an IP address by: Automatic IP address configuration >>using DHCP, or Manual IP address entry from the device. " >> >>Comment 2 >>Why did you not reference RFC3361 DHCP option for sip >>ftp://ftp.rfc-editor.org/in-notes/rfc3361.txt this a great >>MAY RFC to support for sip clients to learn SIP proxy servers >> >>Comment 3 >>No mention was made of support for Visual and Hearing >>Impaired Special Equipment or even RFC3351 >> >> >ftp://ftp.rfc-editor.org/in-notes/rfc3351.txt > >Comment 4 >You mention management but only for provisioning, why can we not have >SNMP v3 support for network LAN statistics, SIP traffic stats or even >RTCP info on the SIP phone. > > > > > > > > >>-----Original Message----- >>From: sipforum-discussion-admin@lists.su.se >>[mailto:sipforum-discussion-admin@lists.su.se] On Behalf Of >>Henry Sinnreich >>Sent: Monday, February 10, 2003 8:49 AM >>To: 'Jörgen Björkner'; sipforum-discussion@lists.su.se >>Subject: [Sipforum-discussion] SIP Telephony Device >>Requirements, Configuration and Data >> >> >>For everyone interested SIP phones and other SIP >>communication devices, and the 56 IETF coming next month, >>please see if you like or dislike or don't care about the draft: >> >> >> >http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-00.txt > >The idea is to have discussions on the lists, and if there is interest >and rough consensus to move ahead with an informational RFC. Would >appreciate your comments to > >sipping@ietf.org , and also to > >sipforum-discussion@lists.su.se > >Thanks, Henry > >Henry Sinnreich >WorldCom >400 International Parkway >Richardson, Texas 75081 >USA > > > > --------------010700070200030407060707 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I agree!  SNMP v3 support for network LAN statistics etc. might just about make sense for SIP telphony adaptors, but it is unlikely that you would convince SIP telephone manufacturers of the need for such support in their products.

Adian Lewis

Henry Sinnreich wrote:
Comments 1, 2, and 3 seem obvious - will edit in the next version.
Thanks for pointing out.

As for comment 4: "why can we not have SNMP v3 support for network LAN
statistics, SIP traffic stats or even RTCP info on the SIP phone", 

 it would be interesting to see if SIP phone manufacturers think this is
OK for any type of SIP device, or only for certain devices, such as SIP
telephony adaptors that support key sets. I believe it makes sense only
for latter. Opinions?

Thanks, Henry

  
-----Original Message-----
From: Brierre, Jean Joseph [mailto:Jean.Joseph.Brierre@wcom.com] 
Sent: Thursday, February 13, 2003 5:43 AM
To: Sinnreich, Henry; 'sipforum-discussion@lists.su.se'; 
'sipping@ietf.org'
Subject: RE: [Sipforum-discussion] SIP Telephony Device 
Requirements, Conf iguration and Data


Henry, 

below are my comments to the Somefolks draft. 



Integrated Switch/Hub SIP devices designed for wired Ethernet 
SHOULD have an uplink port such that another IP device, such 
as a personal computer, MAY share the network connection. SIP 
clients MUST prioritize the transmission of RTP traffic over 
the shared network connection. 

comment 1: 
Wish you would remove the Hub reference since this is a 
shared collision domain concept which I do not recommend for 
sip client that has real time requirements sharing this 
shared Ethernet environment with a host device that may also 
have real time data on the same hub. Switch is the only way 
to go since ethernet HUB collisions between 2 devices can 
effect throughput

"IP Requirements IP-1: SIP telephony devices MUST be able to 
acquire an IP address by: Automatic IP address configuration 
using DHCP, or Manual IP address entry from the device. "

Comment 2 
Why did you not reference RFC3361 DHCP option for sip 
ftp://ftp.rfc-editor.org/in-notes/rfc3361.txt this a great 
MAY RFC to support for sip clients to learn SIP proxy servers

Comment 3 
No mention was made of support for Visual and Hearing 
Impaired Special Equipment or even RFC3351 
    
ftp://ftp.rfc-editor.org/in-notes/rfc3351.txt

Comment 4 
You mention management but only for provisioning, why can we not have
SNMP v3 support for network LAN statistics, SIP traffic stats or even
RTCP info on the SIP phone.






  
-----Original Message-----
From: sipforum-discussion-admin@lists.su.se
[mailto:sipforum-discussion-admin@lists.su.se] On Behalf Of 
Henry Sinnreich
Sent: Monday, February 10, 2003 8:49 AM
To: 'Jörgen Björkner'; sipforum-discussion@lists.su.se
Subject: [Sipforum-discussion] SIP Telephony Device 
Requirements, Configuration and Data


For everyone interested SIP phones and other SIP
communication devices, and the 56 IETF  coming next month, 
please see if you like or dislike or don't care about the draft:

    
http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-00.txt

The idea is to have discussions on the lists, and if there is interest
and rough consensus to move ahead with an informational RFC. Would
appreciate your comments to 

sipping@ietf.org , and also to

sipforum-discussion@lists.su.se 

Thanks, Henry

Henry Sinnreich
WorldCom
400 International Parkway
Richardson, Texas 75081
USA

--------------010700070200030407060707-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 20 04:04:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04730 for ; Thu, 20 Feb 2003 04:04:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1K9BPo29034 for sipping-archive@odin.ietf.org; Thu, 20 Feb 2003 04:11:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K9BPp29031 for ; Thu, 20 Feb 2003 04:11:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04718 for ; Thu, 20 Feb 2003 04:04:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K9App28989; Thu, 20 Feb 2003 04:10:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DKLxp17105 for ; Thu, 13 Feb 2003 15:21:59 -0500 Received: from mailf.telia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25611 for ; Thu, 13 Feb 2003 15:18:07 -0500 (EST) Received: from d1o933.telia.com (d1o933.telia.com [213.67.164.241]) by mailf.telia.com (8.12.5/8.12.5) with ESMTP id h1DKLHjd012002; Thu, 13 Feb 2003 21:21:17 +0100 (CET) X-Original-Recipient: sipping@ietf.org Received: from eta (h10n2fls31o933.telia.com [212.181.137.10]) by d1o933.telia.com (8.10.2/8.10.1) with SMTP id h1DKLHq25123; Thu, 13 Feb 2003 21:21:17 +0100 (CET) From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= To: "Henry Sinnreich" , "=?iso-8859-1?Q?'J=F6rgen_Bj=F6rkner'?=" , Cc: Date: Thu, 13 Feb 2003 21:21:41 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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.2600.0000 In-Reply-To: <000601c2d113$7d0d6990$248823a6@hsinnreich2> Content-Transfer-Encoding: 8bit Subject: [Sipping] Re: [Sipforum-discussion] SIP Telephony Device Requirements, Configuration and Data Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Henry, It is mentioned in the introduction to the document that "text shall be kept in mind". I suggest some specific text items to be entered that are in line with existing standardisation, and accessibility needs and useful for all: ---------------------------------------------------------------------------- ------------------- SIP-xx, analogue text support: SIP adapter devices (for analog phone lines) MUST support conversion between real time text transmission using RFC 2793 [y] and text telephones according to ITU-T V.18 [x] allowing alternating use of text and voice. SIP clients MUST fallback to G.711 if RFC2793 connection fails. SIP-zz, digital text support: SIP telephone devices MUST support real time text conversation using RFC 2793 [y] for the text stream. It MUST be possible to use text simultaneously with voice. --------------------------------------------- In 4.11 Ringer Behaviour : add the section below for the purpose of deaf, hearing impaired, deaf-blind people and people in the garden and noisy locations: SIP Telephony devices MUST provide an external interface to an external alerting system. Add to References ----------------- [y] G. Hellstrom: "RTP Payload for Text Conversation.", RFC 2793, IETF, May 2000. [z] ITU-T Recommendation V.18 "Operational and interworking requirements for DCEs operating in the text telephone mode", November 2000 with amendment November 2002. ---------------------------------------------------------------------------- ------- Thanks ------------------------------------------- Gunnar Hellström Omnitor AB Renathvägen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom@Omnitor.se -------------------------------------------- > -----Ursprungligt meddelande----- > Från: sipforum-discussion-admin@lists.su.se > [mailto:sipforum-discussion-admin@lists.su.se]För Henry Sinnreich > Skickat: den 10 februari 2003 15:49 > Till: 'Jörgen Björkner'; sipforum-discussion@lists.su.se > Ämne: [Sipforum-discussion] SIP Telephony Device Requirements, > Configuration and Data > > > For everyone interested SIP phones and other SIP communication devices, > and the 56 IETF coming next month, please see if you like or dislike or > don't care about the draft: > > http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-00.txt > > The idea is to have discussions on the lists, and if there is interest > and rough consensus to move ahead with an informational RFC. Would > appreciate your comments to > > sipping@ietf.org , and also to > > sipforum-discussion@lists.su.se > > Thanks, Henry > > Henry Sinnreich > WorldCom > 400 International Parkway > Richardson, Texas 75081 > USA > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 20 04:07:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04760 for ; Thu, 20 Feb 2003 04:07:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1K9DZZ29099 for sipping-archive@odin.ietf.org; Thu, 20 Feb 2003 04:13:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K9DZp29096 for ; Thu, 20 Feb 2003 04:13:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04756 for ; Thu, 20 Feb 2003 04:06:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K9Csp29072; Thu, 20 Feb 2003 04:12:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1IA2Hp13600 for ; Tue, 18 Feb 2003 05:02:17 -0500 Received: from bramg1.net.external.hp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23736 for ; Tue, 18 Feb 2003 04:56:15 -0500 (EST) Received: from loire.grenoble.hp.com (loire.grenoble.hp.com [15.128.14.199]) by bramg1.net.external.hp.com (Postfix) with ESMTP id 773BC829; Tue, 18 Feb 2003 11:00:01 +0100 (MET) Received: by loire.grenoble.hp.com with Internet Mail Service (5.5.2655.55) id <14C27TA7>; Tue, 18 Feb 2003 11:00:00 +0100 Message-ID: <1FA8FB96ED5BD411911D00D0B77FC68E08652367@galilei.italy.hp.com> From: "PRATI,LUCA (HP-Italy,ex1)" To: Gonzalo Camarillo , sipping Cc: Dean Willis , Rohan Mahy , Eric Burger Subject: RE: [Sipping] Expert review for draft-burger-sipping-netann-04.tx t Date: Tue, 18 Feb 2003 10:59:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) 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: , Folks, in case of pre-paid service the we should also support the Advice of Charging. AOC information could be presented at the start of the call, or during a call, or at the end of the call. AOC may be presented using an audible tone or announcement (e.g. remaining balance = 33 minutes). The call flow in that specific case is not clear for me especially in case of Mid-Call Interruption...could help me? Thanks, Luca -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: Monday, February 10, 2003 11:40 AM To: sipping Cc: Dean Willis; Rohan Mahy; Eric Burger Subject: [Sipping] Expert review for draft-burger-sipping-netann-04.txt Folks, We would like the SIPPING working group to provide expert review of: http://www.ietf.org/internet-drafts/draft-burger-sipping-netann-04.txt The authors have requested individual publication of this document. Expert Review will close on March 10th, 2003 Thanks, Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 20 04:09:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04798 for ; Thu, 20 Feb 2003 04:09:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1K9FW229167 for sipping-archive@odin.ietf.org; Thu, 20 Feb 2003 04:15:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K9FWp29164 for ; Thu, 20 Feb 2003 04:15:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04784 for ; Thu, 20 Feb 2003 04:08:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K9Ewp29131; Thu, 20 Feb 2003 04:14:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J84rp15831 for ; Wed, 19 Feb 2003 03:04:53 -0500 Received: from p2.piuha.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15630 for ; Wed, 19 Feb 2003 02:58:23 -0500 (EST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 010486A905; Wed, 19 Feb 2003 10:02:11 +0200 (EET) Message-ID: <3E5339E4.7030204@piuha.net> Date: Wed, 19 Feb 2003 10:01:40 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henry Sinnreich Cc: jh@lohi.eng.song.fi, "'Gonzalo Camarillo'" , "'sipping'" , "'John Loughney'" Subject: Re: [Sipping] New version of the SIP-AAA reqs draft References: <000201c2d7dc$a4b138d0$416032a6@hsinnreich2> 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I don't think the AAA architecture RG is an engineering alternative the SIP WG can consider, assuming we want to get this thing deployed and running in a relatively short time period with many vendors supporting it. My preference is DIAMETER. I do agree that we probably need to look at RADIUS compatibility as well. Perhaps this is the compromise we need for us to continue? (I don't see a major technical obstacle to the compatibility; the DIAMETER NASREQ application has been defined to work with existing RADIUS NASes. If SIP AAA is defined with this in mind, we can get at least some amount of functionality over RADIUS. The main problem is perhaps finding standardized RADIUS attribute numbers, of which we have almost run out... Also naturally, some new functions of DIAMETER can not be realized through translation to RADIUS, such as the what requirement 2.3.4 in the SIP AAA requirements draft indicates. And I would reserve RADIUS mode mainly for compatibility with old products, not as the mandatory-to-implement feature in some future RFC. It is seen as the weakest component in the security of planned network access systems, for instance.) Perhaps I'm biased for being involved in the DIAMETER work myself. However, I am also involved with some planned very large scale applications of SIP, and those folks intend to use DIAMETER -- they are also building products in this space. Finally, a few comments to the SIP-AAA requirements: - The security requirements might be expanded a bit. Are proxies going to be needed? Is end-to-end security through proxies necessary for some reason? - The document does not mention anything about reliability of AAA transactions, accounting in particular. I would think this is of high interest, as Allison also noted. - Do we really need both cumulative and non-cumulative accounting? - 2.4.2 and 2.4.3 are unclear to me. What is really required here? - Section 3.2 example is a bit thin. I suspect there's more to it than this. - John's address has a non-ASCII character. Jari Henry Sinnreich wrote: > I still would like to hear if people think a discussion with the AAA > architecture RG is a good way to get out of this impasse. Please browse > the work at http://www.aaaarch.org/charter.html > > It appears there is enough push-back on DIAMETER in this WG that this > should be given some time for discussion at the next meeting. All > messages from the 'audience' favored RADIUS, contrary to the proposed > work agenda. > > I have yet to hear an argument why some form of XML documents over some > secure transport, as in Web Services should not be the choice after > RADIUS. > > Or are the authors so committed to a DIAMETER project that this > discussion is futile? > > Thanks, Henry > > > > >>-----Original Message----- >>From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] >>Sent: Tuesday, February 18, 2003 11:35 PM >>To: Henry Sinnreich >>Cc: 'Gonzalo Camarillo'; 'sipping'; 'John Loughney' >>Subject: RE: [Sipping] New version of the SIP-AAA reqs draft >> >> >>Henry Sinnreich writes: >> >> > I suggest therefore to start with RADIUS instead. >> >>i fully agree, juha >> > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 20 04:11:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04886 for ; Thu, 20 Feb 2003 04:11:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1K9Hb729221 for sipping-archive@odin.ietf.org; Thu, 20 Feb 2003 04:17:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K9Hbp29218 for ; Thu, 20 Feb 2003 04:17:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04875 for ; Thu, 20 Feb 2003 04:10:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K9H1p29201; Thu, 20 Feb 2003 04:17:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JIl4p00795 for ; Wed, 19 Feb 2003 13:47:04 -0500 Received: from newman.gte.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04395 for ; Wed, 19 Feb 2003 13:40:21 -0500 (EST) Received: from rcmppc2.gte.com (rcmppc2.gte.com [132.197.73.30]) by newman.gte.com (8.9.1/8.9.1) with ESMTP id NAA02248; Wed, 19 Feb 2003 13:44:08 -0500 (EST) Message-Id: <5.1.1.6.0.20030219133601.041fa380@pophost.gte.com> X-Sender: sjj0@pophost.gte.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 19 Feb 2003 13:44:29 -0500 To: Allison Mankin From: Stuart Jacobs Subject: Re: [Sipping] New version of the SIP-AAA reqs draft Cc: sipping@ietf.org In-Reply-To: References: <5.2.0.9.0.20030213195458.04501ea0@mailhost.fokus.gmd.de> 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: , Allison, Within Verizon, accounting of SIP based services will most likely not use Diameter in our Next Generation Network (NGN) VoIP Services. We will be doing our usage accounting within SIP Proxies and intend to transfer said accounting "call detail records" back to our billing OSSes via other protocols with IPsec providing authentication and confidentiality for these transfers. We currently do not plan on any deployment of Diameter within Verizon's wireline NGN architecture. We will probably continue to use Radius for remote access authentication at the application layer for a number or years into the future. Stu Jacobs At 2/14/03 09:58 PM, you wrote: >Jiri, > >It always seems good to be able to stay with installed base, but >there's a factor against our supporting RADIUS drafts for SIP's >accounting - safety. Even though there is deployment, there are >some extremely bad cases of damage in production, and the IETF >has concluded that RADIUS is not suitable for usage-based accounting >(RFC2975). > >Unless there is no intention of having in SIP accounting usage-based, >monetary, auditable applications, RADIUS is not the solution. The >protocol just does not preserve a complete stream of reliable >accounting records that are auditable on any level, especially with >any roaming. As Bernard Aboba stated to this WG, quoting Mike O'Dell, >the use of RADIUS may even be illegal in situations where there is an >authority over the billing. Records are too easily lost by the >protocol. This is stated clearly by RFC2975. This is the reason why >the Operations and Mgt Area developed Diameter. On these technical* >grounds, that the RADIUS protocol does not have enough reliability, >the work must be based on the Diameter protocol, which is now >approved. Alternatively, work could be done that does not include >usage-based accounting, but this does not seem to be what is >envisioned in the SIPPING AAA requirements. > >Allison > >P.S. There's a current investigation of RADIUS compatibility mode >in Diameter for this - more needs to be thought about it. > > > > At 07:46 PM 2/11/2003, john.loughney@nokia.com wrote: > > >Hi Henry, > > > > > >> >but one option is develop a solution using > > >> > Diameter in RADIUS-compatibility mode. > > >> > > >> OK, this is better than nothing. We'll take what we can :-) > > >> > > >> As mentioned, the installed base is RADIUS, no matter how > > >> voluminous the DIAMETER literature may be. > > > > > >I think the issues is that the IETF should recommend what is the > > >right thing to do & why. If people choose to do something else, > > >well, that is life. > > > > Remember that running code does not necessarily mean something known > > to compile -- that is something known to be deployed. > > > > >I understand what you are asking but I do note that some > > >people have thought that the potential for AAA is much greater > > >than the existing installed base. > > > > I actually think that the deployment argument is a very important one. > > > > -Jiri > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the 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 ========================== Stuart Jacobs CISSP PMTS - Sr. Technologist Verizon Laboratories 40 Sylvan Road Waltham, MA 02451-1128 USA telephone: (781) 466-3076 fax: (781) 466-2838 stu.jacobs@labs.gte.com sjj0@labs.gte.com stu.jacobs@verizon.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 mailnull@www1.ietf.org Thu Feb 20 09:09:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14922 for ; Thu, 20 Feb 2003 09:09:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KEGRt15498 for sipping-archive@odin.ietf.org; Thu, 20 Feb 2003 09:16:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KEGRp15495 for ; Thu, 20 Feb 2003 09:16:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14870 for ; Thu, 20 Feb 2003 09:09:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KEFgp15463; Thu, 20 Feb 2003 09:15:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KEEqp15427 for ; Thu, 20 Feb 2003 09:14:52 -0500 Received: from pmesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14846 for ; Thu, 20 Feb 2003 09:07:45 -0500 (EST) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0HAM0046M1W2VS@firewall.wcom.com> for sipping@ietf.org; Thu, 20 Feb 2003 14:07:14 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HAM00E011UR54@pmismtp04.wcomnet.com>; Thu, 20 Feb 2003 14:07:14 +0000 (GMT) Received: from hsinnreich2 ([166.42.40.80]) by pmismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HAM00A8C12M1Y@pmismtp04.wcomnet.com>; Thu, 20 Feb 2003 14:06:29 +0000 (GMT) Date: Thu, 20 Feb 2003 08:06:29 -0600 From: Henry Sinnreich Subject: RE: [Sipping] Re: [Sipforum-discussion] SIP Telephony Device Requirements, Configuration and Data In-reply-to: To: "=?iso-8859-1?Q?'Gunnar_Hellstr=F6m'?=" , "=?iso-8859-1?Q?'J=F6rgen_Bj=F6rkner'?=" , sipforum-discussion@lists.su.se Cc: sipping@ietf.org Message-id: <002101c2d8e9$448b13a0$50282aa6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=iso-8859-1 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1KEEqp15428 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Gunnar Hellström writes: > SIP-xx, analogue text support: SIP adapter devices (for > analog phone lines) > MUST support conversion between real time text transmission > using RFC 2793 [y] > and text telephones according to ITU-T V.18 [x] allowing > alternating use of > text and voice. SIP clients MUST fallback to G.711 if > RFC2793 connection fails. This and the other below are excellent points! Thanks for the contribution. Will add in the next version of http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-00.txt Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of Gunnar Hellström > Sent: Thursday, February 13, 2003 2:22 PM > To: Henry Sinnreich; 'Jörgen Björkner'; > sipforum-discussion@lists.su.se > Cc: sipping@ietf.org > Subject: [Sipping] Re: [Sipforum-discussion] SIP Telephony > Device Requirements, Configuration and Data > > > Henry, > > It is mentioned in the introduction to the document that > "text shall be kept in mind". > > I suggest some specific text items to be entered that are in > line with existing standardisation, and accessibility needs > and useful for all: > > -------------------------------------------------------------- > -------------- > ------------------- > SIP-xx, analogue text support: SIP adapter devices (for > analog phone lines) > MUST support conversion between real time text transmission > using RFC 2793 [y] > and text telephones according to ITU-T V.18 [x] allowing > alternating use of > text and voice. SIP clients MUST fallback to G.711 if > RFC2793 connection fails. > > > SIP-zz, digital text support: SIP telephone devices MUST support > real time text conversation using RFC 2793 [y] for the text stream. > It MUST be possible to use text simultaneously with voice. > > > > --------------------------------------------- > In 4.11 Ringer Behaviour : add the section below for the > purpose of deaf, hearing impaired, deaf-blind people and > people in the garden and noisy > locations: > > SIP Telephony devices MUST provide an external interface to > an external alerting system. > > > > Add to References > ----------------- > [y] G. Hellstrom: "RTP Payload for Text Conversation.", RFC > 2793, IETF, May 2000. [z] ITU-T Recommendation V.18 > "Operational and interworking requirements for DCEs operating > in the text telephone mode", November 2000 with amendment > November 2002. > > -------------------------------------------------------------- > -------------- > ------- > > > > > Thanks > ------------------------------------------- > Gunnar Hellström > Omnitor AB > Renathvägen 2 > SE 121 37 Johanneshov > SWEDEN > +46 8 556 002 03 > Mob: +46 708 204 288 > www.omnitor.se > Gunnar.Hellstrom@Omnitor.se > -------------------------------------------- > > > -----Ursprungligt meddelande----- > > Från: sipforum-discussion-admin@lists.su.se > > [mailto:sipforum-discussion-admin@lists.su.se]För Henry Sinnreich > > Skickat: den 10 februari 2003 15:49 > > Till: 'Jörgen Björkner'; sipforum-discussion@lists.su.se > > Ämne: [Sipforum-discussion] SIP Telephony Device Requirements, > > Configuration and Data > > > > > > For everyone interested SIP phones and other SIP communication > > devices, and the 56 IETF coming next month, please see if > you like or > > dislike or don't care about the draft: > > > > > http://www.ietf.org/internet-> drafts/draft-sinnreich-sipdev-req-00.txt > > > > The idea is to have discussions on the lists, and if there > is interest > > and rough consensus to move ahead with an informational RFC. Would > > appreciate your comments to > > > > sipping@ietf.org , and also to > > > > sipforum-discussion@lists.su.se > > > > Thanks, Henry > > > > Henry Sinnreich > > WorldCom > > 400 International Parkway > > Richardson, Texas 75081 > > USA > > > > > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 mailnull@www1.ietf.org Thu Feb 20 16:33:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00431 for ; Thu, 20 Feb 2003 16:33:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KLe7718233 for sipping-archive@odin.ietf.org; Thu, 20 Feb 2003 16:40:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KLe7p18230 for ; Thu, 20 Feb 2003 16:40:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00426 for ; Thu, 20 Feb 2003 16:32:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KLbWp18079; Thu, 20 Feb 2003 16:37:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KLZkp17256 for ; Thu, 20 Feb 2003 16:35:46 -0500 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00184 for ; Thu, 20 Feb 2003 16:28:29 -0500 (EST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h1KLWDo00580; Thu, 20 Feb 2003 15:32:13 -0600 (CST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1LWHXXMN>; Thu, 20 Feb 2003 13:32:14 -0800 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D206B7F8FC@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Gonzalo Camarillo'" , "'sipping'" Cc: "'Dean Willis'" , "'Rohan Mahy'" , "'kns10@cs.columbia.edu'" , "'Henning Schulzrinne'" , "'alan.johnston@wcom.com'" , "'rrroy@att.com'" Subject: RE: [Sipping] SIP-H.323 design team Date: Thu, 20 Feb 2003 13:32:13 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D927.883F712A" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2D927.883F712A Content-Type: text/plain; charset="iso-8859-1" Gonzallo and all, I have a few comments/concerns about this requirement document. - Section 6 states that the IWF shall use the H.323 version 2 Recommendation. I don't believe this is a valid requirement. Many (if not most) implementations are up to versions 3 and 4 these days. We could either say nothing at all about H.323 versions, or require version 2 or above. In H.323, new versions need to be backward compatible with older versions, so this shouldn't be an issue. - Many requirements are extremely vague. For example, things like 6.1.2 a "the IWF shall support all the addressing shcemes of both H.323 and SIP". I'm not sure if this is even feasible. Requirement 8.1.1 is also very vague I also really doubt that it is even possible to do so: I'd recommend writing examples instead of a clear mapping). - Certain requirements seem to modify the behavior that and H.323 endpoint or GK may have. We can not impose system-wide behavioral changes on an existing H.323 (or SIP) network. For example, 6.4 says that the pre-granted ARQ shall be supported by the IWF. It is entirely up to the GK to decide which mode (pre-granted or not) will be used, not the IWF. Perhaps I'm not reading the requirement properly and this requirement is just saying that the IWF needs to support both pre-Granted ARQ and normal ARQ (if it is the case, then this bullet should just be merger with the previous requirement about vague requirements). One of the reason I am thinking that the intent is to prescribe a specific behavior on the H.323 (and SIP) protocol is that the now-expired draft-agrawal-sip-h323-interworking-01.txt was doing so. Are we thinking of ressucitating this draft, or are we thinking of starting from scratch with a different approach? - Section 6.5 uses the INFO method for sending DTMF information. I will point out that H.323v4 supports RFC2833 (the procedures for exchanging the necessary dynamic payload type are similar to the procedures used in SIP). - Section 8.2 I like. - Section 8.4 needs to be clarified (what is "invisible support"?). - Section 12.4 is probably one of the most important to look into. It should explain how the offer/answer model maps to H.323 (both fastStart and mid/call or slow start). It should talk about re-INVITE, UPDATE, OpenLogicalChannnel, a=sendonly/inactive, TCS=0,etc. I am pretty sure that there is no simple mapping as the models are quite different. - There should also be a section on in-band and out-of band media (early media) and how they map. Lastly, we need to make sure that this document is meant to be informative at best. I would much prefer to have document explaining the various mismatches between SIP and H.323 and how to minimize them than a document trying to describe a fixed mapping between the two: more a free-form description of the various "gotchas" that may be encountered when trying to interwork the two protocols. For example, it could explain how opening logical channels in H.323 and the terminal capability set negotiation process differ from the offer/answer model. I see very little benefits in creating a document that would describe only a mapping for "basic call setup" as this is not where people are going to have difficulties. I am convinced that a "simple protocol mapping" approach such as the one defined in the now expired draft-agrawal-sip-h323-interworking-01.txt is not possible and that instead the IWF will have to maintain full call control/state information in order to map properly between the protocols. I think we would be doing developpers and service providers a great disservice by issuing an RFC implying that a simple "protocol mapping" box might be sufficient to allow for interworking between SIP and H.323. I'd rather see no interworking document at all than a simplistic mapping document. Comments? François Audet > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Monday, February 10, 2003 12:17 AM > To: sipping > Cc: Dean Willis; Rohan Mahy; kns10@cs.columbia.edu; Henning > Schulzrinne; alan.johnston@wcom.com; rrroy@att.com > Subject: [Sipping] SIP-H.323 design team > > > Folks, > > The requirements document for SIP-H.323 interworking is advancing: > http://www.ietf.org/internet-drafts/draft-agrawal-sip-h323-interworking-reqs -03.txt Now, it is time to start thinking about the solution document. If there are enough people willing to contribute, we intend to form a design team in SIPPING. The scope of the work will be most likely limited to basic call set-up. Those of you who are interested in being part of such a design team, please let me know. Thanks, Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP ------_=_NextPart_001_01C2D927.883F712A Content-Type: text/html; charset="iso-8859-1" RE: [Sipping] SIP-H.323 design team

Gonzallo and all,

I have a few comments/concerns about this requirement document.

- Section 6 states that the IWF shall use the H.323 version 2 Recommendation. I don't believe
  this is a valid requirement. Many (if not most) implementations are up to versions 3 and 4
  these days. We could either say nothing at all about H.323 versions, or require version 2
  or above. In H.323, new versions need to be backward compatible with older versions, so this
  shouldn't be an issue.

- Many requirements are extremely vague. For example, things like 6.1.2 a "the IWF shall support
  all the addressing shcemes of both H.323 and SIP". I'm not sure if this is even feasible.
  Requirement 8.1.1 is also very vague I also really doubt that it is even possible to do so:
  I'd recommend writing examples instead of a clear mapping).

- Certain requirements seem to modify the behavior that and H.323 endpoint or GK may have. We
  can not impose system-wide behavioral changes on an existing H.323 (or SIP) network. For example,
  6.4 says that the pre-granted ARQ shall be supported by the IWF. It is entirely up to the
  GK to decide which mode (pre-granted or not) will be used, not the IWF. Perhaps I'm not reading
  the requirement properly and this requirement is just saying that the IWF needs to support
  both pre-Granted ARQ and normal ARQ (if it is the case, then this bullet should just be
  merger with the previous requirement about vague requirements). One of the reason I am
  thinking that the intent is to prescribe a specific behavior on the H.323 (and SIP) protocol
  is that the now-expired draft-agrawal-sip-h323-interworking-01.txt was doing so. Are we
  thinking of ressucitating this draft, or are we thinking of starting from scratch with
  a different approach?

- Section 6.5 uses the INFO method for sending DTMF information. I will point out that H.323v4
  supports RFC2833 (the procedures for exchanging the necessary dynamic payload type are
  similar to the procedures used in SIP).

- Section 8.2 I like.

- Section 8.4 needs to be clarified (what is "invisible support"?).

- Section 12.4 is probably one of the most important to look into. It should explain how the
  offer/answer model maps to H.323 (both fastStart and mid/call or slow start). It should
  talk about re-INVITE, UPDATE, OpenLogicalChannnel, a=sendonly/inactive, TCS=0,etc.
  I am pretty sure that there is no simple mapping as the models are quite different.

- There should also be a section on in-band and out-of band media (early media) and how they
  map.

Lastly, we need to make sure that this document is meant to be informative at best. I would
much prefer to have document explaining the various mismatches between SIP and H.323 and how
to minimize them than a document trying to describe a fixed mapping between the two: more
a free-form description of the various "gotchas" that may be encountered when trying to
interwork the two protocols.

For example, it could explain how opening logical channels in H.323 and the terminal
capability set negotiation process differ from the offer/answer model. I see very little
benefits in creating a document that would describe only a mapping for "basic call setup"
as this is not where people are going to have difficulties.

I am convinced that a "simple protocol mapping" approach such as the one defined in the now
expired draft-agrawal-sip-h323-interworking-01.txt is not possible and that instead the IWF
will have to maintain full call control/state information in order to map properly between
the protocols. I think we would be doing developpers and service providers a great disservice
by issuing an RFC implying that a simple "protocol mapping" box might be sufficient to allow
for interworking between SIP and H.323. I'd rather see no interworking document at all than
a simplistic mapping document.

Comments?

François Audet



> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> Sent: Monday, February 10, 2003 12:17 AM
> To: sipping
> Cc: Dean Willis; Rohan Mahy; kns10@cs.columbia.edu; Henning
> Schulzrinne; alan.johnston@wcom.com; rrroy@att.com
> Subject: [Sipping] SIP-H.323 design team
>
>
> Folks,
>
> The requirements document for SIP-H.323 interworking is advancing:
>
http://www.ietf.org/internet-drafts/draft-agrawal-sip-h323-interworking-reqs-03.txt

Now, it is time to start thinking about the solution document. If there are enough people willing to contribute, we intend to form a design team in SIPPING.

The scope of the work will be most likely limited to basic call set-up.

Those of you who are interested in being part of such a design team, please let me know.

Thanks,

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

------_=_NextPart_001_01C2D927.883F712A-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 20 18:37:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03597 for ; Thu, 20 Feb 2003 18:37:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KNi7v26545 for sipping-archive@odin.ietf.org; Thu, 20 Feb 2003 18:44:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KNi7p26542 for ; Thu, 20 Feb 2003 18:44:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03594 for ; Thu, 20 Feb 2003 18:36:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KNfSp26452; Thu, 20 Feb 2003 18:41:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KNeLp26418 for ; Thu, 20 Feb 2003 18:40:21 -0500 Received: from pmesmtp01.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03497 for ; Thu, 20 Feb 2003 18:33:02 -0500 (EST) Received: from dgismtp05.wcomnet.com ([166.38.58.88]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HAM00FFZS8FF0@firewall.wcom.com> for sipping@ietf.org; Thu, 20 Feb 2003 23:36:15 +0000 (GMT) Received: from dgismtp05.wcomnet.com by dgismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HAM00D01S8FMC@dgismtp05.wcomnet.com>; Thu, 20 Feb 2003 23:36:15 +0000 (GMT) Received: from hsinnreich2 ([166.35.136.36]) by dgismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HAM00AF6S8EMU@dgismtp05.wcomnet.com>; Thu, 20 Feb 2003 23:36:15 +0000 (GMT) Date: Thu, 20 Feb 2003 17:36:13 -0600 From: Henry Sinnreich Subject: RE: [Sipping] New version of the SIP-AAA reqs draft In-reply-to: <3E5339E4.7030204@piuha.net> To: jari.arkko@piuha.net Cc: jh@lohi.eng.song.fi, "'Gonzalo Camarillo'" , "'sipping'" , "'John Loughney'" Message-id: <004201c2d938$db818650$248823a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I don't think the AAA architecture RG is an engineering > alternative the SIP WG can consider, It would be only fair to include the aaaarch folks in this discussion. They have done serious work - applicable to the real world. Thanks, Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of Jari Arkko > Sent: Wednesday, February 19, 2003 2:02 AM > To: Henry Sinnreich > Cc: jh@lohi.eng.song.fi; 'Gonzalo Camarillo'; 'sipping'; > 'John Loughney' > Subject: Re: [Sipping] New version of the SIP-AAA reqs draft > > > > I don't think the AAA architecture RG is an engineering > alternative the SIP WG can consider, assuming we want to get > this thing deployed and running in a relatively short time > period with many vendors supporting it. > > My preference is DIAMETER. I do agree that we probably need > to look at RADIUS compatibility as well. Perhaps this is the > compromise we need for us to continue? (I don't see a major > technical obstacle to the compatibility; the DIAMETER NASREQ > application has been defined to work with existing RADIUS > NASes. If SIP AAA is defined with this in mind, we can get at > least some amount of functionality over RADIUS. The main > problem is perhaps finding standardized RADIUS attribute > numbers, of which we have almost run out... Also naturally, > some new functions of DIAMETER can not be realized through > translation to RADIUS, such as the what requirement 2.3.4 in > the SIP AAA requirements draft indicates. And I would reserve > RADIUS mode mainly for compatibility with old products, not > as the mandatory-to-implement feature in some future RFC. It > is seen as the weakest component in the security of planned > network access systems, for instance.) > > Perhaps I'm biased for being involved in the DIAMETER work > myself. However, I am also involved with some planned very > large scale applications of SIP, and those folks intend to > use DIAMETER -- they are also building products in this space. > > Finally, a few comments to the SIP-AAA requirements: > > - The security requirements might be expanded a bit. > Are proxies going to be needed? Is end-to-end > security through proxies necessary for some reason? > > - The document does not mention anything about reliability > of AAA transactions, accounting in particular. I would > think this is of high interest, as Allison also noted. > > - Do we really need both cumulative and non-cumulative > accounting? > > - 2.4.2 and 2.4.3 are unclear to me. What is really > required here? > > - Section 3.2 example is a bit thin. I suspect there's > more to it than this. > > - John's address has a non-ASCII character. > > Jari > > Henry Sinnreich wrote: > > I still would like to hear if people think a discussion > with the AAA > > architecture RG is a good way to get out of this impasse. Please > > browse the work at http://www.aaaarch.org/charter.html > > > > It appears there is enough push-back on DIAMETER in this WG > that this > > should be given some time for discussion at the next meeting. All > > messages from the 'audience' favored RADIUS, contrary to > the proposed > > work agenda. > > > > I have yet to hear an argument why some form of XML documents over > > some secure transport, as in Web Services should not be the choice > > after RADIUS. > > > > Or are the authors so committed to a DIAMETER project that this > > discussion is futile? > > > > Thanks, Henry > > > > > > > > > >>-----Original Message----- > >>From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > >>Sent: Tuesday, February 18, 2003 11:35 PM > >>To: Henry Sinnreich > >>Cc: 'Gonzalo Camarillo'; 'sipping'; 'John Loughney' > >>Subject: RE: [Sipping] New version of the SIP-AAA reqs draft > >> > >> > >>Henry Sinnreich writes: > >> > >> > I suggest therefore to start with RADIUS instead. > >> > >>i fully agree, juha > >> > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sip@ietf.org for new developments of core SIP > > > > > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 mailnull@www1.ietf.org Thu Feb 20 18:42:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03668 for ; Thu, 20 Feb 2003 18:42:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KNmra26697 for sipping-archive@odin.ietf.org; Thu, 20 Feb 2003 18:48:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KNmrp26694 for ; Thu, 20 Feb 2003 18:48:53 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03653 for ; Thu, 20 Feb 2003 18:41:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KNk6p26636; Thu, 20 Feb 2003 18:46:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KNjSp26605 for ; Thu, 20 Feb 2003 18:45:28 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03615 for ; Thu, 20 Feb 2003 18:38:09 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h1KNfUxw000635 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 20 Feb 2003 18:41:31 -0500 (EST) Message-ID: <3E5567B3.5080407@cs.columbia.edu> Date: Thu, 20 Feb 2003 18:41:39 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Audet CC: "'Gonzalo Camarillo'" , "'sipping'" , "'Dean Willis'" , "'Rohan Mahy'" , "'kns10@cs.columbia.edu'" , "'alan.johnston@wcom.com'" , "'rrroy@att.com'" Subject: Re: [Sipping] SIP-H.323 design team References: <2F1FC1DEA077D5119FAD00508BCFD6D206B7F8FC@zsc3c030.us.nortel.com> In-Reply-To: <2F1FC1DEA077D5119FAD00508BCFD6D206B7F8FC@zsc3c030.us.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Francois Audet wrote: > Gonzallo and all, > > I have a few comments/concerns about this requirement document. Before we go there: the requirements document was last-called sometime in the last millenium and is now at the RFC editor. (The text will change a bit due to some last-minute editing to make it a bit more readable, but it's too late to make substantive changes). draft-agrawal-sip-h323-interworking-reqs-03 was issued in early 2002, I think and was IESG approved for informational on April 18, 2002. Thus, your comments would have been somewhat more helpful about 18 months ago :-) > > - Section 6 states that the IWF shall use the H.323 version 2 > Recommendation. I don't believe > this is a valid requirement. Many (if not most) implementations are up > to versions 3 and 4 > these days. We could either say nothing at all about H.323 versions, > or require version 2 > or above. In H.323, new versions need to be backward compatible with > older versions, so this > shouldn't be an issue. > > - Many requirements are extremely vague. For example, things like 6.1.2 > a "the IWF shall support > all the addressing shcemes of both H.323 and SIP". I'm not sure if > this is even feasible. > Requirement 8.1.1 is also very vague I also really doubt that it is > even possible to do so: > I'd recommend writing examples instead of a clear mapping). > > - Certain requirements seem to modify the behavior that and H.323 > endpoint or GK may have. We > can not impose system-wide behavioral changes on an existing H.323 (or > SIP) network. For example, > 6.4 says that the pre-granted ARQ shall be supported by the IWF. It is > entirely up to the > GK to decide which mode (pre-granted or not) will be used, not the > IWF. Perhaps I'm not reading > the requirement properly and this requirement is just saying that the > IWF needs to support > both pre-Granted ARQ and normal ARQ (if it is the case, then this > bullet should just be > merger with the previous requirement about vague requirements). One of > the reason I am > thinking that the intent is to prescribe a specific behavior on the > H.323 (and SIP) protocol > is that the now-expired draft-agrawal-sip-h323-interworking-01.txt was > doing so. Are we > thinking of ressucitating this draft, or are we thinking of starting > from scratch with > a different approach? > > - Section 6.5 uses the INFO method for sending DTMF information. I will > point out that H.323v4 > supports RFC2833 (the procedures for exchanging the necessary dynamic > payload type are > similar to the procedures used in SIP). The final version has removed any mentioning of INFO. I caught this at the last minute :-) > > - Section 8.2 I like. > > - Section 8.4 needs to be clarified (what is "invisible support"?). > > - Section 12.4 is probably one of the most important to look into. It > should explain how the > offer/answer model maps to H.323 (both fastStart and mid/call or slow > start). It should > talk about re-INVITE, UPDATE, OpenLogicalChannnel, > a=sendonly/inactive, TCS=0,etc. > I am pretty sure that there is no simple mapping as the models are > quite different. > > - There should also be a section on in-band and out-of band media (early > media) and how they > map. > > Lastly, we need to make sure that this document is meant to be > informative at best. I would It will be, like all requirements documents. > much prefer to have document explaining the various mismatches between > SIP and H.323 and how > to minimize them than a document trying to describe a fixed mapping > between the two: more > a free-form description of the various "gotchas" that may be encountered > when trying to > interwork the two protocols. Your contribution to such a document would be much appreciated. Unfortunately, it doesn't write itself... > > For example, it could explain how opening logical channels in H.323 and > the terminal > capability set negotiation process differ from the offer/answer model. I > see very little > benefits in creating a document that would describe only a mapping for > "basic call setup" > as this is not where people are going to have difficulties. > > I am convinced that a "simple protocol mapping" approach such as the one > defined in the now > expired draft-agrawal-sip-h323-interworking-01.txt is not possible and > that instead the IWF > will have to maintain full call control/state information in order to > map properly between > the protocols. I think we would be doing developpers and service > providers a great disservice > by issuing an RFC implying that a simple "protocol mapping" box might be > sufficient to allow > for interworking between SIP and H.323. I'd rather see no interworking > document at all than > a simplistic mapping document. > > Comments? > > François Audet > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 20 18:48:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03729 for ; Thu, 20 Feb 2003 18:48:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KNtkp26908 for sipping-archive@odin.ietf.org; Thu, 20 Feb 2003 18:55:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KNtkp26905 for ; Thu, 20 Feb 2003 18:55:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03719 for ; Thu, 20 Feb 2003 18:48:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KNr5p26839; Thu, 20 Feb 2003 18:53:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KNq4p26807 for ; Thu, 20 Feb 2003 18:52:04 -0500 Received: from pmesmtp01.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03688 for ; Thu, 20 Feb 2003 18:44:45 -0500 (EST) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HAM00GB7SOJCO@firewall.wcom.com> for sipping@ietf.org; Thu, 20 Feb 2003 23:45:55 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HAM00101SO2JZ@dgismtp01.wcomnet.com>; Thu, 20 Feb 2003 23:45:54 +0000 (GMT) Received: from hsinnreich2 ([166.35.136.36]) by dgismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HAM0004KSO3TY@dgismtp01.wcomnet.com>; Thu, 20 Feb 2003 23:45:41 +0000 (GMT) Date: Thu, 20 Feb 2003 17:45:38 -0600 From: Henry Sinnreich Subject: RE: [Sipping] New version of the SIP-AAA reqs draft In-reply-to: <5.1.1.6.0.20030219133601.041fa380@pophost.gte.com> To: "'Stuart Jacobs'" , "'Allison Mankin'" Cc: sipping@ietf.org, Henning Schulzrinne Message-id: <005e01c2d93a$2cdbd450$248823a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Is there any service provider planning to use SIP-DIAMETER? If yes, please speak up. (Though a count for SIP-RADIUS would be just as interesting) It looks not only is RADIUS the installed base, but it will continue to be so. The design group should therefore give priority to the SIP-RADIUS work. Actually, the old I-D by Henning Schulzrinne is pretty solid and probably could be used 'as is'. Thanks, Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of Stuart Jacobs > Sent: Wednesday, February 19, 2003 12:44 PM > To: Allison Mankin > Cc: sipping@ietf.org > Subject: Re: [Sipping] New version of the SIP-AAA reqs draft > > > Allison, > > Within Verizon, accounting of SIP based services will most > likely not use > Diameter in our Next Generation Network (NGN) VoIP Services. > We will be > doing our usage accounting within SIP Proxies and intend to > transfer said > accounting "call detail records" back to our billing OSSes via other > protocols with IPsec providing authentication and > confidentiality for these > transfers. We currently do not plan on any deployment of > Diameter within > Verizon's wireline NGN architecture. We will probably > continue to use > Radius for remote access authentication at the application > layer for a > number or years into the future. > > Stu Jacobs > > At 2/14/03 09:58 PM, you wrote: > > >Jiri, > > > >It always seems good to be able to stay with installed base, but > >there's a factor against our supporting RADIUS drafts for SIP's > >accounting - safety. Even though there is deployment, there > are some > >extremely bad cases of damage in production, and the IETF > has concluded > >that RADIUS is not suitable for usage-based accounting (RFC2975). > > > >Unless there is no intention of having in SIP accounting > usage-based, > >monetary, auditable applications, RADIUS is not the solution. The > >protocol just does not preserve a complete stream of reliable > >accounting records that are auditable on any level, > especially with any > >roaming. As Bernard Aboba stated to this WG, quoting Mike > O'Dell, the > >use of RADIUS may even be illegal in situations where there is an > >authority over the billing. Records are too easily lost by the > >protocol. This is stated clearly by RFC2975. This is the reason why > >the Operations and Mgt Area developed Diameter. On these technical* > >grounds, that the RADIUS protocol does not have enough > reliability, the > >work must be based on the Diameter protocol, which is now approved. > >Alternatively, work could be done that does not include usage-based > >accounting, but this does not seem to be what is envisioned in the > >SIPPING AAA requirements. > > > >Allison > > > >P.S. There's a current investigation of RADIUS compatibility mode in > >Diameter for this - more needs to be thought about it. > > > > > > At 07:46 PM 2/11/2003, john.loughney@nokia.com wrote: > > > >Hi Henry, > > > > > > > >> >but one option is develop a solution using > > > >> > Diameter in RADIUS-compatibility mode. > > > >> > > > >> OK, this is better than nothing. We'll take what we can :-) > > > >> > > > >> As mentioned, the installed base is RADIUS, no matter how > > > >> voluminous the DIAMETER literature may be. > > > > > > > >I think the issues is that the IETF should recommend what is the > > > >right thing to do & why. If people choose to do something else, > > > >well, that is life. > > > > > > Remember that running code does not necessarily mean > something known > > > to compile -- that is something known to be deployed. > > > > > > >I understand what you are asking but I do note that some people > > > >have thought that the potential for AAA is much greater than the > > > >existing installed base. > > > > > > I actually think that the deployment argument is a very important > > > one. > > > > > > -Jiri > > > > > > _______________________________________________ > > > Sipping mailing list > https://www1.ietf.org/mailman/listi> nfo/sipping > > > This list > is for NEW development of the > 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 > > ========================== > Stuart Jacobs CISSP > PMTS - Sr. Technologist > Verizon Laboratories > 40 Sylvan Road Waltham, MA 02451-1128 USA > telephone: (781) 466-3076 fax: (781) 466-2838 > stu.jacobs@labs.gte.com sjj0@labs.gte.com > stu.jacobs@verizon.com ========================== > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 20 19:01:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04028 for ; Thu, 20 Feb 2003 19:01:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1L07sq28200 for sipping-archive@odin.ietf.org; Thu, 20 Feb 2003 19:07:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L07sp28197 for ; Thu, 20 Feb 2003 19:07:54 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04016 for ; Thu, 20 Feb 2003 19:00:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L05Cp27408; Thu, 20 Feb 2003 19:05:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L04Hp27361 for ; Thu, 20 Feb 2003 19:04:17 -0500 Received: from p2.piuha.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03980 for ; Thu, 20 Feb 2003 18:56:57 -0500 (EST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id F34D46A902; Fri, 21 Feb 2003 02:00:47 +0200 (EET) Message-ID: <3E556C0D.6060403@piuha.net> Date: Fri, 21 Feb 2003 02:00:13 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henry Sinnreich Cc: "'Stuart Jacobs'" , "'Allison Mankin'" , sipping@ietf.org, Henning Schulzrinne Subject: Re: [Sipping] New version of the SIP-AAA reqs draft References: <005e01c2d93a$2cdbd450$248823a6@hsinnreich2> 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henry Sinnreich wrote: > Is there any service provider planning to use SIP-DIAMETER? If yes, > please speak up. Any of the 3G operators count for this? I'm not sure how many of the subscribe to this group though, even if their vendors do... Jari _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 21 00:24:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09970 for ; Fri, 21 Feb 2003 00:24:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1L5UUb13846 for sipping-archive@odin.ietf.org; Fri, 21 Feb 2003 00:30:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L5UUp13843 for ; Fri, 21 Feb 2003 00:30:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09939 for ; Fri, 21 Feb 2003 00:23:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L5Ttp13802; Fri, 21 Feb 2003 00:29:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L5SCp13755 for ; Fri, 21 Feb 2003 00:28:12 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09868 for ; Fri, 21 Feb 2003 00:20:46 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.36 #1 (Debian)) id 18m5fX-0005hN-00; Fri, 21 Feb 2003 07:24:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15957.47107.736309.266260@harjus.eng.song.fi> Date: Fri, 21 Feb 2003 07:24:19 +0200 To: jari.arkko@piuha.net Cc: Henry Sinnreich , "'Stuart Jacobs'" , "'Allison Mankin'" , sipping@ietf.org, Henning Schulzrinne Subject: Re: [Sipping] New version of the SIP-AAA reqs draft In-Reply-To: <3E556C0D.6060403@piuha.net> References: <005e01c2d93a$2cdbd450$248823a6@hsinnreich2> <3E556C0D.6060403@piuha.net> X-Mailer: VM 7.07 under Emacs 21.2.1 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jari Arkko writes: > Henry Sinnreich wrote: > > Is there any service provider planning to use SIP-DIAMETER? If yes, > > please speak up. > > Any of the 3G operators count for this? I'm not sure how many > of the subscribe to this group though, even if their vendors > do... it depends. will the vendors really give 3g operators a free choice which diameter server they want to use in their 3g network? which diameter servers has nokia tested interoperability against? does any of these servers come from non-3g vendors? or is the use of diameter in 3g networks similar fake as use of sip in 3g im? -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 21 04:05:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23803 for ; Fri, 21 Feb 2003 04:05:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1L9CTM06172 for sipping-archive@odin.ietf.org; Fri, 21 Feb 2003 04:12:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L9CTp06169 for ; Fri, 21 Feb 2003 04:12:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23797 for ; Fri, 21 Feb 2003 04:04:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L98Wp05949; Fri, 21 Feb 2003 04:08:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L97lp05914 for ; Fri, 21 Feb 2003 04:07:47 -0500 Received: from p2.piuha.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23613 for ; Fri, 21 Feb 2003 04:00:17 -0500 (EST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id CFDEC6A902; Fri, 21 Feb 2003 11:04:06 +0200 (EET) Message-ID: <3E55EB63.7080605@piuha.net> Date: Fri, 21 Feb 2003 11:03:31 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jh@lohi.eng.song.fi Cc: "'John Loughney'" , sipping@ietf.org Subject: Re: [Sipping] New version of the SIP-AAA reqs draft References: <005e01c2d93a$2cdbd450$248823a6@hsinnreich2> <3E556C0D.6060403@piuha.net> <15957.47107.736309.266260@harjus.eng.song.fi> 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit jh@lohi.eng.song.fi wrote: > Jari Arkko writes: > > > Henry Sinnreich wrote: > > > Is there any service provider planning to use SIP-DIAMETER? If yes, > > > please speak up. > > > > Any of the 3G operators count for this? I'm not sure how many > > of the subscribe to this group though, even if their vendors > > do... > > it depends. will the vendors really give 3g operators a free choice > which diameter server they want to use in their 3g network? which I'm not quite sure what you mean by free choice in this context, but perhaps you are after standardized interfaces? These would be publicly available in the form of RFCs (eg DIAMETER base) and 3G specifications on how DIAMETER is used for multimedia application. > diameter servers has nokia tested interoperability against? does any of I don't know but there's been Diameter interoperability events. Perhaps you John could dig up the Nokia information from those if you participated? I know Ericsson particpated at least. > these servers come from non-3g vendors? or is the use of diameter in 3g > networks similar fake as use of sip in 3g im? The question was if anyone was going to deploy and I answered ;-) I don't fully agree with the way 3G sets up their AAA. But we are discussing the creation of an IETF standard for SIP AAA. 3G folks had to create a multimedia AAA application because the IETF does not have one. My opinion is that we need an IETF standard in this space, so that the 3G folks, SIP vendor groups, or other parties don't all diverge on how to do this. IMHO, this is really crucial for SIP. My belief is also that the IETF standard will be better than any of these groups could do themselves. As far as 3G goes, my understanding was that they are happy to switch to an IETF standard when it becomes available. Jari _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 21 09:47:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01710 for ; Fri, 21 Feb 2003 09:47:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LEsKu27748 for sipping-archive@odin.ietf.org; Fri, 21 Feb 2003 09:54:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LEsKp27744 for ; Fri, 21 Feb 2003 09:54:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01696 for ; Fri, 21 Feb 2003 09:46:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LEqGp27674; Fri, 21 Feb 2003 09:52:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LEpip27654 for ; Fri, 21 Feb 2003 09:51:44 -0500 Received: from dgesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01650 for ; Fri, 21 Feb 2003 09:44:08 -0500 (EST) Received: from dgismtp05.wcomnet.com ([166.38.58.88]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0HAN0015MYCQ39@firewall.wcom.com> for sipping@ietf.org; Fri, 21 Feb 2003 14:46:02 +0000 (GMT) Received: from dgismtp05.wcomnet.com by dgismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HAN00001YCOJX@dgismtp05.wcomnet.com>; Fri, 21 Feb 2003 14:46:02 +0000 (GMT) Received: from hsinnreich2 ([166.35.136.36]) by dgismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HAN00M6SYCLCJ@dgismtp05.wcomnet.com>; Fri, 21 Feb 2003 14:46:00 +0000 (GMT) Date: Fri, 21 Feb 2003 08:45:57 -0600 From: Henry Sinnreich Subject: RE: [Sipping] New version of the SIP-AAA reqs draft In-reply-to: <3E55EB63.7080605@piuha.net> To: jari.arkko@piuha.net, jh@lohi.eng.song.fi Cc: "'John Loughney'" , sipping@ietf.org Message-id: <000601c2d9b7$f397a740$248823a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > Any of the 3G operators count for this? I'm not sure how many > > of the subscribe to this group though, even if their vendors > > do... I doubt any service providers will agree vendors are entitled to speak for them, wired or wireless. The service providers on this list have given solid arguments why we prefer RADIUS at present. As for what comes beyond RADIUS, we have the OSP token I-D http://www.ietf.org/internet-drafts/draft-johnston-sip-osp-token-04.txt and the IETF work at http://www.aaaarch.org/charter.html DIAMETER is just too little, too late IMHO, when looking at the options in these links. Question: Has anyone predetermined in SIPPING that DIAMETER good for service providers? Interesting... Thanks, Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of Jari Arkko > Sent: Friday, February 21, 2003 3:04 AM > To: jh@lohi.eng.song.fi > Cc: 'John Loughney'; sipping@ietf.org > Subject: Re: [Sipping] New version of the SIP-AAA reqs draft > > > jh@lohi.eng.song.fi wrote: > > Jari Arkko writes: > > > > > Henry Sinnreich wrote: > > > > Is there any service provider planning to use SIP-DIAMETER? If > > yes, > > please speak up. > > > > Any of the 3G operators count for this? I'm not sure how many > > > of the subscribe to this group though, even if their vendors > > > do... > > > > it depends. will the vendors really give 3g operators a > free choice > > which diameter server they want to use in their 3g network? which > > I'm not quite sure what you mean by free choice in this > context, but perhaps you are after standardized interfaces? > These would be publicly available in the form of RFCs (eg > DIAMETER base) and 3G specifications on how DIAMETER is used > for multimedia application. > > > diameter servers has nokia tested interoperability against? > does any > > of > > I don't know but there's been Diameter interoperability > events. Perhaps you John could dig up the Nokia information > from those if you participated? I know Ericsson particpated at least. > > > these servers come from non-3g vendors? or is the use of > diameter in > > 3g networks similar fake as use of sip in 3g im? > > The question was if anyone was going to deploy and I answered ;-) > > I don't fully agree with the way 3G sets up their AAA. But we > are discussing the creation of an IETF standard for SIP AAA. > 3G folks had to create a multimedia AAA application because > the IETF does not have one. My opinion is that we need an > IETF standard in this space, so that the 3G folks, SIP vendor > groups, or other parties don't all diverge on how to do this. > IMHO, this is really crucial for SIP. My belief is also that > the IETF standard will be better than any of these groups > could do themselves. As far as 3G goes, my understanding was > that they are happy to switch to an IETF standard when it > becomes available. > > Jari > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 mailnull@www1.ietf.org Fri Feb 21 10:18:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03067 for ; Fri, 21 Feb 2003 10:18:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LFP6q30142 for sipping-archive@odin.ietf.org; Fri, 21 Feb 2003 10:25:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LFP6p30139 for ; Fri, 21 Feb 2003 10:25:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03043 for ; Fri, 21 Feb 2003 10:17:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LFORp30078; Fri, 21 Feb 2003 10:24:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LFJsp29849 for ; Fri, 21 Feb 2003 10:19:54 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02851 for ; Fri, 21 Feb 2003 10:12:16 -0500 (EST) From: marco.stura@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1LFEr226951 for ; Fri, 21 Feb 2003 17:14:53 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 21 Feb 2003 17:16:06 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 21 Feb 2003 17:16:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] New version of the SIP-AAA reqs draft Date: Fri, 21 Feb 2003 17:16:04 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D9E44C5@esebe016.ntc.nokia.com> Thread-Topic: [Sipping] New version of the SIP-AAA reqs draft Thread-Index: AcLZuUcRpsrKqWCnQUePCzlBzm9ULAAAJKDQ To: , , Cc: , X-OriginalArrivalTime: 21 Feb 2003 15:16:05.0097 (UTC) FILETIME=[26FCB590:01C2D9BC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1LFJsp29850 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, > I doubt any service providers will agree vendors are entitled to speak > for them, wired or wireless. I guess Jari was not speaking on behalf of wireless operators, rather He was just reporting what has been standardized in 3GPP by both vendors and operators i.e. AAA for IP multimedia services based on Diameter. Consequently 3G wireless service providers will deploy Diameter. I guess an IETF standard on SIP-AAA based on Diameter is needed to avoid divergent solutions across multiple networks, which perhaps end up in interoperability problems. Best Regards Marco > -----Original Message----- > From: ext Henry Sinnreich [mailto:Henry.Sinnreich@wcom.com] > Sent: 21 February, 2003 16:46 > To: jari.arkko@piuha.net; jh@lohi.eng.song.fi > Cc: Loughney John (NRC/Helsinki); sipping@ietf.org > Subject: RE: [Sipping] New version of the SIP-AAA reqs draft > > > > > Any of the 3G operators count for this? I'm not sure how many > > > of the subscribe to this group though, even if their vendors > > > do... > > I doubt any service providers will agree vendors are entitled to speak > for them, wired or wireless. The service providers on this list have > given solid arguments why we prefer RADIUS at present. As for > what comes > beyond RADIUS, we have the OSP token I-D > > http://www.ietf.org/internet-drafts/draft-johnston-sip-osp-tok > en-04.txt > > and the IETF work at > > http://www.aaaarch.org/charter.html > > DIAMETER is just too little, too late IMHO, when looking at > the options > in these links. > > Question: Has anyone predetermined in SIPPING that DIAMETER good for > service providers? Interesting... > > Thanks, Henry > > > > > -----Original Message----- > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > On Behalf Of Jari Arkko > > Sent: Friday, February 21, 2003 3:04 AM > > To: jh@lohi.eng.song.fi > > Cc: 'John Loughney'; sipping@ietf.org > > Subject: Re: [Sipping] New version of the SIP-AAA reqs draft > > > > > > jh@lohi.eng.song.fi wrote: > > > Jari Arkko writes: > > > > > > > Henry Sinnreich wrote: > > > > > Is there any service provider planning to use > SIP-DIAMETER? If > > > yes, > > please speak up. > > > > > Any of the 3G operators count for this? I'm not sure how many > > > > of the subscribe to this group though, even if their vendors > > > > do... > > > > > > it depends. will the vendors really give 3g operators a > > free choice > > > which diameter server they want to use in their 3g network? which > > > > I'm not quite sure what you mean by free choice in this > > context, but perhaps you are after standardized interfaces? > > These would be publicly available in the form of RFCs (eg > > DIAMETER base) and 3G specifications on how DIAMETER is used > > for multimedia application. > > > > > diameter servers has nokia tested interoperability against? > > does any > > > of > > > > I don't know but there's been Diameter interoperability > > events. Perhaps you John could dig up the Nokia information > > from those if you participated? I know Ericsson particpated > at least. > > > > > these servers come from non-3g vendors? or is the use of > > diameter in > > > 3g networks similar fake as use of sip in 3g im? > > > > The question was if anyone was going to deploy and I answered ;-) > > > > I don't fully agree with the way 3G sets up their AAA. But we > > are discussing the creation of an IETF standard for SIP AAA. > > 3G folks had to create a multimedia AAA application because > > the IETF does not have one. My opinion is that we need an > > IETF standard in this space, so that the 3G folks, SIP vendor > > groups, or other parties don't all diverge on how to do this. > > IMHO, this is really crucial for SIP. My belief is also that > > the IETF standard will be better than any of these groups > > could do themselves. As far as 3G goes, my understanding was > > that they are happy to switch to an IETF standard when it > > becomes available. > > > > Jari > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the 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 mailnull@www1.ietf.org Fri Feb 21 10:34:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03704 for ; Fri, 21 Feb 2003 10:34:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LFfro31790 for sipping-archive@odin.ietf.org; Fri, 21 Feb 2003 10:41:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LFfrp31787 for ; Fri, 21 Feb 2003 10:41:53 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03695 for ; Fri, 21 Feb 2003 10:34:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LFf9p31756; Fri, 21 Feb 2003 10:41:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LFeQp31692 for ; Fri, 21 Feb 2003 10:40:26 -0500 Received: from pmesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03649 for ; Fri, 21 Feb 2003 10:32:47 -0500 (EST) Received: from dgismtp06.wcomnet.com ([166.38.58.89]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0HAO00GGE0P2SG@firewall.wcom.com> for sipping@ietf.org; Fri, 21 Feb 2003 15:36:39 +0000 (GMT) Received: from dgismtp06.wcomnet.com by dgismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HAO00N010P23M@dgismtp06.wcomnet.com>; Fri, 21 Feb 2003 15:36:38 +0000 (GMT) Received: from hsinnreich2 ([166.35.136.36]) by dgismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HAO00M4V0P2QT@dgismtp06.wcomnet.com>; Fri, 21 Feb 2003 15:36:38 +0000 (GMT) Date: Fri, 21 Feb 2003 09:36:38 -0600 From: Henry Sinnreich Subject: RE: [Sipping] New version of the SIP-AAA reqs draft In-reply-to: <142DC466081D9B409AAD1DDCA4B21E1D9E44C5@esebe016.ntc.nokia.com> To: marco.stura@nokia.com, jari.arkko@piuha.net, jh@lohi.eng.song.fi Cc: john.loughney@nokia.com, sipping@ietf.org, Henning Schulzrinne Message-id: <000001c2d9bf$06308820$248823a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Diameter is needed to avoid divergent solutions across > multiple networks, which perhaps end up in interoperability problems. Yes, DIAMETER will be divergent with the existing RADIUS base serving 100's of millions Internet users. That's why we should make http://www.watersprings.org/pub/id/draft-schulzrinne-sipping-radius-acco unting-00.txt and http://www.watersprings.org/pub/id/draft-byerly-sip-radius-00.txt should be the first WG design items. Henry > -----Original Message----- > From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] > Sent: Friday, February 21, 2003 9:16 AM > To: Henry.Sinnreich@wcom.com; jari.arkko@piuha.net; > jh@lohi.eng.song.fi > Cc: john.loughney@nokia.com; sipping@ietf.org > Subject: RE: [Sipping] New version of the SIP-AAA reqs draft > > > Hi, > > > I doubt any service providers will agree vendors are > entitled to speak > > for them, wired or wireless. > > I guess Jari was not speaking on behalf of wireless > operators, rather He was just reporting what has been > standardized in 3GPP by both vendors and operators i.e. AAA > for IP multimedia services based on Diameter. > > Consequently 3G wireless service providers will deploy > Diameter. I guess an IETF standard on SIP-AAA based on > Diameter is needed to avoid divergent solutions across > multiple networks, which perhaps end up in interoperability problems. > > Best Regards > Marco > > > -----Original Message----- > > From: ext Henry Sinnreich [mailto:Henry.Sinnreich@wcom.com] > > Sent: 21 February, 2003 16:46 > > To: jari.arkko@piuha.net; jh@lohi.eng.song.fi > > Cc: Loughney John (NRC/Helsinki); sipping@ietf.org > > Subject: RE: [Sipping] New version of the SIP-AAA reqs draft > > > > > > > > Any of the 3G operators count for this? I'm not sure > how many > > > > of the subscribe to this group though, even if their vendors > > > > do... > > > > I doubt any service providers will agree vendors are > entitled to speak > > for them, wired or wireless. The service providers on this > list have > > given solid arguments why we prefer RADIUS at present. As for what > > comes beyond RADIUS, we have the OSP token I-D > > > > http://www.ietf.org/internet-drafts/draft-johnston-sip-osp-tok > > en-04.txt > > > > and the IETF work at > > > > http://www.aaaarch.org/charter.html > > > > DIAMETER is just too little, too late IMHO, when looking at > > the options > > in these links. > > > > Question: Has anyone predetermined in SIPPING that DIAMETER > good for > > service providers? Interesting... > > > > Thanks, Henry > > > > > > > > > -----Original Message----- > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > > On Behalf Of Jari Arkko > > > Sent: Friday, February 21, 2003 3:04 AM > > > To: jh@lohi.eng.song.fi > > > Cc: 'John Loughney'; sipping@ietf.org > > > Subject: Re: [Sipping] New version of the SIP-AAA reqs draft > > > > > > > > > jh@lohi.eng.song.fi wrote: > > > > Jari Arkko writes: > > > > > > > > > Henry Sinnreich wrote: > > > > > > Is there any service provider planning to use > > SIP-DIAMETER? If > > > > yes, > > please speak up. > > > > > > Any of the 3G operators count for this? I'm not sure > how many > > > > > of the subscribe to this group though, even if their > vendors > > > > > do... > > > > > > > > it depends. will the vendors really give 3g operators a > > > free choice > > > > which diameter server they want to use in their 3g > network? which > > > > > > I'm not quite sure what you mean by free choice in this > > > context, but perhaps you are after standardized interfaces? > > > These would be publicly available in the form of RFCs (eg > > > DIAMETER base) and 3G specifications on how DIAMETER is used > > > for multimedia application. > > > > > > > diameter servers has nokia tested interoperability against? > > > does any > > > > of > > > > > > I don't know but there's been Diameter interoperability > > > events. Perhaps you John could dig up the Nokia information > > > from those if you participated? I know Ericsson particpated > > at least. > > > > > > > these servers come from non-3g vendors? or is the use of > > > diameter in > > > > 3g networks similar fake as use of sip in 3g im? > > > > > > The question was if anyone was going to deploy and I answered ;-) > > > > > > I don't fully agree with the way 3G sets up their AAA. But we > > > are discussing the creation of an IETF standard for SIP AAA. > > > 3G folks had to create a multimedia AAA application because > > > the IETF does not have one. My opinion is that we need an > > > IETF standard in this space, so that the 3G folks, SIP vendor > > > groups, or other parties don't all diverge on how to do this. > > > IMHO, this is really crucial for SIP. My belief is also that > > > the IETF standard will be better than any of these groups > > > could do themselves. As far as 3G goes, my understanding was > > > that they are happy to switch to an IETF standard when it > > > becomes available. > > > > > > Jari > > > > > > _______________________________________________ > > > Sipping mailing list > https://www1.ietf.org/mailman/listi> nfo/sipping > > > This list > is for NEW development of the > 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 mailnull@www1.ietf.org Fri Feb 21 10:40:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03867 for ; Fri, 21 Feb 2003 10:40:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LFleF32044 for sipping-archive@odin.ietf.org; Fri, 21 Feb 2003 10:47:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LFlep32041 for ; Fri, 21 Feb 2003 10:47:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03855 for ; Fri, 21 Feb 2003 10:40:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LFl5p32029; Fri, 21 Feb 2003 10:47:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LFknp32000 for ; Fri, 21 Feb 2003 10:46:49 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03831 for ; Fri, 21 Feb 2003 10:39:10 -0500 (EST) From: marco.stura@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1LFfm212696 for ; Fri, 21 Feb 2003 17:41:48 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 21 Feb 2003 17:43:00 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 21 Feb 2003 17:43:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] New version of the SIP-AAA reqs draft Date: Fri, 21 Feb 2003 17:43:00 +0200 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C7958@esebe016.ntc.nokia.com> Thread-Topic: [Sipping] New version of the SIP-AAA reqs draft Thread-Index: AcLZvwfTOmi9oL5EShyg8wjYIJ7wPQAAGF5Q To: , , Cc: , , X-OriginalArrivalTime: 21 Feb 2003 15:43:00.0693 (UTC) FILETIME=[E9F51850:01C2D9BF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1LFknp32001 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > Yes, DIAMETER will be divergent with the existing RADIUS base serving > 100's of millions Internet users. Yes, but RADIUS will be divergent with the wireless environment currently serving 700's millions of GSM/GPRS users. That's why we should make Diameter base AAA-SIP solution with special care to RADIUS interoperability. Br Marco > -----Original Message----- > From: ext Henry Sinnreich [mailto:Henry.Sinnreich@wcom.com] > Sent: 21 February, 2003 17:37 > To: Stura Marco (NET/Helsinki); jari.arkko@piuha.net; > jh@lohi.eng.song.fi > Cc: Loughney John (NRC/Helsinki); sipping@ietf.org; Henning > Schulzrinne > Subject: RE: [Sipping] New version of the SIP-AAA reqs draft > > > > Diameter is needed to avoid divergent solutions across > > multiple networks, which perhaps end up in interoperability > problems. > > Yes, DIAMETER will be divergent with the existing RADIUS base serving > 100's of millions Internet users. > > That's why we should make > > http://www.watersprings.org/pub/id/draft-schulzrinne-sipping-r > adius-acco > unting-00.txt > > and > > http://www.watersprings.org/pub/id/draft-byerly-sip-radius-00.txt > > should be the first WG design items. > > Henry > > > -----Original Message----- > > From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] > > Sent: Friday, February 21, 2003 9:16 AM > > To: Henry.Sinnreich@wcom.com; jari.arkko@piuha.net; > > jh@lohi.eng.song.fi > > Cc: john.loughney@nokia.com; sipping@ietf.org > > Subject: RE: [Sipping] New version of the SIP-AAA reqs draft > > > > > > Hi, > > > > > I doubt any service providers will agree vendors are > > entitled to speak > > > for them, wired or wireless. > > > > I guess Jari was not speaking on behalf of wireless > > operators, rather He was just reporting what has been > > standardized in 3GPP by both vendors and operators i.e. AAA > > for IP multimedia services based on Diameter. > > > > Consequently 3G wireless service providers will deploy > > Diameter. I guess an IETF standard on SIP-AAA based on > > Diameter is needed to avoid divergent solutions across > > multiple networks, which perhaps end up in interoperability > problems. > > > > Best Regards > > Marco > > > > > -----Original Message----- > > > From: ext Henry Sinnreich [mailto:Henry.Sinnreich@wcom.com] > > > Sent: 21 February, 2003 16:46 > > > To: jari.arkko@piuha.net; jh@lohi.eng.song.fi > > > Cc: Loughney John (NRC/Helsinki); sipping@ietf.org > > > Subject: RE: [Sipping] New version of the SIP-AAA reqs draft > > > > > > > > > > > Any of the 3G operators count for this? I'm not sure > > how many > > > > > of the subscribe to this group though, even if their vendors > > > > > do... > > > > > > I doubt any service providers will agree vendors are > > entitled to speak > > > for them, wired or wireless. The service providers on this > > list have > > > given solid arguments why we prefer RADIUS at present. As > for what > > > comes beyond RADIUS, we have the OSP token I-D > > > > > > http://www.ietf.org/internet-drafts/draft-johnston-sip-osp-tok > > > en-04.txt > > > > > > and the IETF work at > > > > > > http://www.aaaarch.org/charter.html > > > > > > DIAMETER is just too little, too late IMHO, when looking at > > > the options > > > in these links. > > > > > > Question: Has anyone predetermined in SIPPING that DIAMETER > > good for > > > service providers? Interesting... > > > > > > Thanks, Henry > > > > > > > > > > > > > -----Original Message----- > > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > > > On Behalf Of Jari Arkko > > > > Sent: Friday, February 21, 2003 3:04 AM > > > > To: jh@lohi.eng.song.fi > > > > Cc: 'John Loughney'; sipping@ietf.org > > > > Subject: Re: [Sipping] New version of the SIP-AAA reqs draft > > > > > > > > > > > > jh@lohi.eng.song.fi wrote: > > > > > Jari Arkko writes: > > > > > > > > > > > Henry Sinnreich wrote: > > > > > > > Is there any service provider planning to use > > > SIP-DIAMETER? If > > > > > yes, > > please speak up. > > > > > > > Any of the 3G operators count for this? I'm not sure > > how many > > > > > > of the subscribe to this group though, even if their > > vendors > > > > > > do... > > > > > > > > > > it depends. will the vendors really give 3g operators a > > > > free choice > > > > > which diameter server they want to use in their 3g > > network? which > > > > > > > > I'm not quite sure what you mean by free choice in this > > > > context, but perhaps you are after standardized interfaces? > > > > These would be publicly available in the form of RFCs (eg > > > > DIAMETER base) and 3G specifications on how DIAMETER is used > > > > for multimedia application. > > > > > > > > > diameter servers has nokia tested interoperability against? > > > > does any > > > > > of > > > > > > > > I don't know but there's been Diameter interoperability > > > > events. Perhaps you John could dig up the Nokia information > > > > from those if you participated? I know Ericsson particpated > > > at least. > > > > > > > > > these servers come from non-3g vendors? or is the use of > > > > diameter in > > > > > 3g networks similar fake as use of sip in 3g im? > > > > > > > > The question was if anyone was going to deploy and I > answered ;-) > > > > > > > > I don't fully agree with the way 3G sets up their AAA. But we > > > > are discussing the creation of an IETF standard for SIP AAA. > > > > 3G folks had to create a multimedia AAA application because > > > > the IETF does not have one. My opinion is that we need an > > > > IETF standard in this space, so that the 3G folks, SIP vendor > > > > groups, or other parties don't all diverge on how to do this. > > > > IMHO, this is really crucial for SIP. My belief is also that > > > > the IETF standard will be better than any of these groups > > > > could do themselves. As far as 3G goes, my understanding was > > > > that they are happy to switch to an IETF standard when it > > > > becomes available. > > > > > > > > Jari > > > > > > > > _______________________________________________ > > > > Sipping mailing list > > https://www1.ietf.org/mailman/listi> nfo/sipping > > > > This list > > is for NEW development of the > > 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 mailnull@www1.ietf.org Fri Feb 21 11:23:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05466 for ; Fri, 21 Feb 2003 11:23:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LGUSv02407 for sipping-archive@odin.ietf.org; Fri, 21 Feb 2003 11:30:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LGUSp02404 for ; Fri, 21 Feb 2003 11:30:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05458 for ; Fri, 21 Feb 2003 11:22:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LGTlp02371; Fri, 21 Feb 2003 11:29:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LGSZp02337 for ; Fri, 21 Feb 2003 11:28:35 -0500 Received: from ihemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05428 for ; Fri, 21 Feb 2003 11:20:56 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1LGOkR24588 for ; Fri, 21 Feb 2003 11:24:47 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Feb 2003 16:24:42 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EBFF@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Henry Sinnreich'" Cc: sipping@ietf.org Subject: RE: [Sipping] New version of the SIP-AAA reqs draft Date: Fri, 21 Feb 2003 16:24:40 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Henry, you seem to have reached the point where you have totally confused two questions that ought to be taken independently. 1) Should IETF specify RADIUS for use with SIP. This is apparently what you want. It is not required by the operators or vendors represented in 3GPP, but nobody from 3GPP is telling you not to do it. 2) Should IETF specify DIAMETER for use with SIP. That decision to use DIAMETER in association with SIP has been made in 3GPP in an open forum for all 3GPP interested vendors and operators, and that decision is well known throughout the industry. Those decisions are documented in meeting reports from 3GPP SA2, CN4, SA and CN, and specified in approved 3GPP specifications all of which are publically available. If you wish to change that decision, then by all means join 3GPP and make the appropriate proposal. To the best of my knowledge nobody has suggested that RADIUS is even suitable for use in the 3GPP environment here (despite RADIUS already appearing elsewhere in the 3GPP architecture), and IMS cannot be deployed without these capabilities. Further, while 3GPP release 5 uses proprietary extensions to DIAMETER to provide service codes (these are provided in an informational RFC), 3GPP has undertaken to replace these in release 6 with an IETF worked proposal. If IETF does n! ot do that work (with appropriate 3GPP support), then 3GPP cannot meet that agreement. Therefore from a 3GPP perspective the point is that for question 1, we have no position and for question 2, we need the work from IETF in order to complete agreements we have already made with IETF. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Henry Sinnreich [mailto:Henry.Sinnreich@wcom.com] > Sent: 21 February 2003 14:46 > To: jari.arkko@piuha.net; jh@lohi.eng.song.fi > Cc: 'John Loughney'; sipping@ietf.org > Subject: RE: [Sipping] New version of the SIP-AAA reqs draft > > > > > Any of the 3G operators count for this? I'm not sure how many > > > of the subscribe to this group though, even if their vendors > > > do... > > I doubt any service providers will agree vendors are entitled to speak > for them, wired or wireless. The service providers on this list have > given solid arguments why we prefer RADIUS at present. As for > what comes > beyond RADIUS, we have the OSP token I-D > > http://www.ietf.org/internet-drafts/draft-johnston-sip-osp-tok > en-04.txt > > and the IETF work at > > http://www.aaaarch.org/charter.html > > DIAMETER is just too little, too late IMHO, when looking at > the options > in these links. > > Question: Has anyone predetermined in SIPPING that DIAMETER good for > service providers? Interesting... > > Thanks, Henry > > > > > -----Original Message----- > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > On Behalf Of Jari Arkko > > Sent: Friday, February 21, 2003 3:04 AM > > To: jh@lohi.eng.song.fi > > Cc: 'John Loughney'; sipping@ietf.org > > Subject: Re: [Sipping] New version of the SIP-AAA reqs draft > > > > > > jh@lohi.eng.song.fi wrote: > > > Jari Arkko writes: > > > > > > > Henry Sinnreich wrote: > > > > > Is there any service provider planning to use > SIP-DIAMETER? If > > > yes, > > please speak up. > > > > > Any of the 3G operators count for this? I'm not sure how many > > > > of the subscribe to this group though, even if their vendors > > > > do... > > > > > > it depends. will the vendors really give 3g operators a > > free choice > > > which diameter server they want to use in their 3g network? which > > > > I'm not quite sure what you mean by free choice in this > > context, but perhaps you are after standardized interfaces? > > These would be publicly available in the form of RFCs (eg > > DIAMETER base) and 3G specifications on how DIAMETER is used > > for multimedia application. > > > > > diameter servers has nokia tested interoperability against? > > does any > > > of > > > > I don't know but there's been Diameter interoperability > > events. Perhaps you John could dig up the Nokia information > > from those if you participated? I know Ericsson particpated > at least. > > > > > these servers come from non-3g vendors? or is the use of > > diameter in > > > 3g networks similar fake as use of sip in 3g im? > > > > The question was if anyone was going to deploy and I answered ;-) > > > > I don't fully agree with the way 3G sets up their AAA. But we > > are discussing the creation of an IETF standard for SIP AAA. > > 3G folks had to create a multimedia AAA application because > > the IETF does not have one. My opinion is that we need an > > IETF standard in this space, so that the 3G folks, SIP vendor > > groups, or other parties don't all diverge on how to do this. > > IMHO, this is really crucial for SIP. My belief is also that > > the IETF standard will be better than any of these groups > > could do themselves. As far as 3G goes, my understanding was > > that they are happy to switch to an IETF standard when it > > becomes available. > > > > Jari > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the 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 mailnull@www1.ietf.org Fri Feb 21 11:34:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05795 for ; Fri, 21 Feb 2003 11:34:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LGfEd03556 for sipping-archive@odin.ietf.org; Fri, 21 Feb 2003 11:41:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LGfEp03553 for ; Fri, 21 Feb 2003 11:41:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05785 for ; Fri, 21 Feb 2003 11:33:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LGeTp03521; Fri, 21 Feb 2003 11:40:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LGdKp03448 for ; Fri, 21 Feb 2003 11:39:20 -0500 Received: from rautu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05727 for ; Fri, 21 Feb 2003 11:31:37 -0500 (EST) Received: from jh by rautu with local (Exim 3.35 #1 (Debian)) id 18mHzV-00007i-00; Fri, 21 Feb 2003 20:33:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15958.28925.93722.773942@lohi.eng.song.fi> Date: Fri, 21 Feb 2003 20:33:33 +0200 To: Cc: , , , Subject: RE: [Sipping] New version of the SIP-AAA reqs draft In-Reply-To: <142DC466081D9B409AAD1DDCA4B21E1D9E44C5@esebe016.ntc.nokia.com> References: <142DC466081D9B409AAD1DDCA4B21E1D9E44C5@esebe016.ntc.nokia.com> X-Mailer: VM 7.07 under Emacs 21.2.1 From: Juha Heinanen Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit marco.stura@nokia.com writes: > Consequently 3G wireless service providers will deploy Diameter. that is fine with me although i'm not sure what the walled garden of 3gpp im has to do with this working group. > I guess an IETF standard on SIP-AAA based on Diameter is needed to avoid > divergent solutions across multiple networks, which perhaps end up > in interoperability problems. other operators than 3g are already using radius for sip aaa and this cannot be ignored by this working group. we and many others are using radius authentication according to the sterman draft are very happy with it. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 21 11:53:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06628 for ; Fri, 21 Feb 2003 11:53:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LH0Pb04238 for sipping-archive@odin.ietf.org; Fri, 21 Feb 2003 12:00:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LH0Pp04235 for ; Fri, 21 Feb 2003 12:00:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06615 for ; Fri, 21 Feb 2003 11:52:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LGxVp04181; Fri, 21 Feb 2003 11:59:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LGwlp04151 for ; Fri, 21 Feb 2003 11:58:47 -0500 Received: from pmesmtp01.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06583 for ; Fri, 21 Feb 2003 11:51:07 -0500 (EST) Received: from pmismtp06.wcomnet.com ([166.38.62.54]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HAO00GDD44NQ9@firewall.wcom.com> for sipping@ietf.org; Fri, 21 Feb 2003 16:50:47 +0000 (GMT) Received: from pmismtp06.wcomnet.com by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HAO00E014280N@pmismtp06.wcomnet.com>; Fri, 21 Feb 2003 16:50:47 +0000 (GMT) Received: from hsinnreich2 ([166.35.136.36]) by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HAO00E0M449AO@pmismtp06.wcomnet.com>; Fri, 21 Feb 2003 16:50:34 +0000 (GMT) Date: Fri, 21 Feb 2003 10:50:33 -0600 From: Henry Sinnreich Subject: RE: [Sipping] New version of the SIP-AAA reqs draft In-reply-to: <475FF955A05DD411980D00508B6D5FB00439EBFF@en0033exch001u.uk.lucent.com> To: "'Drage, Keith (Keith)'" Cc: sipping@ietf.org Message-id: <000001c2d9c9$5a186fc0$248823a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Keith, the confusion stems from the fact: Why if 3GPP has decided on DIAMETER, this should not be treated in the WG as all the other "p" labels for SIP used by 3GPP? No problem with what 3GPP folks decide, but that should be labeled "p" (standing here for proprietary, private and I bet, also for provisional, since I don't believe 3GPP operetors will not eventually deploy some form of web services XML etc. for AAA). As for quoting 3GPP SA2, CN4, SA and CN, we could equally qoute T1, etc. The world is bigger than the 3GPP universe :-) Henry > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Friday, February 21, 2003 10:25 AM > To: 'Henry Sinnreich' > Cc: sipping@ietf.org > Subject: RE: [Sipping] New version of the SIP-AAA reqs draft > > > Henry, you seem to have reached the point where you have > totally confused two questions that ought to be taken independently. > > 1) Should IETF specify RADIUS for use with SIP. This is > apparently what you want. It is not required by the operators > or vendors represented in 3GPP, but nobody from 3GPP is > telling you not to do it. > > 2) Should IETF specify DIAMETER for use with SIP. That > decision to use DIAMETER in association with SIP has been > made in 3GPP in an open forum for all 3GPP interested vendors > and operators, and that decision is well known throughout the > industry. Those decisions are documented in meeting reports > from 3GPP SA2, CN4, SA and CN, and specified in approved 3GPP > specifications all of which are publically available. If you > wish to change that decision, then by all means join 3GPP and > make the appropriate proposal. To the best of my knowledge > nobody has suggested that RADIUS is even suitable for use in > the 3GPP environment here (despite RADIUS already appearing > elsewhere in the 3GPP architecture), and IMS cannot be > deployed without these capabilities. Further, while 3GPP > release 5 uses proprietary extensions to DIAMETER to provide > service codes (these are provided in an informational RFC), > 3GPP has undertaken to replace these in release 6 with an > IETF worked proposal. If IETF does n! > ot do that work (with appropriate 3GPP support), then 3GPP > cannot meet that agreement. > > Therefore from a 3GPP perspective the point is that for > question 1, we have no position and for question 2, we need > the work from IETF in order to complete agreements we have > already made with IETF. > > Keith > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > > -----Original Message----- > > From: Henry Sinnreich [mailto:Henry.Sinnreich@wcom.com] > > Sent: 21 February 2003 14:46 > > To: jari.arkko@piuha.net; jh@lohi.eng.song.fi > > Cc: 'John Loughney'; sipping@ietf.org > > Subject: RE: [Sipping] New version of the SIP-AAA reqs draft > > > > > > > > Any of the 3G operators count for this? I'm not sure > how many > > > > of the subscribe to this group though, even if their vendors > > > > do... > > > > I doubt any service providers will agree vendors are > entitled to speak > > for them, wired or wireless. The service providers on this > list have > > given solid arguments why we prefer RADIUS at present. As for what > > comes beyond RADIUS, we have the OSP token I-D > > > > http://www.ietf.org/internet-drafts/draft-johnston-sip-osp-tok > > en-04.txt > > > > and the IETF work at > > > > http://www.aaaarch.org/charter.html > > > > DIAMETER is just too little, too late IMHO, when looking at > > the options > > in these links. > > > > Question: Has anyone predetermined in SIPPING that DIAMETER > good for > > service providers? Interesting... > > > > Thanks, Henry > > > > > > > > > -----Original Message----- > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > > On Behalf Of Jari Arkko > > > Sent: Friday, February 21, 2003 3:04 AM > > > To: jh@lohi.eng.song.fi > > > Cc: 'John Loughney'; sipping@ietf.org > > > Subject: Re: [Sipping] New version of the SIP-AAA reqs draft > > > > > > > > > jh@lohi.eng.song.fi wrote: > > > > Jari Arkko writes: > > > > > > > > > Henry Sinnreich wrote: > > > > > > Is there any service provider planning to use > > SIP-DIAMETER? If > > > > yes, > > please speak up. > > > > > > Any of the 3G operators count for this? I'm not sure > how many > > > > > of the subscribe to this group though, even if their > vendors > > > > > do... > > > > > > > > it depends. will the vendors really give 3g operators a > > > free choice > > > > which diameter server they want to use in their 3g > network? which > > > > > > I'm not quite sure what you mean by free choice in this > > > context, but perhaps you are after standardized interfaces? > > > These would be publicly available in the form of RFCs (eg > > > DIAMETER base) and 3G specifications on how DIAMETER is used > > > for multimedia application. > > > > > > > diameter servers has nokia tested interoperability against? > > > does any > > > > of > > > > > > I don't know but there's been Diameter interoperability > > > events. Perhaps you John could dig up the Nokia information > > > from those if you participated? I know Ericsson particpated > > at least. > > > > > > > these servers come from non-3g vendors? or is the use of > > > diameter in > > > > 3g networks similar fake as use of sip in 3g im? > > > > > > The question was if anyone was going to deploy and I answered ;-) > > > > > > I don't fully agree with the way 3G sets up their AAA. But we > > > are discussing the creation of an IETF standard for SIP AAA. > > > 3G folks had to create a multimedia AAA application because > > > the IETF does not have one. My opinion is that we need an > > > IETF standard in this space, so that the 3G folks, SIP vendor > > > groups, or other parties don't all diverge on how to do this. > > > IMHO, this is really crucial for SIP. My belief is also that > > > the IETF standard will be better than any of these groups > > > could do themselves. As far as 3G goes, my understanding was > > > that they are happy to switch to an IETF standard when it > > > becomes available. > > > > > > Jari > > > > > > _______________________________________________ > > > Sipping mailing list > https://www1.ietf.org/mailman/listi> nfo/sipping > > > This list > is for NEW development of the > 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 mailnull@www1.ietf.org Fri Feb 21 12:13:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07277 for ; Fri, 21 Feb 2003 12:13:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LHKmU06183 for sipping-archive@odin.ietf.org; Fri, 21 Feb 2003 12:20:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LHKmp06180 for ; Fri, 21 Feb 2003 12:20:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07271 for ; Fri, 21 Feb 2003 12:13:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LHKDp06161; Fri, 21 Feb 2003 12:20:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LHJIp06087 for ; Fri, 21 Feb 2003 12:19:18 -0500 Received: from rautu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07247 for ; Fri, 21 Feb 2003 12:11:34 -0500 (EST) Received: from jh by rautu with local (Exim 3.35 #1 (Debian)) id 18mIdG-0000BZ-00 for ; Fri, 21 Feb 2003 21:14:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15958.31368.133191.629532@lohi.eng.song.fi> Date: Fri, 21 Feb 2003 21:14:16 +0200 To: sipping@ietf.org Subject: RE: [Sipping] New version of the SIP-AAA reqs draft In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439EBFF@en0033exch001u.uk.lucent\.com> References: <475FF955A05DD411980D00508B6D5FB00439EBFF@en0033exch001u.uk.lucent.\com> X-Mailer: VM 7.07 under Emacs 21.2.1 From: Juha Heinanen Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit just to add to henry's list ofdrafts, this is what many open source and commercial radius servers and sip proxies support for digest authentication with sip and which is in use by several sip providers: ftp://lohi.eng.song.fi/tmp/draft-sterman-aaa-sip-00.txt (the directory is not listable). -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 21 12:24:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07731 for ; Fri, 21 Feb 2003 12:24:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LHVC706711 for sipping-archive@odin.ietf.org; Fri, 21 Feb 2003 12:31:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LHVCp06708 for ; Fri, 21 Feb 2003 12:31:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07726 for ; Fri, 21 Feb 2003 12:23:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LHURp06647; Fri, 21 Feb 2003 12:30:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LHTip06585 for ; Fri, 21 Feb 2003 12:29:44 -0500 Received: from rautu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07663 for ; Fri, 21 Feb 2003 12:21:58 -0500 (EST) Received: from jh by rautu with local (Exim 3.35 #1 (Debian)) id 18mIj3-0000Be-00 for ; Fri, 21 Feb 2003 21:20:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15958.31721.103701.159222@lohi.eng.song.fi> Date: Fri, 21 Feb 2003 21:20:09 +0200 To: sipping@ietf.org X-Mailer: VM 7.03 under Emacs 21.2.1 From: Juha Heinanen Content-Transfer-Encoding: 7bit Subject: [Sipping] is there a way to authenticate bye? Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit related to sip aaa requirements, is there a way to figure out that a bye that terminates a session/dialog was sent by a local user that the proxy is responsible for (and thus should be authenticated by the proxy)? if the matching invite was originated by a non-local user, the to and from headers may not tell anything about the matter. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 21 12:46:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08661 for ; Fri, 21 Feb 2003 12:46:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LHs7t08349 for sipping-archive@odin.ietf.org; Fri, 21 Feb 2003 12:54:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LHs7p08345 for ; Fri, 21 Feb 2003 12:54:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08640 for ; Fri, 21 Feb 2003 12:46:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LHrDp08309; Fri, 21 Feb 2003 12:53:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LHqAp08261 for ; Fri, 21 Feb 2003 12:52:10 -0500 Received: from auemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08531 for ; Fri, 21 Feb 2003 12:44:28 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1LHmId16686 for ; Fri, 21 Feb 2003 12:48:19 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Feb 2003 17:48:17 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EC00@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Henry Sinnreich'" Cc: sipping@ietf.org Subject: RE: [Sipping] New version of the SIP-AAA reqs draft Date: Fri, 21 Feb 2003 17:48:16 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , If DIAMETER was a 3GPP protocol, then treating the work with the same status as P-headers would be a perfectly valid statement, but DIAMETER is an approved IETF protocol as draft standard currently sitting in the RFC editors queue and therefore is on the same IETF standards track as RADIUS. Further, DIAMETER was chosen by 3GPP because RADIUS does not meet the 3GPP requirements for that particular interface. Available implementations comes secondary to those requirements (after all 3GPP have specified RFC 3261 rather than RFC 2543 and there are not many deployed implementations of that either). What you appear to be saying is that DIAMETER should not have been created in the first place (presumably with a view that RADIUS should have been enhanced to deal with its shortcomings). That is an issue you must take up with the IESG and the WG responsible, not try and blame 3GPP for it. And finally to reiterate the point of my previous mail, 3GPP is asking IETF to provide DIAMETER support. In my view, that has zero impact on whether RADIUS is done as well. The input that work should not be done on RADIUS is coming from within the IETF, and is nothing to do with 3GPP. Keith P.S. I cannot quote T1 yet because the release 5 specifications have not yet been endorsed by the SDOs, of which T1 is one (that stage in the process will occur shortly). And the reason for quoting those groups was not to say that my group is better that yours, it was to make clear that the choice of DIAMETER is well known in 3GPP (and therefore by the nature of the 3G market by all operators deploying 3GPP) by publically available information from those groups. Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Henry Sinnreich [mailto:Henry.Sinnreich@wcom.com] > Sent: 21 February 2003 16:51 > To: 'Drage, Keith (Keith)' > Cc: sipping@ietf.org > Subject: RE: [Sipping] New version of the SIP-AAA reqs draft > > > Keith, the confusion stems from the fact: Why if 3GPP has decided on > DIAMETER, this should not be treated in the WG as all the other "p" > labels for SIP used by 3GPP? No problem with what 3GPP folks > decide, but > that should be labeled "p" (standing here for proprietary, > private and I > bet, also for provisional, since I don't believe 3GPP > operetors will not > eventually deploy some form of web services XML etc. for AAA). > > As for quoting 3GPP SA2, CN4, SA and CN, we could equally > qoute T1, etc. > The world is bigger than the 3GPP universe :-) > > Henry > > > -----Original Message----- > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > Sent: Friday, February 21, 2003 10:25 AM > > To: 'Henry Sinnreich' > > Cc: sipping@ietf.org > > Subject: RE: [Sipping] New version of the SIP-AAA reqs draft > > > > > > Henry, you seem to have reached the point where you have > > totally confused two questions that ought to be taken independently. > > > > 1) Should IETF specify RADIUS for use with SIP. This is > > apparently what you want. It is not required by the operators > > or vendors represented in 3GPP, but nobody from 3GPP is > > telling you not to do it. > > > > 2) Should IETF specify DIAMETER for use with SIP. That > > decision to use DIAMETER in association with SIP has been > > made in 3GPP in an open forum for all 3GPP interested vendors > > and operators, and that decision is well known throughout the > > industry. Those decisions are documented in meeting reports > > from 3GPP SA2, CN4, SA and CN, and specified in approved 3GPP > > specifications all of which are publically available. If you > > wish to change that decision, then by all means join 3GPP and > > make the appropriate proposal. To the best of my knowledge > > nobody has suggested that RADIUS is even suitable for use in > > the 3GPP environment here (despite RADIUS already appearing > > elsewhere in the 3GPP architecture), and IMS cannot be > > deployed without these capabilities. Further, while 3GPP > > release 5 uses proprietary extensions to DIAMETER to provide > > service codes (these are provided in an informational RFC), > > 3GPP has undertaken to replace these in release 6 with an > > IETF worked proposal. If IETF does n! > > ot do that work (with appropriate 3GPP support), then 3GPP > > cannot meet that agreement. > > > > Therefore from a 3GPP perspective the point is that for > > question 1, we have no position and for question 2, we need > > the work from IETF in order to complete agreements we have > > already made with IETF. > > > > Keith > > > > Keith Drage > > Lucent Technologies > > Tel: +44 1793 776249 > > Email: drage@lucent.com > > > > > -----Original Message----- > > > From: Henry Sinnreich [mailto:Henry.Sinnreich@wcom.com] > > > Sent: 21 February 2003 14:46 > > > To: jari.arkko@piuha.net; jh@lohi.eng.song.fi > > > Cc: 'John Loughney'; sipping@ietf.org > > > Subject: RE: [Sipping] New version of the SIP-AAA reqs draft > > > > > > > > > > > Any of the 3G operators count for this? I'm not sure > > how many > > > > > of the subscribe to this group though, even if their vendors > > > > > do... > > > > > > I doubt any service providers will agree vendors are > > entitled to speak > > > for them, wired or wireless. The service providers on this > > list have > > > given solid arguments why we prefer RADIUS at present. As > for what > > > comes beyond RADIUS, we have the OSP token I-D > > > > > > http://www.ietf.org/internet-drafts/draft-johnston-sip-osp-tok > > > en-04.txt > > > > > > and the IETF work at > > > > > > http://www.aaaarch.org/charter.html > > > > > > DIAMETER is just too little, too late IMHO, when looking at > > > the options > > > in these links. > > > > > > Question: Has anyone predetermined in SIPPING that DIAMETER > > good for > > > service providers? Interesting... > > > > > > Thanks, Henry > > > > > > > > > > > > > -----Original Message----- > > > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > > > > On Behalf Of Jari Arkko > > > > Sent: Friday, February 21, 2003 3:04 AM > > > > To: jh@lohi.eng.song.fi > > > > Cc: 'John Loughney'; sipping@ietf.org > > > > Subject: Re: [Sipping] New version of the SIP-AAA reqs draft > > > > > > > > > > > > jh@lohi.eng.song.fi wrote: > > > > > Jari Arkko writes: > > > > > > > > > > > Henry Sinnreich wrote: > > > > > > > Is there any service provider planning to use > > > SIP-DIAMETER? If > > > > > yes, > > please speak up. > > > > > > > Any of the 3G operators count for this? I'm not sure > > how many > > > > > > of the subscribe to this group though, even if their > > vendors > > > > > > do... > > > > > > > > > > it depends. will the vendors really give 3g operators a > > > > free choice > > > > > which diameter server they want to use in their 3g > > network? which > > > > > > > > I'm not quite sure what you mean by free choice in this > > > > context, but perhaps you are after standardized interfaces? > > > > These would be publicly available in the form of RFCs (eg > > > > DIAMETER base) and 3G specifications on how DIAMETER is used > > > > for multimedia application. > > > > > > > > > diameter servers has nokia tested interoperability against? > > > > does any > > > > > of > > > > > > > > I don't know but there's been Diameter interoperability > > > > events. Perhaps you John could dig up the Nokia information > > > > from those if you participated? I know Ericsson particpated > > > at least. > > > > > > > > > these servers come from non-3g vendors? or is the use of > > > > diameter in > > > > > 3g networks similar fake as use of sip in 3g im? > > > > > > > > The question was if anyone was going to deploy and I > answered ;-) > > > > > > > > I don't fully agree with the way 3G sets up their AAA. But we > > > > are discussing the creation of an IETF standard for SIP AAA. > > > > 3G folks had to create a multimedia AAA application because > > > > the IETF does not have one. My opinion is that we need an > > > > IETF standard in this space, so that the 3G folks, SIP vendor > > > > groups, or other parties don't all diverge on how to do this. > > > > IMHO, this is really crucial for SIP. My belief is also that > > > > the IETF standard will be better than any of these groups > > > > could do themselves. As far as 3G goes, my understanding was > > > > that they are happy to switch to an IETF standard when it > > > > becomes available. > > > > > > > > Jari > > > > > > > > _______________________________________________ > > > > Sipping mailing list > > https://www1.ietf.org/mailman/listi> nfo/sipping > > > > This list > > is for NEW development of the > > 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 mailnull@www1.ietf.org Fri Feb 21 13:01:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09285 for ; Fri, 21 Feb 2003 13:01:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LI92s09672 for sipping-archive@odin.ietf.org; Fri, 21 Feb 2003 13:09:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LI92p09669 for ; Fri, 21 Feb 2003 13:09:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09265 for ; Fri, 21 Feb 2003 13:01:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LI8Bp09612; Fri, 21 Feb 2003 13:08:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LI7Ip09243 for ; Fri, 21 Feb 2003 13:07:18 -0500 Received: from dgesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09206 for ; Fri, 21 Feb 2003 12:59:36 -0500 (EST) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0HAO0066G7GD52@firewall.wcom.com> for sipping@ietf.org; Fri, 21 Feb 2003 18:02:37 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HAO009017G8GK@dgismtp01.wcomnet.com>; Fri, 21 Feb 2003 18:02:37 +0000 (GMT) Received: from hsinnreich2 ([166.35.136.36]) by dgismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HAO0092S7GB5N@dgismtp01.wcomnet.com>; Fri, 21 Feb 2003 18:02:35 +0000 (GMT) Date: Fri, 21 Feb 2003 12:02:34 -0600 From: Henry Sinnreich Subject: RE: [Sipping] New version of the SIP-AAA reqs draft In-reply-to: <475FF955A05DD411980D00508B6D5FB00439EC00@en0033exch001u.uk.lucent.com> To: "'Drage, Keith (Keith)'" Cc: sipping@ietf.org Message-id: <000701c2d9d3$69895550$248823a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > What you appear to be saying is that DIAMETER should not have > been created in the first place (presumably with a view that > RADIUS should have been enhanced to deal with its > shortcomings). That is an issue you must take up with the > IESG and the WG responsible, not try and blame 3GPP for it. On this we can agree. 3GPP is not the problem for us. DIAMETER is. Henry > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Friday, February 21, 2003 11:48 AM > To: 'Henry Sinnreich' > Cc: sipping@ietf.org > Subject: RE: [Sipping] New version of the SIP-AAA reqs draft > > > If DIAMETER was a 3GPP protocol, then treating the work with > the same status as P-headers would be a perfectly valid > statement, but DIAMETER is an approved IETF protocol as draft > standard currently sitting in the RFC editors queue and > therefore is on the same IETF standards track as RADIUS. > > Further, DIAMETER was chosen by 3GPP because RADIUS does not > meet the 3GPP requirements for that particular interface. > Available implementations comes secondary to those > requirements (after all 3GPP have specified RFC 3261 rather > than RFC 2543 and there are not many deployed implementations > of that either). > > What you appear to be saying is that DIAMETER should not have > been created in the first place (presumably with a view that > RADIUS should have been enhanced to deal with its > shortcomings). That is an issue you must take up with the > IESG and the WG responsible, not try and blame 3GPP for it. > > And finally to reiterate the point of my previous mail, 3GPP > is asking IETF to provide DIAMETER support. In my view, that > has zero impact on whether RADIUS is done as well. The input > that work should not be done on RADIUS is coming from within > the IETF, and is nothing to do with 3GPP. > > Keith > > P.S. I cannot quote T1 yet because the release 5 > specifications have not yet been endorsed by the SDOs, of > which T1 is one (that stage in the process will occur > shortly). And the reason for quoting those groups was not to > say that my group is better that yours, it was to make clear > that the choice of DIAMETER is well known in 3GPP (and > therefore by the nature of the 3G market by all operators > deploying 3GPP) by publically available information from those groups. > > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > > -----Original Message----- > > From: Henry Sinnreich [mailto:Henry.Sinnreich@wcom.com] > > Sent: 21 February 2003 16:51 > > To: 'Drage, Keith (Keith)' > > Cc: sipping@ietf.org > > Subject: RE: [Sipping] New version of the SIP-AAA reqs draft > > > > > > Keith, the confusion stems from the fact: Why if 3GPP has > decided on > > DIAMETER, this should not be treated in the WG as all the other "p" > > labels for SIP used by 3GPP? No problem with what 3GPP > folks decide, > > but that should be labeled "p" (standing here for proprietary, > > private and I > > bet, also for provisional, since I don't believe 3GPP > > operetors will not > > eventually deploy some form of web services XML etc. for AAA). > > > > As for quoting 3GPP SA2, CN4, SA and CN, we could equally > > qoute T1, etc. > > The world is bigger than the 3GPP universe :-) > > > > Henry > > > > > -----Original Message----- > > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > > Sent: Friday, February 21, 2003 10:25 AM > > > To: 'Henry Sinnreich' > > > Cc: sipping@ietf.org > > > Subject: RE: [Sipping] New version of the SIP-AAA reqs draft > > > > > > > > > Henry, you seem to have reached the point where you have > > > totally confused two questions that ought to be taken > independently. > > > > > > 1) Should IETF specify RADIUS for use with SIP. This is > > > apparently what you want. It is not required by the operators > > > or vendors represented in 3GPP, but nobody from 3GPP is > > > telling you not to do it. > > > > > > 2) Should IETF specify DIAMETER for use with SIP. That > > > decision to use DIAMETER in association with SIP has been > > > made in 3GPP in an open forum for all 3GPP interested vendors > > > and operators, and that decision is well known throughout the > > > industry. Those decisions are documented in meeting reports > > > from 3GPP SA2, CN4, SA and CN, and specified in approved 3GPP > > > specifications all of which are publically available. If you > > > wish to change that decision, then by all means join 3GPP and > > > make the appropriate proposal. To the best of my knowledge > > > nobody has suggested that RADIUS is even suitable for use in > > > the 3GPP environment here (despite RADIUS already appearing > > > elsewhere in the 3GPP architecture), and IMS cannot be > > > deployed without these capabilities. Further, while 3GPP > > > release 5 uses proprietary extensions to DIAMETER to provide > > > service codes (these are provided in an informational RFC), > > > 3GPP has undertaken to replace these in release 6 with an > > > IETF worked proposal. If IETF does n! > > > ot do that work (with appropriate 3GPP support), then 3GPP > > > cannot meet that agreement. > > > > > > Therefore from a 3GPP perspective the point is that for > > > question 1, we have no position and for question 2, we need > > > the work from IETF in order to complete agreements we have > > > already made with IETF. > > > > > > Keith > > > > > > Keith Drage > > > Lucent Technologies > > > Tel: +44 1793 776249 > > > Email: drage@lucent.com > > > > > > > -----Original Message----- > > > > From: Henry Sinnreich [mailto:Henry.Sinnreich@wcom.com] > > > > Sent: 21 February 2003 14:46 > > > > To: jari.arkko@piuha.net; jh@lohi.eng.song.fi > > > > Cc: 'John Loughney'; sipping@ietf.org > > > > Subject: RE: [Sipping] New version of the SIP-AAA reqs draft > > > > > > > > > > > > > > Any of the 3G operators count for this? I'm not sure > > > how many > > > > > > of the subscribe to this group though, even if their > vendors > > > > > > do... > > > > > > > > I doubt any service providers will agree vendors are > > > entitled to speak > > > > for them, wired or wireless. The service providers on this > > > list have > > > > given solid arguments why we prefer RADIUS at present. As > > for what > > > > comes beyond RADIUS, we have the OSP token I-D > > > > > > > > http://www.ietf.org/internet-drafts/draft-johnston-sip-osp-tok > > > > en-04.txt > > > > > > > > and the IETF work at > > > > > > > > http://www.aaaarch.org/charter.html > > > > > > > > DIAMETER is just too little, too late IMHO, when looking at the > > > > options in these links. > > > > > > > > Question: Has anyone predetermined in SIPPING that DIAMETER > > > good for > > > > service providers? Interesting... > > > > > > > > Thanks, Henry > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: sipping-admin@ietf.org > [mailto:sipping-admin@ietf.org] On > > > > > Behalf Of Jari Arkko > > > > > Sent: Friday, February 21, 2003 3:04 AM > > > > > To: jh@lohi.eng.song.fi > > > > > Cc: 'John Loughney'; sipping@ietf.org > > > > > Subject: Re: [Sipping] New version of the SIP-AAA reqs draft > > > > > > > > > > > > > > > jh@lohi.eng.song.fi wrote: > > > > > > Jari Arkko writes: > > > > > > > > > > > > > Henry Sinnreich wrote: > > > > > > > > Is there any service provider planning to use > > > > SIP-DIAMETER? If > > > > > > yes, > > please speak up. > > > > > > > > Any of the 3G operators count for this? I'm not sure > > > how many > > > > > > > of the subscribe to this group though, even if their > > > vendors > > > > > > > do... > > > > > > > > > > > > it depends. will the vendors really give 3g operators a > > > > > free choice > > > > > > which diameter server they want to use in their 3g > > > network? which > > > > > > > > > > I'm not quite sure what you mean by free choice in > this context, > > > > > but perhaps you are after standardized interfaces? > These would > > > > > be publicly available in the form of RFCs (eg > DIAMETER base) and > > > > > 3G specifications on how DIAMETER is used for multimedia > > > > > application. > > > > > > > > > > > diameter servers has nokia tested interoperability against? > > > > > does any > > > > > > of > > > > > > > > > > I don't know but there's been Diameter > interoperability events. > > > > > Perhaps you John could dig up the Nokia information > from those > > > > > if you participated? I know Ericsson particpated > > > > at least. > > > > > > > > > > > these servers come from non-3g vendors? or is the use of > > > > > diameter in > > > > > > 3g networks similar fake as use of sip in 3g im? > > > > > > > > > > The question was if anyone was going to deploy and I > > answered ;-) > > > > > > > > > > I don't fully agree with the way 3G sets up their AAA. But we > > > > > are discussing the creation of an IETF standard for > SIP AAA. 3G > > > > > folks had to create a multimedia AAA application because the > > > > > IETF does not have one. My opinion is that we need an IETF > > > > > standard in this space, so that the 3G folks, SIP > vendor groups, > > > > > or other parties don't all diverge on how to do this. > IMHO, this > > > > > is really crucial for SIP. My belief is also that the IETF > > > > > standard will be better than any of these groups could do > > > > > themselves. As far as 3G goes, my understanding was that they > > > > > are happy to switch to an IETF standard when it becomes > > > > > available. > > > > > > > > > > Jari > > > > > > > > > > _______________________________________________ > > > > > Sipping mailing list > > > https://www1.ietf.org/mailman/listi> nfo/sipping > > > > > This list > > > is for NEW development of the > > > 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 mailnull@www1.ietf.org Fri Feb 21 13:16:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09699 for ; Fri, 21 Feb 2003 13:16:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LINUw10259 for sipping-archive@odin.ietf.org; Fri, 21 Feb 2003 13:23:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LINUp10256 for ; Fri, 21 Feb 2003 13:23:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09672 for ; Fri, 21 Feb 2003 13:15:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LIMsp10212; Fri, 21 Feb 2003 13:22:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LIHfp10003 for ; Fri, 21 Feb 2003 13:17:41 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09511 for ; Fri, 21 Feb 2003 13:09:59 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1LICb225794 for ; Fri, 21 Feb 2003 20:12:37 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 21 Feb 2003 20:13:49 +0200 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 21 Feb 2003 20:13:49 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 21 Feb 2003 20:13:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] New version of the SIP-AAA reqs draft Date: Fri, 21 Feb 2003 20:13:48 +0200 Message-ID: Thread-Topic: [Sipping] New version of the SIP-AAA reqs draft Thread-Index: AcLZ1J3rRqLGP2o8TFuXYIUoBN8YYAAAA0uw To: , Cc: X-OriginalArrivalTime: 21 Feb 2003 18:13:49.0011 (UTC) FILETIME=[FB2CDA30:01C2D9D4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1LIHfp10004 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Henry, > > What you appear to be saying is that DIAMETER should not have > > been created in the first place (presumably with a view that > > RADIUS should have been enhanced to deal with its > > shortcomings). That is an issue you must take up with the > > IESG and the WG responsible, not try and blame 3GPP for it. > > On this we can agree. 3GPP is not the problem for us. DIAMETER is. Do you have technical reasons for this? Diameter running in RADIUS compatability mode should allow NAS's and RADIUS servers to talk to Diameter servers. I understand your reasons for not wanting to upgrade everything to Diameter, but I still don't see what reasons you have for being dismissive of Diameter. br, 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 mailnull@www1.ietf.org Fri Feb 21 13:17:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09741 for ; Fri, 21 Feb 2003 13:17:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LIOkU10342 for sipping-archive@odin.ietf.org; Fri, 21 Feb 2003 13:24:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LIOkp10339 for ; Fri, 21 Feb 2003 13:24:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09732 for ; Fri, 21 Feb 2003 13:17:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LIO7p10327; Fri, 21 Feb 2003 13:24:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LINVp10276 for ; Fri, 21 Feb 2003 13:23:31 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09673 for ; Fri, 21 Feb 2003 13:15:48 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1LIMem17535 for ; Fri, 21 Feb 2003 20:22:40 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 21 Feb 2003 20:19:39 +0200 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 21 Feb 2003 20:19:39 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 21 Feb 2003 20:19:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 21 Feb 2003 20:19:38 +0200 Message-ID: Thread-Topic: [Sipping] New version of the SIP-AAA reqs draft Thread-Index: AcLZ1J3rRqLGP2o8TFuXYIUoBN8YYAAAF9fQ To: X-OriginalArrivalTime: 21 Feb 2003 18:19:38.0965 (UTC) FILETIME=[CBC39850:01C2D9D5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1LINVp10277 Subject: [Sipping] Attempted summary of SIP-AAA discussion Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi all, So, it seems that there are the following needs: 1) Compatability with existing RADIUS infrastructure. 2) Support for Diameter for the 3G community (I believe both 3GPP and 3GPP2 will be using Diameter). 3) Some vague handwaving about Web Services. It seems that there are some expired drafts on using RADIUS for at least 2 of the AA's in AAA. Expired drafts don't usually count for much, however. A way forward would be to have the authors of the expired drafts to update them and re-submit them. A solution sufficient for 3G is in the works, so I have heard. I have seen no concrete proposals for web services, so until I see one in a draft, I am going to discount it entirely. So, after all of the possible solutions are re-issued in draft form, probably the SIPPING WG chairs, AAA WG chairs and relevent IESG members could sort out how to go forward, perhaps forming a small team to make recommendations on how to procede. I would like to say that at present, the SIP-AAA interface is an unstandardized interface, so no matter what the final protoocl solution is, everyone want to support the standard will need to implement it from scatch, so backward compatability may not be a huge barrier, as long as there is some way to interwork with existing RADIUS servers and NASes. br, 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 mailnull@www1.ietf.org Fri Feb 21 13:27:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10001 for ; Fri, 21 Feb 2003 13:27:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LIYu310740 for sipping-archive@odin.ietf.org; Fri, 21 Feb 2003 13:34:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LIYup10737 for ; Fri, 21 Feb 2003 13:34:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09979 for ; Fri, 21 Feb 2003 13:27:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LIYKp10728; Fri, 21 Feb 2003 13:34:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LIXip10688 for ; Fri, 21 Feb 2003 13:33:44 -0500 Received: from auemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09963 for ; Fri, 21 Feb 2003 13:26:01 -0500 (EST) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1LITqd04206 for ; Fri, 21 Feb 2003 13:29:52 -0500 (EST) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19) id <1H3QJFWQ>; Fri, 21 Feb 2003 12:29:52 -0600 Message-ID: From: "Ejzak, Richard P (Richard)" To: "'Gonzalo Camarillo'" , sipping Subject: RE: [Sipping] New version of the early media draft Date: Fri, 21 Feb 2003 12:29:49 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Gonzalo, It seems the single greatest difficulty with the gateway model (as you point out in your draft) is the difficulty of depending on the arrival of media packets to determine whether or not to generate local ringing. I have previously (last summer) suggested a solution to this (use 180 exclusively to indicate that local ringing should override any inband media and 183 otherwise) that is unacceptable since it does not satisfy the requirement that 180 be used to indicate alerting of the called party. Have you considered using the Alert-Info header in the following way? Since the real problem is that we would like to be able to discriminate between cases when 180 should cause local ringing and when 180 should not (since inband media is available), and it is the UAS that knows conclusively which case applies, let's agree on an encoding of the Alert-Info header that indicates that local ringing should not be applied. The following line is a syntactically valid header: Alert-Info: This header identifies the Alert-Info as the null string, which seems unambiguously and efficiently interpretable within a 180 response as "do not play local ringing even though the called party is being alerted." If the UAC does not recognize it or chooses not to interpret it for security reasons, it can be safely ignored. This modest addition to your draft (or an equivalent mechanism) would make it unnecessary for the gateway model to depend on local policy or incoming media packet detection and is completely consistent with all of the constraints you have documented. Another approach may be to actually specify the rtp stream as the source of the alert info (although this would require the definition of a new URI scheme type). It might look like: Alert-Info: where the Alert-Info specifies the address and port of the rtp stream. I don't like this mechanism since it is redundant with SDP and prone to error. It is also ambiguous in the event of any subsequent media change using UPDATE (Do I begin to generate local ringing if the rtp stream source address changes? Or do I continue to listen to the address specified in the Alert-Info and ignore any UPDATEs? No to both.) May I suggest including such a mechanism (preferably the first one) in your draft. Richard Ejzak Lucent Technologies -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: Monday, February 10, 2003 5:41 AM To: sipping Subject: [Sipping] New version of the early media draft Folks, I have just sumitted a new version of the early media draft. Until it appears in the archives, you can fetch it from: http://standards.ericsson.net/gonzalo/papers/draft-camarillo-sipping-early-media-01.txt I have included all the (long and useful) discussions we had in the mailing list. Therefore, the draft now keeps separate the "gateway" and the "application server" models. I have also removed the parts we did not agree on. Feedback is, as usual, appreciated. Thanks, Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 21 14:59:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12818 for ; Fri, 21 Feb 2003 14:59:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LK6IU16646 for sipping-archive@odin.ietf.org; Fri, 21 Feb 2003 15:06:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LK6Ip16643 for ; Fri, 21 Feb 2003 15:06:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12809 for ; Fri, 21 Feb 2003 14:58:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LK5cp16569; Fri, 21 Feb 2003 15:05:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LK4Ap16470 for ; Fri, 21 Feb 2003 15:04:10 -0500 Received: from p2.piuha.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12740 for ; Fri, 21 Feb 2003 14:56:27 -0500 (EST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id CDE866A903; Fri, 21 Feb 2003 22:00:16 +0200 (EET) Message-ID: <3E56852C.6080800@piuha.net> Date: Fri, 21 Feb 2003 21:59:40 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: sipping@ietf.org Subject: Re: [Sipping] Attempted summary of SIP-AAA discussion 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thank you John for your summary. Let's stop the previous thread and continue with the technical discussion -- I think it was a fair question to ask who is going to deploy what, but it doesn't sound very productive to start arguing the details on who can speak for who, which deployment examples should not be counted, specific other SDO plans, etc. But back to the technical issues. I think the *needs* are discussed in the requirements document (which I think could still be improved *). The main solutions that have been proposed are RADIUS, DIAMETER, and Web Services. These solutions appear to be targeted at slightly different purposes, however, and I suspect this is the root cause of the argument. Do we just want a quick scheme to transport Digest authentication from a SIP server to a central authentication box? If yes, its very easy to explain why RADIUS looks so promising (even if there are folks who don't its security). Or do we want more, such as reliable accounting, ability for a server to perform "user de-authorization", ability to carry many pieces of information in standardized attributes, etc. (I think we want these things). RADIUS doesn't have these features and extending it to do them would result in something resembling DIAMETER so if you want any of this DIAMETER looks like a better solution. By the way, I continue to wonder why we need to have such a controversial debate when I suspect we might be able to cater to the needs of both groups. One possible idea is that the digest-carrying AAA protocol extension would be defined using RADIUS attributes in a manner which makes it possible run it over either basic RADIUS or DIAMETER NASREQ **). The remaining AAA functionality for SIP would be covered only in DIAMETER commands and AVPs, mainly because I suspect that it can't be done in RADIUS. Is this a potential compromise? Jari *) One thing that wasn't clear from the requirements specification was whether we expect to deal just with SIP proxies, or do we have support also end systems, such as some sort of a media server which not just runs SIP but also offers some function? **) Details to be worked out. One problem is that 3G folks might actually want to get session keys back from the authentication server as their auth methods generate these. Perhaps this part could only be supported in DIAMETER. RADIUS has key transport as well, but based on Microsoft's vendor specific attributes, which are pretty outdated at this point. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 21 15:46:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14258 for ; Fri, 21 Feb 2003 15:46:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LKs3F19977 for sipping-archive@odin.ietf.org; Fri, 21 Feb 2003 15:54:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LKs3p19974 for ; Fri, 21 Feb 2003 15:54:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14226 for ; Fri, 21 Feb 2003 15:46:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LKrSp19925; Fri, 21 Feb 2003 15:53:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LKqJp19864 for ; Fri, 21 Feb 2003 15:52:19 -0500 Received: from pmesmtp01.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14066 for ; Fri, 21 Feb 2003 15:44:36 -0500 (EST) Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HAO003CYEX5H0@firewall.wcom.com> for sipping@ietf.org; Fri, 21 Feb 2003 20:43:53 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HAO00B01EUV0U@dgismtp03.wcomnet.com>; Fri, 21 Feb 2003 20:43:53 +0000 (GMT) Received: from hsinnreich2 ([166.35.136.36]) by dgismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HAO00A50EWYOM@dgismtp03.wcomnet.com>; Fri, 21 Feb 2003 20:43:47 +0000 (GMT) Date: Fri, 21 Feb 2003 14:43:45 -0600 From: Henry Sinnreich Subject: RE: [Sipping] New version of the SIP-AAA reqs draft In-reply-to: To: john.loughney@nokia.com, drage@lucent.com Cc: sipping@ietf.org Message-id: <000001c2d9e9$edd0d9d0$248823a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I understand your reasons for not wanting to upgrade > everything to Diameter, but I still don't see what reasons > you have for being dismissive of Diameter. Thanks for clarifying the fact that we have two issues. The 2nd item, why DIAMETER is not the best option for NG: It is too little, too late. AAA is a natural part of e-commerce, that is of the web services architecture, as defined in W3C and numerous industry consortiums. It makes little sense for all the world to make payments and conduct transactions in the 'web services currency' and only phone calls to be paid in 'DIAMETER currency'. Actually two types of phones call 'currencies': Wired using RADIUS and mobile using DIAMETER. Not that DIAMETER is inherently evil or poorly engineered. It is just too little too late, when looking beyond RADIUS and its limitations. My two cents. I would see the design jobs therefore this way: 1-Near term: Use RADIUS-SIP to accommodate the huge isntalled base. The I-D's mentioned here. Including the OSP token for SIP. 2-Longer-term: The Web services architecture. It appears the present discussion stems from the fact that we only have volonteers for a DIAMETER-SIP draft. None of the mentioned RADIUS-SIP authors have volunteered any work here, and this is the problem. So unless the no RADIUS or web services volonteer steps up, we will have neither 1 nor 2. And this is not any fault of 3GPP :-) Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of john.loughney@nokia.com > Sent: Friday, February 21, 2003 12:14 PM > To: Henry.Sinnreich@wcom.com; drage@lucent.com > Cc: sipping@ietf.org > Subject: RE: [Sipping] New version of the SIP-AAA reqs draft > > > Henry, > > > > What you appear to be saying is that DIAMETER should not have been > > > created in the first place (presumably with a view that RADIUS > > > should have been enhanced to deal with its shortcomings). That is > > > an issue you must take up with the IESG and the WG responsible, > > > not try and blame 3GPP for it. > > > > On this we can agree. 3GPP is not the problem for us. DIAMETER is. > > Do you have technical reasons for this? Diameter running in > RADIUS compatability mode should allow NAS's and RADIUS > servers to talk to Diameter servers. > > I understand your reasons for not wanting to upgrade > everything to Diameter, but I still don't see what reasons > you have for being dismissive of Diameter. > > br, > 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 > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 21 15:53:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14518 for ; Fri, 21 Feb 2003 15:53:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LL0m820352 for sipping-archive@odin.ietf.org; Fri, 21 Feb 2003 16:00:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LL0lp20349 for ; Fri, 21 Feb 2003 16:00:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14494 for ; Fri, 21 Feb 2003 15:53:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LL07p20315; Fri, 21 Feb 2003 16:00:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LKxTp20213 for ; Fri, 21 Feb 2003 15:59:29 -0500 Received: from newman.gte.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14444 for ; Fri, 21 Feb 2003 15:51:44 -0500 (EST) Received: from rcmppc2.gte.com (rcmppc2.gte.com [132.197.73.30]) by newman.gte.com (8.9.1/8.9.1) with ESMTP id PAA15734; Fri, 21 Feb 2003 15:55:33 -0500 (EST) Message-Id: <5.1.1.6.0.20030221155434.04229170@bumail47.verizon.com> X-Sender: BA8CPQQ@bumail47.verizon.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 X-Priority: 1 (Highest) Date: Fri, 21 Feb 2003 15:55:55 -0500 To: Allison Mankin , sipping@ietf.org From: Stu Jacobs Subject: Re: [Sipping] New version of the SIP-AAA reqs draft Cc: sipping@ietf.org 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: , Allison, This material is part of ongoing efforts of Verizon and Verizon management to engage in thoughtful considerations of the fundamental changes and challenges facing the telecommunications industry. To meet its fiduciary responsibilities, management must explore all alternatives, even those that may appear highly speculative and hypothetical. Statements and representations contained herein are preliminary and/or tentative and should not be relied on unless approved by the appropriate Verizon governing body. The following represent the anticipated approach Verizon most likely will use. I cannot be more firm at this time as our architectural plans are not finalized. Verizon's current direction for our Next Generation Network (NGN) VoIP Services will likely use a challenge/response approach (ala. Radius) for authentication and access control between our SIP service customers and SIP Proxies. All our SIP service customers will probably go through SIP Proxies. We will not support SIP UA to SIP UA within our operational domain. Our SIP Proxies will likely authenticate themselves to other SIP Proxies and other back-office systems (OSSs, Application Servers, EMSs, etc.) by use of IPsec, specifically IKE combined with X.509v3 server certificates and ESP transport mode Null-encryption using HMAC-SHA1-96. Access controls (rights/policies) between our intermediate systems (incl. SIP Proxies, Gateways , etc.) are expected to be based on use of policy certificates. All policy and identity certificates are expected to be distributed via a redundant hierarchy of LDAP servers (repositories). Accounting data will most likely be compiled by our SIP Proxies and transferred to billing systems with authentication provided by IPsec. The actual billing data will probably be captured in the form of XML in conjunction with XML signatures (as defined by the W3C). Stu At 2/20/03 05:24 PM, you wrote: >Stu, > >You are not doing the usage accounting with Radius, then. > >It is only doing the remote access authentication? > >We can work with this scenario. Could you speak to this in >the open mailing list? I would like to rule out Radius for >call detail and usage-based accounting, but it is ok for the >other A's. > >Allison > > > Diameter in our Next Generation Network (NGN) VoIP Services. We will be > > doing our usage accounting within SIP Proxies and intend to transfer said > > accounting "call detail records" back to our billing OSSes via other > > protocols with IPsec providing authentication and confidentiality for > these > > transfers. We currently do not plan on any deployment of Diameter within > > Verizon's wireline NGN architecture. We will probably continue to use > > Radius for remote access authentication at the application layer for a > > number or years into the future. > > > > Stu Jacobs > > > > At 2/14/03 09:58 PM, you wrote: > > > > >Jiri, > > > > > >It always seems good to be able to stay with installed base, but > > >there's a factor against our supporting RADIUS drafts for SIP's > > >accounting - safety. Even though there is deployment, there are > > >some extremely bad cases of damage in production, and the IETF > > >has concluded that RADIUS is not suitable for usage-based accounting > > >(RFC2975). > > > > > >Unless there is no intention of having in SIP accounting usage-based, > > >monetary, auditable applications, RADIUS is not the solution. The > > >protocol just does not preserve a complete stream of reliable > > >accounting records that are auditable on any level, especially with > > >any roaming. As Bernard Aboba stated to this WG, quoting Mike O'Dell, > > >the use of RADIUS may even be illegal in situations where there is an > > >authority over the billing. Records are too easily lost by the > > >protocol. This is stated clearly by RFC2975. This is the reason why > > >the Operations and Mgt Area developed Diameter. On these technical* > > >grounds, that the RADIUS protocol does not have enough reliability, > > >the work must be based on the Diameter protocol, which is now > > >approved. Alternatively, work could be done that does not include > > >usage-based accounting, but this does not seem to be what is > > >envisioned in the SIPPING AAA requirements. > > > > > >Allison > > > > > >P.S. There's a current investigation of RADIUS compatibility mode > > >in Diameter for this - more needs to be thought about it. > > > > > > > > At 07:46 PM 2/11/2003, john.loughney@nokia.com wrote: > > > > >Hi Henry, > > > > > > > > > >> >but one option is develop a solution using > > > > >> > Diameter in RADIUS-compatibility mode. > > > > >> > > > > >> OK, this is better than nothing. We'll take what we can :-) > > > > >> > > > > >> As mentioned, the installed base is RADIUS, no matter how > > > > >> voluminous the DIAMETER literature may be. > > > > > > > > > >I think the issues is that the IETF should recommend what is the > > > > >right thing to do & why. If people choose to do something else, > > > > >well, that is life. > > > > > > > > Remember that running code does not necessarily mean something known > > > > to compile -- that is something known to be deployed. > > > > > > > > >I understand what you are asking but I do note that some > > > > >people have thought that the potential for AAA is much greater > > > > >than the existing installed base. > > > > > > > > I actually think that the deployment argument is a very important one. > > > > > > > > -Jiri > > > > > > > > _______________________________________________ > > > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > > > This list is for NEW development of the 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 > > > > ========================== > > Stuart Jacobs CISSP > > PMTS - Sr. Technologist > > Verizon Laboratories > > 40 Sylvan Road Waltham, MA 02451-1128 USA > > telephone: (781) 466-3076 fax: (781) 466-2838 > > stu.jacobs@labs.gte.com sjj0@labs.gte.com stu.jacobs@verizon.com > > ========================== > > ========================== Stuart Jacobs CISSP PMTS - Sr. Technologist Verizon Laboratories 40 Sylvan Road Waltham, MA 02451-1128 USA telephone: (781) 466-3076 fax: (781) 466-2838 stu.jacobs@labs.gte.com sjj0@labs.gte.com stu.jacobs@verizon.com ========================== ========================== Stuart Jacobs CISSP PMTS - Sr. Technologist Verizon Laboratories 40 Sylvan Road Waltham, MA 02451-1128 USA telephone: (781) 466-3076 fax: (781) 466-2838 stu.jacobs@labs.gte.com sjj0@labs.gte.com stu.jacobs@verizon.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 mailnull@www1.ietf.org Sat Feb 22 00:14:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24119 for ; Sat, 22 Feb 2003 00:14:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1M5LrC14695 for sipping-archive@odin.ietf.org; Sat, 22 Feb 2003 00:21:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1M5Lrp14692 for ; Sat, 22 Feb 2003 00:21:53 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24116 for ; Sat, 22 Feb 2003 00:13:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1M5LEp14673; Sat, 22 Feb 2003 00:21:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1M5J5p14582 for ; Sat, 22 Feb 2003 00:19:05 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24044 for ; Sat, 22 Feb 2003 00:11:10 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.36 #1 (Debian)) id 18mS05-0006so-00; Sat, 22 Feb 2003 07:15:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15959.1877.345459.352071@harjus.eng.song.fi> Date: Sat, 22 Feb 2003 07:15:01 +0200 To: john.loughney@nokia.com Cc: Subject: [Sipping] Attempted summary of SIP-AAA discussion In-Reply-To: References: X-Mailer: VM 7.07 under Emacs 21.2.1 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit john.loughney@nokia.com writes: > It seems that there are some expired drafts on using > RADIUS for at least 2 of the AA's in AAA. Expired > drafts don't usually count for much, however. what counts is that there are several implementations of the sterman draft (both servers and proxies), which are in active use by sip service providers. > A way forward would be to have the authors of the expired > drafts to update them and re-submit them. i have asked the athors of the sterman draft to re-submit it, but for some reason they have not done so. perhaps running code is enough for them. > I would like to say that at present, the SIP-AAA interface > is an unstandardized interface, so no matter what the > final protoocl solution is, everyone want to support the > standard will need to implement it from scatch, so backward > compatability may not be a huge barrier, as long as there > is some way to interwork with existing RADIUS servers and > NASes. if sterman draft becomes an rfc, there is no need to re-implement anything for digest authentication. i agree that accounting requires more work. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sat Feb 22 00:18:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24157 for ; Sat, 22 Feb 2003 00:18:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1M5PZX14817 for sipping-archive@odin.ietf.org; Sat, 22 Feb 2003 00:25:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1M5PZp14814 for ; Sat, 22 Feb 2003 00:25:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24152 for ; Sat, 22 Feb 2003 00:17:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1M5P4p14801; Sat, 22 Feb 2003 00:25:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1M5Opp14765 for ; Sat, 22 Feb 2003 00:24:51 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24144 for ; Sat, 22 Feb 2003 00:16:56 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.36 #1 (Debian)) id 18mS5f-0006t8-00; Sat, 22 Feb 2003 07:20:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15959.2223.178334.9501@harjus.eng.song.fi> Date: Sat, 22 Feb 2003 07:20:47 +0200 To: john.loughney@nokia.com Cc: , , Subject: RE: [Sipping] New version of the SIP-AAA reqs draft In-Reply-To: References: X-Mailer: VM 7.07 under Emacs 21.2.1 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit john.loughney@nokia.com writes: > I understand your reasons for not wanting to upgrade everything > to Diameter, but I still don't see what reasons you have for > being dismissive of Diameter. henry may have points why he doesn't like diameter, but for me, it is nto really that big deal IF diameter AAA infrastructure some day becomes wide spread. today, however, that is not the case. instead everybody is using radius as the protocol between NASes (includifn sip proxies) and AAA servers and also between AAA servers themselves. examples of the latter are gric and ipass, which provide roaming service for hundreds of isps literally all over the world. if radius is so bad that what you say IESG claims, i don't understand how this is possible. the roaming services run radius over ipsec which solves the security issues. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sat Feb 22 01:55:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26248 for ; Sat, 22 Feb 2003 01:55:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1M73N519063 for sipping-archive@odin.ietf.org; Sat, 22 Feb 2003 02:03:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1M73Mp19060 for ; Sat, 22 Feb 2003 02:03:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26245 for ; Sat, 22 Feb 2003 01:55:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1M72bp18969; Sat, 22 Feb 2003 02:02:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1M71vp18802 for ; Sat, 22 Feb 2003 02:01:57 -0500 Received: from india-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26242 for ; Sat, 22 Feb 2003 01:53:57 -0500 (EST) Received: from cbin3-mira-01.cisco.com (localhost [127.0.0.1]) by india-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h1MCQLd2002421 for ; Sat, 22 Feb 2003 12:26:21 GMT Received: from SHAJW2K ([64.104.137.27]) by cbin3-mira-01.cisco.com (Mirapoint) with ESMTP id AEO04186; Sat, 22 Feb 2003 12:20:44 +0530 (IST) Reply-To: From: "Shiva" To: Date: Sat, 22 Feb 2003 12:27:46 +0530 Organization: Cisco Systems Message-ID: <000401c2da3f$b4644460$1b896840@apac.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C2DA6D.CE1C8060" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: [Sipping] Comments on draft-rosenberg-sipping-conferencing-framework-01.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C2DA6D.CE1C8060 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, Overall the draft looks good. Here are some of my comments on this draft The idea of having a unique URI for each conference is a good one. However a more scalable approach would be to have a master Focus or a group of them that register with a standard URI. This way users use a standard URI with a Conference ID as the payload in the Invite message. This is directed to the master Focus that does the following * Retrieve the Conference ID * Check if a Focus corresponding to the conference exists * If the Conference specific Focus does not exist create a new Focus with a unique URI derived from the Conference ID * Forward the call using the standard Refer mechanism to the new Focus with the Unique URI. The advantage of doing this is that I could have multiple Conference servers that are running that are registered their master focus. We can implement Load Balancing across Conference servers without the UA realizing it as it is not connecting to a specific Focus on a specific server. A second advantage is that if in the course of a meeting if the focus were to go down or the server went down the participants can attempt to rejoin the call. In such a case the Master Focus would see that the Conference specific focus is down and recreate it allowing users to quickly rejoin the conference. Of course one needs to work out the details of the communication and keepalive between the Master Focus and the Conference focus it creates. The other advantage is if there are global Conference policies these can be applied at the master and the Individual Conference focus needs to worry about the specifics of the conference it is dealing with. The other comment was in the area of the Conference policy control protocol. Is this something like the SDP which is carried as a payload in SIP or does it have specifics of it's own. Currently most of the operations that are part of the CPCP are also possible through SIP based mechanisms. Is there a need to define two parallel mechanisms within the same framework. Instead of dealing with Conference aware UA's and Conference Unaware UA's we could assume all participants in the Conference to be Conference Aware. The Conference Unaware participants are routed through a Gateway (e.g. an IVR ) that provides a primitive interface to the conference unaware participants and a Conference aware interface to the Conference itself. This would keep the model simpler and it can allow Conference aware UAs a way to control the conference. Regards Shiva Cisco Systems ------=_NextPart_000_0005_01C2DA6D.CE1C8060 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hello,
 
Overall the=20 draft looks good.  Here are some of my comments on this draft
 
The idea of having a unique URI = for each=20 conference is a good one. However a more scalable approach would be to=20 have a master Focus or a group of them that register with a = standard=20 URI. This way users use a standard URI with a Conference ID as the = payload=20 in the Invite message.  This is directed to the = master Focus=20 that does the following
* = Retrieve the=20 Conference ID
* = Check if a=20 Focus corresponding to the conference exists
* If = the Conference=20 specific Focus  does not exist create a new Focus with a unique = URI derived=20 from the Conference ID
* Forward the call using the = standard Refer=20 mechanism to the new Focus with the Unique URI.
 
The = advantage of=20 doing this is that I could have multiple Conference servers that are = running=20 that are registered their master focus.
 
We can = implement=20 Load Balancing across Conference servers without the UA realizing = it as it=20 is not connecting to a specific Focus on a specific server. A = second=20 advantage is that if in the course of a meeting if the focus were to go = down or=20 the server went down the participants can attempt to rejoin the call. In = such a=20 case the Master Focus would see that the Conference specific focus is = down and=20 recreate it allowing users to quickly rejoin the = conference.
 
Of = course one needs=20 to work out the details of the communication and keepalive between the = Master=20 Focus and the Conference focus it creates.
 
The = other advantage=20 is if there are global Conference policies these can be applied at the = master=20 and the Individual Conference focus needs to worry about the specifics = of the=20 conference it is dealing with.
 
The = other comment=20 was in the area of the Conference policy control protocol. Is this = something=20 like the SDP which is carried as a payload in SIP or does it have = specifics of=20 it's own. Currently most of the operations that are part of the CPCP are = also=20 possible through SIP based mechanisms. Is there a need to define two = parallel=20 mechanisms within the same framework.
 
 
Instead of dealing=20 with Conference aware UA's and Conference Unaware UA's we could assume = all=20 participants in the Conference to be Conference Aware. The Conference = Unaware=20 participants are routed through a Gateway (e.g. an IVR ) that = provides=20 a primitive interface to the conference unaware participants and a = Conference=20 aware interface to the Conference itself.  This would keep the = model=20 simpler and it can allow Conference aware UAs a way to control the=20 conference.
 
Regards
Shiva
Cisco=20 Systems
 
 
 
------=_NextPart_000_0005_01C2DA6D.CE1C8060-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sat Feb 22 03:54:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07591 for ; Sat, 22 Feb 2003 03:54:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1M91o402544 for sipping-archive@odin.ietf.org; Sat, 22 Feb 2003 04:01:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1M91op02541 for ; Sat, 22 Feb 2003 04:01:50 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07576 for ; Sat, 22 Feb 2003 03:53:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1M90gp02478; Sat, 22 Feb 2003 04:00:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1M8x4p02409 for ; Sat, 22 Feb 2003 03:59:04 -0500 Received: from p2.piuha.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07554 for ; Sat, 22 Feb 2003 03:51:06 -0500 (EST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id D4EAC6A901; Sat, 22 Feb 2003 10:54:55 +0200 (EET) Message-ID: <3E573ABA.7000909@piuha.net> Date: Sat, 22 Feb 2003 10:54:18 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jh@lohi.eng.song.fi Cc: sipping@ietf.org Subject: Re: [Sipping] New version of the SIP-AAA reqs draft References: <15959.2223.178334.9501@harjus.eng.song.fi> 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit jh@lohi.eng.song.fi wrote: > john.loughney@nokia.com writes: > > > I understand your reasons for not wanting to upgrade everything > > to Diameter, but I still don't see what reasons you have for > > being dismissive of Diameter. > > henry may have points why he doesn't like diameter, but for me, it is > nto really that big deal IF diameter AAA infrastructure some day becomes > wide spread. today, however, that is not the case. instead everybody > is using radius as the protocol between NASes (includifn sip proxies) > and AAA servers and also between AAA servers themselves. Right. That's why DIAMETER has been designed to be able to work with RADIUS. Naturally new features in DIAMETER are not necessarily accessible in RADIUS, but things that run on RADIUS should also run on DIAMETER, such as current NAS or AP authentication. (This is by the way one reason why I don't believe web services will be successful in this space; I see the RADIUS - DIAMETER line continuing for network access, telephony even if some other apps do something else.) > examples of the latter are gric and ipass, which provide roaming service > for hundreds of isps literally all over the world. if radius is so bad > that what you say IESG claims, i don't understand how this is possible. > the roaming services run radius over ipsec which solves the security > issues. The limitations of RADIUS have been documented in various places. Running IPsec does actually help in some of the security-related limitations, though not all. Everyone knows RADIUS has problems, but it was the only thing people had. To recap: Let's plan for a solution that provides the functions required in the requirements document (using DIAMETER), but allows for some amount of compatibility with RADIUS. Jari _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sat Feb 22 04:53:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08112 for ; Sat, 22 Feb 2003 04:53:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1MA0pe05489 for sipping-archive@odin.ietf.org; Sat, 22 Feb 2003 05:00:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MA0pp05486 for ; Sat, 22 Feb 2003 05:00:51 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08106 for ; Sat, 22 Feb 2003 04:52:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MA0Gp05471; Sat, 22 Feb 2003 05:00:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1M9xdp05405 for ; Sat, 22 Feb 2003 04:59:39 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08060 for ; Sat, 22 Feb 2003 04:51:39 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1M9sF224246 for ; Sat, 22 Feb 2003 11:54:16 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 22 Feb 2003 11:55:29 +0200 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sat, 22 Feb 2003 11:55:29 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sat, 22 Feb 2003 11:55:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] New version of the SIP-AAA reqs draft Date: Sat, 22 Feb 2003 11:55:28 +0200 Message-ID: Thread-Topic: [Sipping] New version of the SIP-AAA reqs draft Thread-Index: AcLZ6piaUnFnz5vjRX6m7Arb4TRX6wAbL6cQ To: , Cc: X-OriginalArrivalTime: 22 Feb 2003 09:55:28.0827 (UTC) FILETIME=[87B098B0:01C2DA58] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1M9xdp05406 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Henry, > Thanks for clarifying the fact that we have two issues. > > The 2nd item, why DIAMETER is not the best option for NG: It is too > little, too late. > > AAA is a natural part of e-commerce, that is of the web services > architecture, as defined in W3C and numerous industry consortiums. It > makes little sense for all the world to make payments and conduct > transactions in the 'web services currency' and only phone calls to be > paid in 'DIAMETER currency'. Actually two types of phones call > 'currencies': Wired using RADIUS and mobile using DIAMETER. Not that > DIAMETER is inherently evil or poorly engineered. It is just too little > too late, when looking beyond RADIUS and its limitations. My > two cents. Well, I would debate that there is a significant difference between Diameter currencies and Web services' currencies. Diameter, ultimately, is a transport protocol for AAA, it does not define the format, etc. > I would see the design jobs therefore this way: > > 1-Near term: Use RADIUS-SIP to accommodate the huge isntalled base. The > I-D's mentioned here. Including the OSP token for SIP. > > 2-Longer-term: The Web services architecture. I would think that Web services are not in scope for the IETF, it is much more of something for W3C, OMA or IRTF to take up, in my opinion. I think the near term is what we should be working on, and I see the solution to be RADIUS compatability & Diameter support - meaning that RADIUS may be able to support Authorization & Authentication, but Accounting might not be possible, that is why Diameter should be considered. There is as well a request from the 3G's that a Diameter based application be supported. > It appears the present discussion stems from the fact that we only have > volonteers for a DIAMETER-SIP draft. None of the mentioned RADIUS-SIP > authors have volunteered any work here, and this is the problem. So > unless the no RADIUS or web services volonteer steps up, we will have > neither 1 nor 2. Well, what I suggest is that for the folks to whom RADIUS-SIP is important, they should get together and get the resources to work on a solution. The work doesn't do it by itself. br, 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 mailnull@www1.ietf.org Sat Feb 22 10:39:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12242 for ; Sat, 22 Feb 2003 10:39:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1MFl2222785 for sipping-archive@odin.ietf.org; Sat, 22 Feb 2003 10:47:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MFl2p22782 for ; Sat, 22 Feb 2003 10:47:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12235 for ; Sat, 22 Feb 2003 10:38:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MFjrp22708; Sat, 22 Feb 2003 10:45:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MFgPp22602 for ; Sat, 22 Feb 2003 10:42:25 -0500 Received: from gateway.hns.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12128; Sat, 22 Feb 2003 10:34:17 -0500 (EST) From: aroychow@hss.hns.com Received: from excore1.hns.com (excore1.hns.com [139.85.52.104]) by gateway.hns.com (Switch-3.0.0/Switch-3.0.0) with ESMTP id h1MFc5J3022949; Sat, 22 Feb 2003 10:38:05 -0500 (EST) Received: from atlas (atlas.hns.com [139.85.177.110]) by excore1.hns.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h1MFc0D22180; Sat, 22 Feb 2003 10:38:00 -0500 (EST) To: Cc: sipping@ietf.org, sipping-admin@ietf.org Subject: Re: [Sipping] Comments on draft-rosenberg-sipping-conferencing-framework-01.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Sat, 22 Feb 2003 10:37:44 -0500 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.10 |March 22, 2002) at 02/22/2003 10:36:02 AM, Serialize complete at 02/22/2003 10:36:02 AM Content-Type: multipart/alternative; boundary="=_alternative 0055D6DB85256CD5_=" X-Filtered: Sendmail MIME Filter v1.0.7 excore1.hns.com h1MFc0D22180 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 0055D6DB85256CD5_= Content-Type: text/plain; charset="us-ascii" Inline prefixed by The idea of having a unique URI for each conference is a good one. However a more scalable approach would be to have a master Focus or a group of them that register with a standard URI. This way users use a standard URI with a Conference ID as the payload in the Invite message. This is directed to the master Focus that does the following * Retrieve the Conference ID * Check if a Focus corresponding to the conference exists * If the Conference specific Focus does not exist create a new Focus with a unique URI derived from the Conference ID * Forward the call using the standard Refer mechanism to the new Focus with the Unique URI. You may also want to read http://www.iptel.org/info/players/ietf/conferencing/draft-johnston-sipping-cc-conferencing-01.txt. Its provides the definition of a conference Factory URI, which could be used to create new conferences and their Focii. Note that when you send an INVITE to a factory URI, that entity returns the actual Conference-URI in the Contact header. Also, you may be using a central 'conference enabling application' that asks you lots of questions before allowing you to create/join a new conference. See an example of that in 4.3 of alan/orit's draft. Note however , that when you want to use a "standard wellknown URI" that has not been published to you by the conference server, you are assuming that there is some agreement for that domain on conference naming policies. I am not sure I like your idea of a payload contaning conf-id (what use is that ?) Also, note that for scalability (if thats your primary concern), this mechanism allows a way for you to start with a 'guessed URI' and from then on communicate directly with you assigned focus without routing everthing to what you call your 'master focus'. Instead of dealing with Conference aware UA's and Conference Unaware UA's we could assume all participants in the Conference to be Conference Aware. The Conference Unaware participants are routed through a Gateway (e.g. an IVR ) that provides a primitive interface to the conference unaware participants and a Conference aware interface to the Conference itself. This would keep the model simpler and it can allow Conference aware UAs a way to control the conference. It is extremely important to acknowledge conference-unaware endpoints. You cannot assume an IVR or any other application in all conference scenarios who 'aware' on behalf of an unaware UA. Again, reading both Jonathan and Alan/Orit's draft in conjunction may motivate you more on the requirement of conference unaware UAs. Remeber also , that most of the EPs deployed in SIP have zilch idea of what isFocus is as well as will not be aware of protocols to moderate a conference for a while. The other comment was in the area of the Conference policy control protocol. Is this something like the SDP which is carried as a payload in SIP or does it have specifics of it's own. Currently most of the operations that are part of the CPCP are also possible through SIP based mechanisms. Is there a need to define two parallel mechanisms within the same framework. I think what has been identifed here is a need for a conference policy control protocol. It is not ascertained yet which protocol will deliver these requirements. Thats as far as I know. The existing SDP specs do not meet all control requirements that come to my mind. Alan - would you mind reposting that link of conferencing work in progress ? I thought I noticed some drafts attempting to address this in more detail Now a question again for the authors of draft-johnston-sipping-cc-conferencing-01.txt: * section 4.5 callflow - you show alice sending an invite to a conf-factory URI but the ladder diagram shows it being received by a 'Focus'. The definition of a focus 3.1 Focus UA A focus, as defined in the framework, hosts a SIP conference and maintains a SIP signaling relationship with each participant in the conference. A focus contains a conference-aware user agent that supports the conferencing call control conventions as defined in this document. Since a 'Focus' hosts 'a specific' conference, I find it a little disconcerting that the call flows show messages with a factory-URI reaching a focus. I thought it may be clearer, if we limit a 'focus' to be the target of a specific URI meant for a specific conference. If a person sends an INVITE to a factory-URI or a 'conf-app-URI' < like an IVR etc which then contacts a Factory after auth etc> it should not be received by a Focus, should it ? regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301 212 7860 (M): 240 997 0066{@vtext.com} "Shiva" Sent by: sipping-admin@ietf.org 02/22/2003 01:57 AM Please respond to shaj To: cc: Subject: [Sipping] Comments on draft-rosenberg-sipping-conferencing-framework-01.txt Hello, Overall the draft looks good. Here are some of my comments on this draft The advantage of doing this is that I could have multiple Conference servers that are running that are registered their master focus. We can implement Load Balancing across Conference servers without the UA realizing it as it is not connecting to a specific Focus on a specific server. A second advantage is that if in the course of a meeting if the focus were to go down or the server went down the participants can attempt to rejoin the call. In such a case the Master Focus would see that the Conference specific focus is down and recreate it allowing users to quickly rejoin the conference. Of course one needs to work out the details of the communication and keepalive between the Master Focus and the Conference focus it creates. The other advantage is if there are global Conference policies these can be applied at the master and the Individual Conference focus needs to worry about the specifics of the conference it is dealing with. The other comment was in the area of the Conference policy control protocol. Is this something like the SDP which is carried as a payload in SIP or does it have specifics of it's own. Currently most of the operations that are part of the CPCP are also possible through SIP based mechanisms. Is there a need to define two parallel mechanisms within the same framework. Instead of dealing with Conference aware UA's and Conference Unaware UA's we could assume all participants in the Conference to be Conference Aware. The Conference Unaware participants are routed through a Gateway (e.g. an IVR ) that provides a primitive interface to the conference unaware participants and a Conference aware interface to the Conference itself. This would keep the model simpler and it can allow Conference aware UAs a way to control the conference. Regards Shiva Cisco Systems --=_alternative 0055D6DB85256CD5_= Content-Type: text/html; charset="us-ascii"
Inline prefixed by <ARC>

The idea of having a unique URI for each conference is a good one. However a more scalable approach would be to have a master Focus or a group of them that register with a standard URI. This way users use a standard URI with a Conference ID as the payload in the Invite message.  This is directed to the master Focus that does the following
* Retrieve the Conference ID
* Check if a Focus corresponding to the conference exists
* If the Conference specific Focus  does not exist create a new Focus with a unique URI derived from the Conference ID
* Forward the call using the standard Refer mechanism to the new Focus with the Unique URI.
 
<ARC>
 You may also want to read http://www.iptel.org/info/players/ietf/conferencing/draft-johnston-sipping-cc-conferencing-01.txt.
Its provides the definition of a conference Factory URI, which could be used to create new conferences and their Focii.
Note that when you send an INVITE to a factory URI, that entity returns the actual Conference-URI in the Contact header.
Also, you may be using a central 'conference enabling application' that  asks you lots of questions before allowing you to create/join  a new
conference. See an example of that in 4.3 of alan/orit's draft.
Note however , that when you want to use a "standard wellknown URI" that has not been published to you by the conference server,
you are assuming that there is some agreement for that domain on conference naming policies.
I am not sure I like your idea of a payload contaning conf-id (what use is that ?)
Also, note that for scalability (if thats your primary concern), this mechanism allows a way for you to start with a 'guessed URI' and from
then on communicate directly with you assigned focus without routing everthing to what you call your 'master focus'.
</ARC>


Instead of dealing with Conference aware UA's and Conference Unaware UA's we could assume all participants in the Conference to be Conference Aware. The Conference Unaware participants are routed through a Gateway (e.g. an IVR ) that provides a primitive interface to the conference unaware participants and a Conference aware interface to the Conference itself.  This would keep the model simpler and it can allow Conference aware UAs a way to control the conference.

<ARC>
 It is extremely important to acknowledge conference-unaware endpoints. You cannot assume an IVR or any other application in all
conference scenarios who 'aware' on behalf of an unaware UA. Again, reading both Jonathan and Alan/Orit's draft in conjunction may motivate
you more on the requirement of conference unaware UAs. Remeber also , that most of the EPs deployed in SIP have zilch idea of what isFocus is
as well as will not be aware of protocols to moderate a conference for a while.
</ARC>


The other comment was in the area of the Conference policy control protocol. Is this something like the SDP which is carried as a payload in SIP or does it have specifics of it's own. Currently most of the operations that are part of the CPCP are also possible through SIP based mechanisms. Is there a need to define two parallel mechanisms within the same framework.

<ARC>
I think what has been identifed here is a need for a conference policy control protocol. It is not ascertained yet which protocol will deliver these
requirements. Thats as far as I know. The existing SDP specs do not meet all control requirements that come to my mind.

Alan - would you mind reposting that link of conferencing work in progress  ? I thought I noticed some drafts attempting to address this in more detail

Now a question again for the authors of  draft-johnston-sipping-cc-conferencing-01.txt:

* section 4.5 callflow - you show alice sending an invite to a conf-factory URI but the ladder diagram shows it being received by a 'Focus'.
The definition of a focus


3.1 Focus UA

  A focus, as defined in the framework, hosts a SIP conference and
  maintains a SIP signaling relationship with each participant in the
  conference. A focus contains a conference-aware user agent that
  supports the conferencing call control conventions as defined in this
  document.

Since a 'Focus' hosts 'a specific' conference, I find it a little disconcerting
that the call flows show messages with a factory-URI reaching a focus. I thought
it may be clearer, if we limit a 'focus' to be the target of a specific URI meant
for a specific conference. If a person sends an INVITE to a factory-URI or
a 'conf-app-URI' < like an IVR etc which then contacts a Factory after auth etc>
it should not be received by a Focus, should it ?

</ARC>

regds
Arjun
--
Arjun Roychowdhury @ Hughes Software Systems
11717 Exploration Lane, Germantown MD 20876
(O): 301 212 7860  (M): 240 997 0066{@vtext.com}


"Shiva" <shaj@cisco.com>
Sent by: sipping-admin@ietf.org

02/22/2003 01:57 AM
Please respond to shaj

       
        To:        <sipping@ietf.org>
        cc:        
        Subject:        [Sipping] Comments on draft-rosenberg-sipping-conferencing-framework-01.txt



Hello,
 
Overall the draft looks good.  Here are some of my comments on this draft
 

The advantage of doing this is that I could have multiple Conference servers that are running that are registered their master focus.
 
We can implement Load Balancing across Conference servers without the UA realizing it as it is not connecting to a specific Focus on a specific server. A second advantage is that if in the course of a meeting if the focus were to go down or the server went down the participants can attempt to rejoin the call. In such a case the Master Focus would see that the Conference specific focus is down and recreate it allowing users to quickly rejoin the conference.
 
Of course one needs to work out the details of the communication and keepalive between the Master Focus and the Conference focus it creates.
 
The other advantage is if there are global Conference policies these can be applied at the master and the Individual Conference focus needs to worry about the specifics of the conference it is dealing with.
 
The other comment was in the area of the Conference policy control protocol. Is this something like the SDP which is carried as a payload in SIP or does it have specifics of it's own. Currently most of the operations that are part of the CPCP are also possible through SIP based mechanisms. Is there a need to define two parallel mechanisms within the same framework.
 
 
Instead of dealing with Conference aware UA's and Conference Unaware UA's we could assume all participants in the Conference to be Conference Aware. The Conference Unaware participants are routed through a Gateway (e.g. an IVR ) that provides a primitive interface to the conference unaware participants and a Conference aware interface to the Conference itself.  This would keep the model simpler and it can allow Conference aware UAs a way to control the conference.
 
Regards
Shiva
Cisco Systems
 
 
 

--=_alternative 0055D6DB85256CD5_=-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sun Feb 23 21:54:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19016 for ; Sun, 23 Feb 2003 21:54:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1O32QH09775 for sipping-archive@odin.ietf.org; Sun, 23 Feb 2003 22:02:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O32Qp09772 for ; Sun, 23 Feb 2003 22:02:26 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19013 for ; Sun, 23 Feb 2003 21:53:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O31Np09700; Sun, 23 Feb 2003 22:01:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O2w1p09575 for ; Sun, 23 Feb 2003 21:58:01 -0500 Received: from dgesmtp01.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18897 for ; Sun, 23 Feb 2003 21:49:10 -0500 (EST) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.wcom.com (Iplanet MTA) with ESMTP id <0HAS0015LLCG86@firewall.wcom.com> for sipping@ietf.org; Mon, 24 Feb 2003 02:53:04 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HAS00M01LCFZ0@pmismtp04.wcomnet.com>; Mon, 24 Feb 2003 02:53:04 +0000 (GMT) Received: from hsinnreich2 ([166.50.135.197]) by pmismtp04.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HAS00L4PLC8EX@pmismtp04.wcomnet.com>; Mon, 24 Feb 2003 02:53:03 +0000 (GMT) Date: Sun, 23 Feb 2003 20:52:54 -0600 From: Henry Sinnreich Subject: RE: [Sipping] New version of the SIP-AAA reqs draft In-reply-to: <3E573ABA.7000909@piuha.net> To: jari.arkko@piuha.net, jh@lohi.eng.song.fi Cc: sipping@ietf.org Message-id: <001701c2dbaf$d8150090$966932a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > To recap: Let's plan for a solution that provides the > functions required in the requirements document (using > DIAMETER), but allows for some amount of compatibility with RADIUS. We may live to see neither in the near future, but a new one, based on web services, a la .NET or Liberty Alliance. As mentioned, it makes no sense for telephone calls to be AAA-ed and purchased in some exotic RADIUS or DIAMTER "currency", while everything else is purchased and AAA-ed with web services. The problem in this WG at present is there are no volunteers for this alternative. I will desist trying to stop DIAMETER if it meets someone's needs, but just wanted to share the possibility mentioned above. Thanks, Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of Jari Arkko > Sent: Saturday, February 22, 2003 2:54 AM > To: jh@lohi.eng.song.fi > Cc: sipping@ietf.org > Subject: Re: [Sipping] New version of the SIP-AAA reqs draft > > > jh@lohi.eng.song.fi wrote: > > john.loughney@nokia.com writes: > > > > > I understand your reasons for not wanting to upgrade > everything > > > to Diameter, but I still don't see what reasons you have > for > being > > dismissive of Diameter. > > > > henry may have points why he doesn't like diameter, but for > me, it is > > nto really that big deal IF diameter AAA infrastructure some day > > becomes wide spread. today, however, that is not the case. > instead > > everybody is using radius as the protocol between NASes > (includifn sip > > proxies) and AAA servers and also between AAA servers themselves. > > Right. That's why DIAMETER has been designed to be able to > work with RADIUS. Naturally new features in DIAMETER are not > necessarily accessible in RADIUS, but things that run on > RADIUS should also run on DIAMETER, such as current NAS or AP > authentication. > > (This is by the way one reason why I don't believe web > services will be successful in this space; I see the RADIUS - > DIAMETER line continuing for network access, telephony even > if some other apps do something else.) > > > examples of the latter are gric and ipass, which provide roaming > > service for hundreds of isps literally all over the world. > if radius > > is so bad that what you say IESG claims, i don't understand > how this > > is possible. the roaming services run radius over ipsec > which solves > > the security issues. > > The limitations of RADIUS have been documented in various > places. Running IPsec does actually help in some of the > security-related limitations, though not all. Everyone knows > RADIUS has problems, but it was the only thing people had. > > To recap: Let's plan for a solution that provides the > functions required in the requirements document (using > DIAMETER), but allows for some amount of compatibility with RADIUS. > > Jari > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 mailnull@www1.ietf.org Mon Feb 24 08:46:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14267 for ; Mon, 24 Feb 2003 08:46:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1ODsZq26025 for sipping-archive@odin.ietf.org; Mon, 24 Feb 2003 08:54:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ODsZp26022 for ; Mon, 24 Feb 2003 08:54:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14223 for ; Mon, 24 Feb 2003 08:45:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ODrjp25984; Mon, 24 Feb 2003 08:53:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ODqQp25934 for ; Mon, 24 Feb 2003 08:52:26 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14158 for ; Mon, 24 Feb 2003 08:43:22 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h1ODlFxw024415 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 24 Feb 2003 08:47:15 -0500 (EST) Message-ID: <3E5A227E.6090202@cs.columbia.edu> Date: Mon, 24 Feb 2003 08:47:42 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'sipping@ietf.org'" Content-Type: multipart/mixed; boundary="------------030109090601070907060601" Subject: [Sipping] [Fwd: I-D ACTION:draft-belinchon-aaa-diameter-mm-app-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: , This is a multi-part message in MIME format. --------------030109090601070907060601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------030109090601070907060601 Content-Type: message/rfc822; name="I-D ACTION:draft-belinchon-aaa-diameter-mm-app-00.txt" Content-Disposition: inline; filename="I-D ACTION:draft-belinchon-aaa-diameter-mm-app-00.txt" Return-Path: Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h1OCEJ729927; Mon, 24 Feb 2003 07:14:19 -0500 Received: from ran.ietf.org (ran.ietf.org [132.151.6.60]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id h1OCEI0B023995; Mon, 24 Feb 2003 07:14:18 -0500 (EST) Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 18nHEf-0007VJ-00 for ietf-announce-list@ran.ietf.org; Mon, 24 Feb 2003 06:57:29 -0500 Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 18nHAv-0007Rl-00 for all-ietf@ran.ietf.org; Mon, 24 Feb 2003 06:53:37 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08502 for ; Mon, 24 Feb 2003 06:43:58 -0500 (EST) Message-Id: <200302241143.GAA08502@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-belinchon-aaa-diameter-mm-app-00.txt Date: Mon, 24 Feb 2003 06:43:58 -0500 Sender: owner-ietf-announce@ietf.org Precedence: bulk X-Spam-Status: No, hits=4.6 required=5.0 tests=AWL,MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Diameter Multimedia Application Author(s) : M. Belinchon et al. Filename : draft-belinchon-aaa-diameter-mm-app-00.txt Pages : 37 Date : 2003-2-21 This document specifies a Diameter application that supports the authentication, authorization, and collection of accounting information for Session Initiation Protocol (SIP) services rendered to a client node. This application, combined with the base Diameter protocol and appropriate SIP extensions, allows SIP User Agents (UAs) to obtain services from SIP servers that are connected to a Diameter infrastructure. When combined with the Inter-Domain capability of the base protocol, service may even be obtained from SIP servers that belong to foreign domains, as would be encountered by roaming mobile nodes. Note that the specification defined here may be used independently of the authentication technique used for authenticating a node's link layer or network-layer access. In particular, we do not require the client node to be authenticated for access with the use of either the Mobile IP [3] or NASREQ [11] Diameter application. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-belinchon-aaa-diameter-mm-app-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-belinchon-aaa-diameter-mm-app-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-belinchon-aaa-diameter-mm-app-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-21160912.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-belinchon-aaa-diameter-mm-app-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-belinchon-aaa-diameter-mm-app-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-21160912.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------030109090601070907060601-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Feb 24 10:48:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17289 for ; Mon, 24 Feb 2003 10:48:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OFucb01772 for sipping-archive@odin.ietf.org; Mon, 24 Feb 2003 10:56:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OFucp01769 for ; Mon, 24 Feb 2003 10:56:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17268 for ; Mon, 24 Feb 2003 10:47:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OFnQp01330; Mon, 24 Feb 2003 10:49:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OFjdp01147 for ; Mon, 24 Feb 2003 10:45:39 -0500 Received: from hoemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16953 for ; Mon, 24 Feb 2003 10:36:33 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1OFeP617470 for ; Mon, 24 Feb 2003 10:40:25 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA29326; Mon, 24 Feb 2003 09:40:23 -0600 (CST) Message-ID: <3E5A3CA4.4070307@lucent.com> Date: Mon, 24 Feb 2003 09:39:16 -0600 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories 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 LIST CC: "Jain, Rajnish (Rajnish)" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] I-D on persistent connections Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks: A while ago we had a discussion on persistent connections in SIP. We have submitted an I-D to the IETF outlining the problem, some requirements and some solutions. Until it appears in the archives, you can get it from: http://www.iit.edu/~gurbvij/I-D/draft-jain-sipping-persistent-conn-reqs-00.txt Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Feb 24 11:24:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18137 for ; Mon, 24 Feb 2003 11:24:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OGXBR04085 for sipping-archive@odin.ietf.org; Mon, 24 Feb 2003 11:33:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OGXBp04082 for ; Mon, 24 Feb 2003 11:33:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18121 for ; Mon, 24 Feb 2003 11:24:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OGWPp04053; Mon, 24 Feb 2003 11:32:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OGVVp04015 for ; Mon, 24 Feb 2003 11:31:31 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18101 for ; Mon, 24 Feb 2003 11:22:23 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA19579; Mon, 24 Feb 2003 11:26:16 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA03288; Mon, 24 Feb 2003 11:26:17 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Feb 2003 11:26:17 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5EA6@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "Jonathan Rosenberg (E-mail)" Cc: "'sipping@ietf.org'" Date: Mon, 24 Feb 2003 11:26:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] Sidebars Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , In the latest conferencing framework draft, sidebars are proposed as a separate conference URI with special properties. In particular there is this text: A sidebar is represented by a separate conference URI. This URI is a type of "alias" for the main conference URI. Both route to the same focus. Like any other conference, the sidebar conference URI has a conference policy and a media policy associated with it. Like any other conference, one can join it by sending an INVITE to this URI, or ask others to join by referring them to it. However, it differs from a normal conference URI in several ways. First, users in the main conference do not need to establish a separate dialog to the sidebar conference. The focus recognizes the sidebar as a special URI, and knows to use the existing dialog to the main conference as a "virtual" connection to the sidebar URI. The second difference is the way in which conference and media policies are implemented. If the conference policy control protocol is used to add a user to a normal conference, the focus will typically send an INVITE to the participant to ask them to join. For a sidebar conference, it is done differently. If the conference policy control protocol is used to add a user to it, and that user is already part of the main conference, the focus will use the conference notification service to alert the existing participant that they have been asked to join the sidebar. The invited user can then make use of the CPCP to formally add themselves to the sidebar. I'm interested in how a non-conference aware UA participates in a sidebar. Clearly, an out-of-band mechanism can be used to manipulate the CPCP to add such a UA to a sidebar, and similar means to control media policy. This is very encouraging. I'm confused, however, on exactly how this special sidebar URI will work with a non-conference aware UA. Specifically: The text says that an INVITE with the sidebar URI will not be sent by the focus to request the user to join. Is there any circumstance in which the focus would use the sidebar URI? I'm thinking of, for example, what would normally be a re-invite to add a media stream when another user, who is not a main conference participant already, joins the sidebar. Any use of the sidebar URI with a non conference aware UA would confuse the heck out of it. So far, I'm thinking that the only real use of this URI is for a UA which is not a main conference participant to get added to the sidebar, but not the main conference. The wording in the framework document could offer more clarity on the use of this URI. Brian _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Feb 24 14:22:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23372 for ; Mon, 24 Feb 2003 14:22:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OJUwY16838 for sipping-archive@odin.ietf.org; Mon, 24 Feb 2003 14:30:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OJUwp16835 for ; Mon, 24 Feb 2003 14:30:58 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23327 for ; Mon, 24 Feb 2003 14:21:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OJU0p16803; Mon, 24 Feb 2003 14:30:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OJSTp16686 for ; Mon, 24 Feb 2003 14:28:29 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23271 for ; Mon, 24 Feb 2003 14:19:18 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h1OJNAC08744; Mon, 24 Feb 2003 19:23:10 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Feb 2003 14:23:14 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214E2D@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Mpierce1@aol.com'" , sipping@ietf.org Subject: RE: [Sipping] Comments on Overlap-04 Date: Mon, 24 Feb 2003 14:23:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DC3A.2C7E16F0" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2DC3A.2C7E16F0 Content-Type: text/plain; charset="iso-8859-1" Some responses below. Jon Peterson NeuStar, Inc. -----Original Message----- From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: Wednesday, February 19, 2003 7:41 PM To: sipping@ietf.org Subject: [Sipping] Comments on Overlap-04 Comments on draft-ietf-sipping-overlap-04: General: The ability of one call to result in multiple IAMs being sent into the PSTN continues to be a serious problem for overlap which must be solved. This concern has been the subject of whole libraries of previous mail; I think we need to agree to disagree on this point. As we've said in the past, the draft allows this condition to arise only if operators choose to configure their networks in a fashion that allows it. Section 3.1: All references to one number being a "prefix" of another should be deleted. This text indicates that overlap can not be used where this "prefix" situation can occur, however, one of the purposes of overlap is to handle the situation in which there are varying lengths of numbers in some destination area, something that would naturally exist if one number really could be a "prefix" of another. This creates a major contradiction. Not necessarily a contradiction, actually. There are varying lengths of numbers in some numbering plans. That does not entail, however, that one number can necessarily be a prefix of another. The numbers +9990123 and +99912345 could exist in the same numbering plan without creating any problems for overlap signaling. The concern is if the numbers +9990123 and +99901234 were to exist in the same numbering plan. However, there is still no identified case in the world-wide numbering plan in which one number is a "prefix" of another. If there were, overlap signaling to get to it would certainly be allowed just as it would be in the existing PSTN. If one believes that this "prefix" situation really exists, then the overlap procedures defined in this draft must correctly support it. We can't necessarily verify that it's the case, but people keep telling us that this happens in practice in the PSTN. As usual, it is tough to provide a counter-existence proof. I think we still need this text. Section 3.3 contains the statement: As a general rule, a media stream corresponding to the response to an INVITE with a greater number of digits should be given more priority than media streams from responses with less digits. This continues to be a problem, since it is not always the case. If the originator dialed more digits than were needed when overlap was being used, the media stream corresponding to the response with the fewer digits would be the one to use. The PSTN had no problem with this. SIP is going to have to figure out a way to correctly handle it. Our text satisfies particular early-media concerns, and is valid, in my opinion. If fewer digits than the minimum length of a number in the numbering plan are dialed, a gateway could still attempt to pass backwards media to the UAC in order to provide early media data. The behavior that occurs when more digits are dialed than necessary is, no doubt, specific to different nationalities, but it seems reasonable to assume that superfluous digits will be discarded. No one, to date, has asserted anything to the contrary anyway. Section 3.5 contains the statement: If the gateway is attached to the PSTN in an area where en-bloc signalling is used, a REL for the previous IAM and a new IAM should be generated. This causes confusion since all areas would allow en-bloc, although some do not allow overlap, for example, an area where US SS#7 according to T1.113 is used. In those areas, since overlap is not allowed, the gateway or switch which provides interworking into that non-overlap area must perform the overlap to en-bloc procedures (by time outs, detecting enough digits, etc.) There can not be a "previous IAM" sent to the PSTN, since the gateway or switch would not have sent one until it knew it had enough digits to send a complete IAM, after which it would stop accepting or sending any further digits. First of all, if you send an incomplete number into an en-bloc signaling network, that are ISUP failure responses (REL with cause 28) that will be sent in response. Our text identifies what one should do if the call has not already been rejected. Gateway very well might be stupid enough to send incomplete addresses into a network that cannot accept them, and it seems dangerous to assume otherwise. This paragraph should be worded as: If the gateway is attached to the PSTN in an area where overlap signalling is not allowed, it must not send an IAM until it determines that it has received the full number in one or more INVITEs, using a process similar to that described in Section 2. It must not send SAMs or additional IAMs after that one IAM. Mike Pierce ------_=_NextPart_001_01C2DC3A.2C7E16F0 Content-Type: text/html; charset="iso-8859-1"
Some responses below.
 
Jon Peterson
NeuStar, Inc.
-----Original Message-----
From: Mpierce1@aol.com [mailto:Mpierce1@aol.com]
Sent: Wednesday, February 19, 2003 7:41 PM
To: sipping@ietf.org
Subject: [Sipping] Comments on Overlap-04

Comments on draft-ietf-sipping-overlap-04:

General:

The ability of one call to result in multiple IAMs being sent into the PSTN continues to be a serious problem for overlap which must be solved.  
 
<JFP> This concern has been the subject of whole libraries of previous mail; I think we need to agree to disagree on this point. As we've said in the past, the draft allows this condition to arise only if operators choose to configure their networks in a fashion that allows it. </JFP> 

Section 3.1:

All references to one number being a "prefix" of another should be deleted. This text indicates that overlap can not be used where this "prefix" situation can occur, however, one of the purposes of overlap is to handle the situation in which there are varying lengths of numbers in some destination area, something that would naturally exist if one number really could be a "prefix" of another. This creates a major contradiction.  
 
<JFP> Not necessarily a contradiction, actually. There are varying lengths of numbers in some numbering plans. That does not entail, however, that one number can necessarily be a prefix of another. The numbers +9990123 and +99912345 could exist in the same numbering plan without creating any problems for overlap signaling. The concern is if the numbers +9990123 and +99901234 were to exist in the same numbering plan.   
 
 However, there is still no identified case in the world-wide numbering plan in which one number is a "prefix" of another. If there were, overlap signaling to get to it would certainly be allowed just as it would be in the existing PSTN. If one believes that this "prefix" situation really exists, then the overlap procedures defined in this draft must correctly support it. 
 
<JFP> We can't necessarily verify that it's the case, but people keep telling us that this happens in practice in the PSTN. As usual, it is tough to provide a counter-existence proof. I think we still need this text. </JFP>

Section 3.3 contains the statement:

  As a general rule, a media stream corresponding to the response to an
  INVITE with a greater number of digits should be given more priority
  than media streams from responses with less digits.

This continues to be a problem, since it is not always the case. If the originator dialed more digits than were needed when overlap was being used, the media stream corresponding to the response with the fewer digits would be the one to use. The PSTN had no problem with this. SIP is going to have to figure out a way to correctly handle it. 
 
<JFP> Our text satisfies particular early-media concerns, and is valid, in my opinion. If fewer digits than the minimum length of a number in the numbering plan are dialed, a gateway could still attempt to pass backwards media to the UAC in order to provide early media data. The behavior that occurs when more digits are dialed than necessary is, no doubt, specific to different nationalities, but it seems reasonable to assume that superfluous digits will be discarded. No one, to date, has asserted anything to the contrary anyway. </JFP>

Section 3.5 contains the statement:

  If the gateway is attached to the PSTN in an area where en-bloc
  signalling is used, a REL for the previous IAM and a new IAM should
  be generated.

This causes confusion since all areas would allow en-bloc, although some do not allow overlap, for example, an area where US SS#7 according to T1.113 is used. In those areas, since overlap is not allowed, the gateway or switch which provides interworking into that non-overlap area must perform the overlap to en-bloc procedures (by time outs, detecting enough digits, etc.) There can not be a "previous IAM" sent to the PSTN, since the gateway or switch would not have sent one until it knew it had enough digits to send a complete IAM, after which it would stop accepting or sending any further digits. 
 
<JFP> First of all, if you send an incomplete number into an en-bloc signaling network, that are ISUP failure responses (REL with cause 28) that will be sent in response. Our text identifies what one should do if the call has not already been rejected. Gateway very well might be stupid enough to send incomplete addresses into a network that cannot accept them, and it seems dangerous to assume otherwise. </JFP>

This paragraph should be worded as:

  If the gateway is attached to the PSTN in an area where overlap signalling
  is not allowed, it must not send an IAM until it determines that it has
  received the full number in one or more INVITEs, using a process similar to  
  that described in Section 2. It must not send SAMs or additional IAMs after
  that one IAM.

Mike Pierce
------_=_NextPart_001_01C2DC3A.2C7E16F0-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Feb 24 18:26:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00023 for ; Mon, 24 Feb 2003 18:26:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1ONZco01153 for sipping-archive@odin.ietf.org; Mon, 24 Feb 2003 18:35:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ONZcp01150 for ; Mon, 24 Feb 2003 18:35:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00018 for ; Mon, 24 Feb 2003 18:26:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ONYlp01116; Mon, 24 Feb 2003 18:34:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ONXYp01067 for ; Mon, 24 Feb 2003 18:33:34 -0500 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29952 for ; Mon, 24 Feb 2003 18:24:19 -0500 (EST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h1ONS8G13679; Mon, 24 Feb 2003 15:28:08 -0800 (PST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1LWH7VXW>; Mon, 24 Feb 2003 15:28:08 -0800 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D206CADC51@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Gonzalo Camarillo'" , "'sipping'" Subject: RE: [Sipping] New version of the early media draft Date: Mon, 24 Feb 2003 15:27:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DC5C.5E6809F6" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2DC5C.5E6809F6 Content-Type: text/plain Gonzallo, I finally had a chance to read the new version of early media draft. Kind of interesting that this version didn't get much feedback at all. It is a very good document. I think you have captured very well the very many issues that were discussed last year. I am very comfortable with this new version. I have only one suggestion (and a minor one). In section 2.2 on page 7, in the paragraph that starts with "Note" just below point 3, I would change the lst sentence to the following: This type of gateway could choose to generate local ringback upon reception of a 180 (Ringing) response, and override or mix it with any incoming media that happens to arrive (if it does at all). > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Monday, February 10, 2003 3:41 AM > To: sipping > Subject: [Sipping] New version of the early media draft > > > Folks, > > I have just sumitted a new version of the early media draft. > Until it appears in the archives, you can fetch it from: > http://standards.ericsson.net/gonzalo/papers/draft-camarillo-sipping-early-m edia-01.txt I have included all the (long and useful) discussions we had in the mailing list. Therefore, the draft now keeps separate the "gateway" and the "application server" models. I have also removed the parts we did not agree on. Feedback is, as usual, appreciated. Thanks, Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP ------_=_NextPart_001_01C2DC5C.5E6809F6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sipping] New version of the early media draft

Gonzallo,

I finally had a chance to read the new version of = early media draft. Kind of interesting
that this version didn't get much feedback at = all.

It is a very good document. I think you have captured = very well the very many issues that
were discussed last year. I am very comfortable with = this new version.

I have only one suggestion (and a minor one). In = section 2.2 on page 7, in the paragraph that
starts with "Note" just below point 3, I = would change the lst sentence to the following:

   This type of gateway could choose to = generate local ringback upon reception
   of a 180 (Ringing) response, and = override or mix it with any incoming media that
   happens to arrive (if it does at = all).



> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> Sent: Monday, February 10, 2003 3:41 AM
> To: sipping
> Subject: [Sipping] New version of the early = media draft
>
>
> Folks,
>
> I have just sumitted a new version of the early = media draft.
> Until it appears in the archives, you can fetch = it from:
>
http://standards.ericsson.net/gonzalo/papers/draft-cam= arillo-sipping-early-media-01.txt

I have included all the (long and useful) discussions = we had in the mailing list. Therefore, the draft now keeps separate the = "gateway" and the "application server" models. I = have also removed the parts we did not agree on.

Feedback is, as usual, appreciated.

Thanks,

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

------_=_NextPart_001_01C2DC5C.5E6809F6-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Feb 24 18:57:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00749 for ; Mon, 24 Feb 2003 18:57:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1P05wN02880 for sipping-archive@odin.ietf.org; Mon, 24 Feb 2003 19:05:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1P05wp02877 for ; Mon, 24 Feb 2003 19:05:58 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00741 for ; Mon, 24 Feb 2003 18:56:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1P05Gp02865; Mon, 24 Feb 2003 19:05:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1P04kp02832 for ; Mon, 24 Feb 2003 19:04:46 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00727 for ; Mon, 24 Feb 2003 18:55:30 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h1ONxHC15533; Mon, 24 Feb 2003 23:59:17 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Feb 2003 18:59:21 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214E38@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Francois Audet'" , "'Gonzalo Camarillo'" , "'sipping'" Subject: RE: [Sipping] New version of the early media draft Date: Mon, 24 Feb 2003 18:59:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DC60.BFD3DFE0" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2DC60.BFD3DFE0 Content-Type: text/plain; charset="iso-8859-1" Though I didn't say so to this list, I also thought this document was a great improvement, and I'm also very comfortable with it. Jon Peterson NeuStar, Inc. -----Original Message----- From: Francois Audet [mailto:audet@nortelnetworks.com] Sent: Monday, February 24, 2003 3:28 PM To: 'Gonzalo Camarillo'; 'sipping' Subject: RE: [Sipping] New version of the early media draft Gonzallo, I finally had a chance to read the new version of early media draft. Kind of interesting that this version didn't get much feedback at all. It is a very good document. I think you have captured very well the very many issues that were discussed last year. I am very comfortable with this new version. I have only one suggestion (and a minor one). In section 2.2 on page 7, in the paragraph that starts with "Note" just below point 3, I would change the lst sentence to the following: This type of gateway could choose to generate local ringback upon reception of a 180 (Ringing) response, and override or mix it with any incoming media that happens to arrive (if it does at all). > -----Original Message----- > From: Gonzalo Camarillo [ mailto:Gonzalo.Camarillo@lmf.ericsson.se ] > Sent: Monday, February 10, 2003 3:41 AM > To: sipping > Subject: [Sipping] New version of the early media draft > > > Folks, > > I have just sumitted a new version of the early media draft. > Until it appears in the archives, you can fetch it from: > http://standards.ericsson.net/gonzalo/papers/draft-camarillo-sipping-early-m edia-01.txt I have included all the (long and useful) discussions we had in the mailing list. Therefore, the draft now keeps separate the "gateway" and the "application server" models. I have also removed the parts we did not agree on. Feedback is, as usual, appreciated. Thanks, Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP ------_=_NextPart_001_01C2DC60.BFD3DFE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sipping] New version of the early media draft
Though=20 I didn't say so to this list, I also thought this document was a = great=20 improvement, and I'm also very comfortable with it.
 
Jon=20 Peterson
NeuStar, Inc.
-----Original Message-----
From: Francois Audet=20 [mailto:audet@nortelnetworks.com]
Sent: Monday, February = 24, 2003=20 3:28 PM
To: 'Gonzalo Camarillo'; = 'sipping'
Subject: RE:=20 [Sipping] New version of the early media draft

Gonzallo,

I finally had a chance to read the new version of = early media=20 draft. Kind of interesting
that this = version didn't=20 get much feedback at all.

It is a very good document. I think you have = captured very=20 well the very many issues that
were = discussed last=20 year. I am very comfortable with this new version.

I have only one suggestion (and a minor one). In = section 2.2=20 on page 7, in the paragraph that
starts = with "Note"=20 just below point 3, I would change the lst sentence to the = following:=20

   This type of gateway could choose to = generate=20 local ringback upon reception
   = of a 180=20 (Ringing) response, and override or mix it with any incoming media = that=20
   happens to arrive (if it does = at=20 all).



> -----Original Message-----
>=20 From: Gonzalo Camarillo [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]=20
> Sent: Monday, February 10, 2003 3:41 = AM=20
> To: sipping
> = Subject:=20 [Sipping] New version of the early media draft
>=20
>
> = Folks,=20
>
> I have just = sumitted a new=20 version of the early media draft.
> = Until it=20 appears in the archives, you can fetch it from:
>=20
http://standards.ericsson.net/gonzalo/papers/dr= aft-camarillo-sipping-early-media-01.txt=20

I have included all the (long and useful) = discussions we had=20 in the mailing list. Therefore, the draft now keeps separate the = "gateway" and=20 the "application server" models. I have also removed the parts we did = not=20 agree on.

Feedback is, as usual, appreciated.

Thanks,

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

------_=_NextPart_001_01C2DC60.BFD3DFE0-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Feb 25 06:53:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25413 for ; Tue, 25 Feb 2003 06:53:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PC21r21787 for sipping-archive@odin.ietf.org; Tue, 25 Feb 2003 07:02:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PC21p21784 for ; Tue, 25 Feb 2003 07:02:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25397 for ; Tue, 25 Feb 2003 06:52:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PBwDp21423; Tue, 25 Feb 2003 06:58:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PBsWp21173 for ; Tue, 25 Feb 2003 06:54:32 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24659; Tue, 25 Feb 2003 06:45:03 -0500 (EST) Message-Id: <200302251145.GAA24659@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 25 Feb 2003 06:45:03 -0500 Subject: [Sipping] I-D ACTION:draft-koskelainen-sipping-conf-policy-req-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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for conference policy data Author(s) : P. Koskelainen Filename : draft-koskelainen-sipping-conf-policy-req-00.txt Pages : 9 Date : 2003-2-24 The conference participants may communicate with the conference policy server, using a conference policy control protocol (CPCP) which is a strictly client-server transactional protocol. This document describes the requirements for conference policy data. Media policy related requirements are beyond the scope of this document. CPCP protocol is not mandatory and the only mechanism to manipulate conference policy data in a conference. For example, web interface can be used as well to perform conference policy manipulation. However, for automata a protocol is needed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-koskelainen-sipping-conf-policy-req-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-koskelainen-sipping-conf-policy-req-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-koskelainen-sipping-conf-policy-req-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-24142313.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-koskelainen-sipping-conf-policy-req-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-koskelainen-sipping-conf-policy-req-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-24142313.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Feb 25 08:38:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00842 for ; Tue, 25 Feb 2003 08:38:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PDlhu29965 for sipping-archive@odin.ietf.org; Tue, 25 Feb 2003 08:47:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PDlhp29962 for ; Tue, 25 Feb 2003 08:47:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00838 for ; Tue, 25 Feb 2003 08:38:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PDSJp28405; Tue, 25 Feb 2003 08:28:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LGPbp02135 for ; Fri, 21 Feb 2003 11:25:37 -0500 Received: from newman.gte.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05308; Fri, 21 Feb 2003 11:17:58 -0500 (EST) Received: from rcmppc2.gte.com (rcmppc2.gte.com [132.197.73.30]) by newman.gte.com (8.9.1/8.9.1) with ESMTP id LAA26845; Fri, 21 Feb 2003 11:21:46 -0500 (EST) Message-Id: <5.1.1.6.0.20030221110917.04229140@pophost.gte.com> X-Sender: sjj0@pophost.gte.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 21 Feb 2003 11:22:08 -0500 To: Allison Mankin From: Stuart Jacobs Subject: Re: [Sipping] New version of the SIP-AAA reqs draft Cc: sipping@ietf.org, sip@ietf.org 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: , Allison, This material is part of ongoing efforts of Verizon and Verizon management to engage in thoughtful considerations of the fundamental changes and challenges facing the telecommunications industry. To meet its fiduciary responsibilities, management must explore all alternatives, even those that may appear highly speculative and hypothetical. Statements and representations contained herein are preliminary and/or tentative and should not be relied on unless approved by the appropriate Verizon governing body. The following represent the anticipated approach Verizon most likely will use. I cannot be more firm at this time as our architectural plans are not finalized. Verizon's current direction for our Next Generation Network (NGN) VoIP Services will likely use a challenge/response approach (ala. Radius) for authentication and access control between our SIP service customers and SIP Proxies. All our SIP service customers will probably go through SIP Proxies. We will not support SIP UA to SIP UA within our operational domain. Our SIP Proxies will likely authenticate themselves to other SIP Proxies and other back-office systems (OSSs, Application Servers, EMSs, etc.) by use of IPsec, specifically IKE combined with X.509v3 server certificates and ESP transport mode Null-encryption using HMAC-SHA1-96. Access controls (rights/policies) between our intermediate systems (incl. SIP Proxies, Gateways , etc.) are expected to be based on use of policy certificates. All policy and identity certificates are expected to be distributed via a redundant hierarchy of LDAP servers (repositories). Accounting data will most likely be compiled by our SIP Proxies and transferred to billing systems with authentication provided by IPsec. The actual billing data will probably be captured in the form of XML in conjunction with XML signatures (as defined by the W3C). Stu At 2/20/03 05:24 PM, you wrote: >Stu, > >You are not doing the usage accounting with Radius, then. > >It is only doing the remote access authentication? > >We can work with this scenario. Could you speak to this in >the open mailing list? I would like to rule out Radius for >call detail and usage-based accounting, but it is ok for the >other A's. > >Allison > > > Diameter in our Next Generation Network (NGN) VoIP Services. We will be > > doing our usage accounting within SIP Proxies and intend to transfer said > > accounting "call detail records" back to our billing OSSes via other > > protocols with IPsec providing authentication and confidentiality for > these > > transfers. We currently do not plan on any deployment of Diameter within > > Verizon's wireline NGN architecture. We will probably continue to use > > Radius for remote access authentication at the application layer for a > > number or years into the future. > > > > Stu Jacobs > > > > At 2/14/03 09:58 PM, you wrote: > > > > >Jiri, > > > > > >It always seems good to be able to stay with installed base, but > > >there's a factor against our supporting RADIUS drafts for SIP's > > >accounting - safety. Even though there is deployment, there are > > >some extremely bad cases of damage in production, and the IETF > > >has concluded that RADIUS is not suitable for usage-based accounting > > >(RFC2975). > > > > > >Unless there is no intention of having in SIP accounting usage-based, > > >monetary, auditable applications, RADIUS is not the solution. The > > >protocol just does not preserve a complete stream of reliable > > >accounting records that are auditable on any level, especially with > > >any roaming. As Bernard Aboba stated to this WG, quoting Mike O'Dell, > > >the use of RADIUS may even be illegal in situations where there is an > > >authority over the billing. Records are too easily lost by the > > >protocol. This is stated clearly by RFC2975. This is the reason why > > >the Operations and Mgt Area developed Diameter. On these technical* > > >grounds, that the RADIUS protocol does not have enough reliability, > > >the work must be based on the Diameter protocol, which is now > > >approved. Alternatively, work could be done that does not include > > >usage-based accounting, but this does not seem to be what is > > >envisioned in the SIPPING AAA requirements. > > > > > >Allison > > > > > >P.S. There's a current investigation of RADIUS compatibility mode > > >in Diameter for this - more needs to be thought about it. > > > > > > > > At 07:46 PM 2/11/2003, john.loughney@nokia.com wrote: > > > > >Hi Henry, > > > > > > > > > >> >but one option is develop a solution using > > > > >> > Diameter in RADIUS-compatibility mode. > > > > >> > > > > >> OK, this is better than nothing. We'll take what we can :-) > > > > >> > > > > >> As mentioned, the installed base is RADIUS, no matter how > > > > >> voluminous the DIAMETER literature may be. > > > > > > > > > >I think the issues is that the IETF should recommend what is the > > > > >right thing to do & why. If people choose to do something else, > > > > >well, that is life. > > > > > > > > Remember that running code does not necessarily mean something known > > > > to compile -- that is something known to be deployed. > > > > > > > > >I understand what you are asking but I do note that some > > > > >people have thought that the potential for AAA is much greater > > > > >than the existing installed base. > > > > > > > > I actually think that the deployment argument is a very important one. > > > > > > > > -Jiri > > > > > > > > _______________________________________________ > > > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > > > This list is for NEW development of the 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 > > > > ========================== > > Stuart Jacobs CISSP > > PMTS - Sr. Technologist > > Verizon Laboratories > > 40 Sylvan Road Waltham, MA 02451-1128 USA > > telephone: (781) 466-3076 fax: (781) 466-2838 > > stu.jacobs@labs.gte.com sjj0@labs.gte.com stu.jacobs@verizon.com > > ========================== > > ========================== Stuart Jacobs CISSP PMTS - Sr. Technologist Verizon Laboratories 40 Sylvan Road Waltham, MA 02451-1128 USA telephone: (781) 466-3076 fax: (781) 466-2838 stu.jacobs@labs.gte.com sjj0@labs.gte.com stu.jacobs@verizon.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 mailnull@www1.ietf.org Tue Feb 25 09:16:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01668 for ; Tue, 25 Feb 2003 09:16:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PEPSi32568 for sipping-archive@odin.ietf.org; Tue, 25 Feb 2003 09:25:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PEPSp32565 for ; Tue, 25 Feb 2003 09:25:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01649 for ; Tue, 25 Feb 2003 09:15:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PEOlp32459; Tue, 25 Feb 2003 09:24:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PELpp32362 for ; Tue, 25 Feb 2003 09:21:51 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01571; Tue, 25 Feb 2003 09:12:18 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.36 #1 (Debian)) id 18nfsR-0002a7-00; Tue, 25 Feb 2003 16:16:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15963.31403.288541.988747@harjus.eng.song.fi> Date: Tue, 25 Feb 2003 16:16:11 +0200 To: Stuart Jacobs Cc: Allison Mankin , sipping@ietf.org, sip@ietf.org Subject: [Sip] Re: [Sipping] New version of the SIP-AAA reqs draft In-Reply-To: <5.1.1.6.0.20030221110917.04229140@pophost.gte.com> References: <5.1.1.6.0.20030221110917.04229140@pophost.gte.com> X-Mailer: VM 7.07 under Emacs 21.2.1 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit nobody replied to my bye question, but after some more thinking i have myself come to the conclusion that it is impossible for a regular sip proxy without a dialog state or a crypto identification of all requests from its clients to do any accounting at all. so it would be important for a sip-aaa requirements draft to list the preconditions for sip accounting. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Feb 25 10:16:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02907 for ; Tue, 25 Feb 2003 10:16:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PFPVq04210 for sipping-archive@odin.ietf.org; Tue, 25 Feb 2003 10:25:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PFPVp04207 for ; Tue, 25 Feb 2003 10:25:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02894 for ; Tue, 25 Feb 2003 10:15:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PFObp04155; Tue, 25 Feb 2003 10:24:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PFNep04114 for ; Tue, 25 Feb 2003 10:23:40 -0500 Received: from bdsl.greycouncil.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02877 for ; Tue, 25 Feb 2003 10:14:05 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h1PFHmLc023366; Tue, 25 Feb 2003 09:17:49 -0600 From: "Dean Willis" To: , "'Henry Sinnreich'" Cc: "'Stuart Jacobs'" , "'Allison Mankin'" , , "'Henning Schulzrinne'" Subject: RE: [Sipping] New version of the SIP-AAA reqs draft Date: Tue, 25 Feb 2003 09:17:41 -0600 Message-ID: <001f01c2dce1$0b52e710$ee036e3f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3E556C0D.6060403@piuha.net> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1PFNep04115 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Jari asked: > Henry Sinnreich wrote: > > Is there any service provider planning to use SIP-DIAMETER? If yes, > > please speak up. > > Any of the 3G operators count for this? I'm not sure how many > of the subscribe to this group though, even if their vendors do... Of the two 3G deployments I have my hands in daily, neither uses DIAMETER for authentication. One uses a database accessible by a proxy (using conventional database interfaces), and the other uses RADIUS. Both use database methods for accounting. This is not to say that they might not use DIAMETER someday. It's just not in their existing networks, and most of todays 3G deployments are coupled to older infrastructure elements, because that makes business sense. I think most of the mobile operators plan on using DIAMETER in the future, some as soon as within the next six months. Making DIAMETER work right will make supporting a couple of hundred million subscribers much easier for them. However, I think we can show existence proofs that RADIUS can be made to do authentication for SIP. Since there IS a constituency, tackling this effort might be a reasonable thing to do in the IETF. Having done RADIUS accounting for several large ISPs, I can also say that only someone with a far higher pain tolerance than mine would try to use RADIUS for time-based usage accounting. Something about unreliable record delivery causes many annoying glitches. I don't want to go there. -- 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 mailnull@www1.ietf.org Tue Feb 25 10:28:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03198 for ; Tue, 25 Feb 2003 10:28:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PFbhq05559 for sipping-archive@odin.ietf.org; Tue, 25 Feb 2003 10:37:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PFbhp05556 for ; Tue, 25 Feb 2003 10:37:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03186 for ; Tue, 25 Feb 2003 10:28:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PFaWp04727; Tue, 25 Feb 2003 10:36:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PFX6p04493 for ; Tue, 25 Feb 2003 10:33:06 -0500 Received: from mail1-0.chcgil.ameritech.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03022; Tue, 25 Feb 2003 10:23:31 -0500 (EST) Received: from repligate ([67.36.180.12]) by mail1-0.chcgil.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20030225152724.CYNZ29339.mail1-0.chcgil.ameritech.net@repligate>; Tue, 25 Feb 2003 09:27:24 -0600 Message-ID: <0ae201c2dce2$6b372190$8500a8c0@repligate> From: "Jim Fleming" To: "Stuart Jacobs" Cc: , References: <5.1.1.6.0.20030221110917.04229140@pophost.gte.com> Date: Tue, 25 Feb 2003 09:27:32 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sipping] "...management must explore all alternatives..." ?? Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit From: "Stuart Jacobs" "...management must explore all alternatives..." ==== Do you mean "explore all alternatives" provided by the I* society...(small s...aka The Big Lie Society)... ...after ethnic cleansing has been done by the I* society thugs...? ----- Original Message ----- From: "Stuart Jacobs" To: "Allison Mankin" Cc: ; Sent: Friday, February 21, 2003 10:22 AM Subject: [Sip] Re: [Sipping] New version of the SIP-AAA reqs draft > Allison, > > This material is part of ongoing efforts of Verizon and Verizon management > to engage in thoughtful considerations of the fundamental changes and > challenges facing the telecommunications industry. To meet its fiduciary > responsibilities, management must explore all alternatives, even those that > may appear highly speculative and hypothetical. Statements and > representations contained herein are preliminary and/or tentative and > should not be relied on unless approved by the appropriate Verizon > governing body. The following represent the anticipated approach Verizon > most likely will use. I cannot be more firm at this time as our > architectural plans are not finalized. > > Verizon's current direction for our Next Generation Network (NGN) VoIP > Services will likely use a challenge/response approach (ala. Radius) for > authentication and access control between our SIP service customers and SIP > Proxies. All our SIP service customers will probably go through SIP > Proxies. We will not support SIP UA to SIP UA within our operational > domain. Our SIP Proxies will likely authenticate themselves to other SIP > Proxies and other back-office systems (OSSs, Application Servers, EMSs, > etc.) by use of IPsec, specifically IKE combined with X.509v3 server > certificates and ESP transport mode Null-encryption using > HMAC-SHA1-96. Access controls (rights/policies) between our intermediate > systems (incl. SIP Proxies, Gateways , etc.) are expected to be based on > use of policy certificates. All policy and identity certificates are > expected to be distributed via a redundant hierarchy of LDAP servers > (repositories). Accounting data will most likely be compiled by our SIP > Proxies and transferred to billing systems with authentication provided by > IPsec. The actual billing data will probably be captured in the form of > XML in conjunction with XML signatures (as defined by the W3C). > > Stu > > At 2/20/03 05:24 PM, you wrote: > >Stu, > > > >You are not doing the usage accounting with Radius, then. > > > >It is only doing the remote access authentication? > > > >We can work with this scenario. Could you speak to this in > >the open mailing list? I would like to rule out Radius for > >call detail and usage-based accounting, but it is ok for the > >other A's. > > > >Allison > > > > > Diameter in our Next Generation Network (NGN) VoIP Services. We will be > > > doing our usage accounting within SIP Proxies and intend to transfer said > > > accounting "call detail records" back to our billing OSSes via other > > > protocols with IPsec providing authentication and confidentiality for > > these > > > transfers. We currently do not plan on any deployment of Diameter within > > > Verizon's wireline NGN architecture. We will probably continue to use > > > Radius for remote access authentication at the application layer for a > > > number or years into the future. > > > > > > Stu Jacobs > > > > > > At 2/14/03 09:58 PM, you wrote: > > > > > > >Jiri, > > > > > > > >It always seems good to be able to stay with installed base, but > > > >there's a factor against our supporting RADIUS drafts for SIP's > > > >accounting - safety. Even though there is deployment, there are > > > >some extremely bad cases of damage in production, and the IETF > > > >has concluded that RADIUS is not suitable for usage-based accounting > > > >(RFC2975). > > > > > > > >Unless there is no intention of having in SIP accounting usage-based, > > > >monetary, auditable applications, RADIUS is not the solution. The > > > >protocol just does not preserve a complete stream of reliable > > > >accounting records that are auditable on any level, especially with > > > >any roaming. As Bernard Aboba stated to this WG, quoting Mike O'Dell, > > > >the use of RADIUS may even be illegal in situations where there is an > > > >authority over the billing. Records are too easily lost by the > > > >protocol. This is stated clearly by RFC2975. This is the reason why > > > >the Operations and Mgt Area developed Diameter. On these technical* > > > >grounds, that the RADIUS protocol does not have enough reliability, > > > >the work must be based on the Diameter protocol, which is now > > > >approved. Alternatively, work could be done that does not include > > > >usage-based accounting, but this does not seem to be what is > > > >envisioned in the SIPPING AAA requirements. > > > > > > > >Allison > > > > > > > >P.S. There's a current investigation of RADIUS compatibility mode > > > >in Diameter for this - more needs to be thought about it. > > > > > > > > > > At 07:46 PM 2/11/2003, john.loughney@nokia.com wrote: > > > > > >Hi Henry, > > > > > > > > > > > >> >but one option is develop a solution using > > > > > >> > Diameter in RADIUS-compatibility mode. > > > > > >> > > > > > >> OK, this is better than nothing. We'll take what we can :-) > > > > > >> > > > > > >> As mentioned, the installed base is RADIUS, no matter how > > > > > >> voluminous the DIAMETER literature may be. > > > > > > > > > > > >I think the issues is that the IETF should recommend what is the > > > > > >right thing to do & why. If people choose to do something else, > > > > > >well, that is life. > > > > > > > > > > Remember that running code does not necessarily mean something known > > > > > to compile -- that is something known to be deployed. > > > > > > > > > > >I understand what you are asking but I do note that some > > > > > >people have thought that the potential for AAA is much greater > > > > > >than the existing installed base. > > > > > > > > > > I actually think that the deployment argument is a very important one. > > > > > > > > > > -Jiri > > > > > > > > > > _______________________________________________ > > > > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > > > > This list is for NEW development of the 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 > > > > > > ========================== > > > Stuart Jacobs CISSP > > > PMTS - Sr. Technologist > > > Verizon Laboratories > > > 40 Sylvan Road Waltham, MA 02451-1128 USA > > > telephone: (781) 466-3076 fax: (781) 466-2838 > > > stu.jacobs@labs.gte.com sjj0@labs.gte.com stu.jacobs@verizon.com > > > ========================== > > > > > ========================== > Stuart Jacobs CISSP > PMTS - Sr. Technologist > Verizon Laboratories > 40 Sylvan Road Waltham, MA 02451-1128 USA > telephone: (781) 466-3076 fax: (781) 466-2838 > stu.jacobs@labs.gte.com sjj0@labs.gte.com stu.jacobs@verizon.com > ========================== > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Feb 25 11:43:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05918 for ; Tue, 25 Feb 2003 11:43:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PGr5S11286 for sipping-archive@odin.ietf.org; Tue, 25 Feb 2003 11:53:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PGr5p11283 for ; Tue, 25 Feb 2003 11:53:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05891 for ; Tue, 25 Feb 2003 11:43:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PGpup11210; Tue, 25 Feb 2003 11:51:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PGo6p11147 for ; Tue, 25 Feb 2003 11:50:06 -0500 Received: from radvpost.RADVISION.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05798; Tue, 25 Feb 2003 11:40:27 -0500 (EST) Received: by radvpost.radvision.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Feb 2003 11:43:11 -0500 Message-ID: From: Orit Levin To: "'aroychow@hss.hns.com'" , shaj@cisco.com Cc: sipping@ietf.org, sipping-admin@ietf.org Subject: RE: [Sipping] Comments on draft-rosenberg-sipping-conferencing-fr amework-01.txt Date: Tue, 25 Feb 2003 11:43:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DCEC.FB97D720" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2DCEC.FB97D720 Content-Type: text/plain I agree with most of Arjun's analysis. My comments are inline (OL:). Orit. -----Original Message----- From: aroychow@hss.hns.com [mailto:aroychow@hss.hns.com] Sent: Saturday, February 22, 2003 10:38 AM To: shaj@cisco.com Cc: sipping@ietf.org; sipping-admin@ietf.org Subject: Re: [Sipping] Comments on draft-rosenberg-sipping-conferencing-framework-01.txt ---skip * Forward the call using the standard Refer mechanism to the new Focus with the Unique URI. You may also want to read http://www.iptel.org/info/players/ietf/conferencing/draft-johnston-sipping-c c-conferencing-01.txt. Its provides the definition of a conference Factory URI, which could be used to create new conferences and their Focii. Note that when you send an INVITE to a factory URI, that entity returns the actual Conference-URI in the Contact header. ---skip OL: The cc-conferencing does take into consideration this scenario i.e. Referring to a focus by a conference factory. The statement in 3.2 "the Conference Factory URI and the newly created focus URI MAY resolve to different physical devices" targets the exact case. We even had this scenario included in one of the intermediate versions of the draft. We can restore the example if the readers find it helpful. The advantage of doing this is that I could have multiple Conference servers that are running that are registered their master focus. We can implement Load Balancing across Conference servers without the UA realizing it as it is not connecting to a specific Focus on a specific server. A second advantage is that if in the course of a meeting if the focus were to go down or the server went down the participants can attempt to rejoin the call. In such a case the Master Focus would see that the Conference specific focus is down and recreate it allowing users to quickly rejoin the conference. Of course one needs to work out the details of the communication and keepalive between the Master Focus and the Conference focus it creates. OL: I agree that this is one of the possible ways to implement Load Balancing. The Factory-Focus "decomposition" allows for that without requiring the factory to forward SIP messages during stable sessions. I am much less sure about the second advantage - redundancy. It is still can be implemented with additional interface between the factory and its focuses (as Shiva points out) but I wouldn't impose standard SIP procedures/conventions in order to implement it - there are so many (proprietary and standard) ways to address redundancy that I wouldn't put it as a requirement for SIP conferencing. ...skip Instead of dealing with Conference aware UA's and Conference Unaware UA's we could assume all participants in the Conference to be Conference Aware. ...skip It is extremely important to acknowledge conference-unaware endpoints. ...skip OL: One of the first requirements (in the conferencing-requirements draft) is to be able to accommodate basic UAs in a SIP conference. That being said based on the chosen approach (and the examined scenarios) on the SIP level there is no need for differentiation between conference-aware and conference-unaware participants neither for a conference factory nor for a focus. ...skip ...skip Now a question again for the authors of draft-johnston-sipping-cc-conferencing-01.txt: * section 4.5 callflow - you show alice sending an invite to a conf-factory URI but the ladder diagram shows it being received by a 'Focus'. The definition of a focus 3.1 Focus UA A focus, as defined in the framework, hosts a SIP conference and maintains a SIP signaling relationship with each participant in the conference. A focus contains a conference-aware user agent that supports the conferencing call control conventions as defined in this document. Since a 'Focus' hosts 'a specific' conference, I find it a little disconcerting that the call flows show messages with a factory-URI reaching a focus. I thought it may be clearer, if we limit a 'focus' to be the target of a specific URI meant for a specific conference. If a person sends an INVITE to a factory-URI or a 'conf-app-URI' < like an IVR etc which then contacts a Factory after auth etc> it should not be received by a Focus, should it ? OL: I agree with this comment - the picture on its own is "disconcerting". In the shown scenario the factory and the focus are logical entities that located in a single physical device (called "focus" in the picture). We will either rearrange the drawing or add a text clarifying the case. Thanks you, guys, for all your comments, Orit. ------_=_NextPart_001_01C2DCEC.FB97D720 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

I agree with most of Arjun's analysis. My comments are inline (OL:).

 

=

Orit.

 

=

-----Original Message-----
From: = aroychow@hss.hns.com [mailto:aroychow@hss.hns.com]
Sent: Saturday, February = 22, 2003 10:38 AM
To: shaj@cisco.com
Cc: = sipping@ietf.org; = sipping-admin@ietf.org
Subject: Re: [Sipping] = Comments on draft-rosenberg-sipping-conferencing-framework-01.txt=

 

---skip
 * Forward the call using = the standard Refer mechanism to the new Focus with the Unique URI.
 
<ARC>
 You may also want to read http://www.iptel.org/info/players/ietf/conferencing/draft-johnston-sippi= ng-cc-conferencing-01.txt.
Its provides the definition of a conference Factory URI, which could be = used to create new conferences and their Focii.
Note that when you send an INVITE to a factory URI, that entity returns the = actual Conference-URI in the Contact header.

---skip

</ARC> =

OL: The cc-conferencing does take into consideration this = scenario i.e. Referring to a focus by a conference = factory. The statement in 3.2 "the Conference Factory URI and the newly created = focus URI MAY resolve to different physical devices" targets the exact case. = We even had this scenario included in one of the intermediate versions of = the draft. We can restore the example if the readers find it helpful. =

 

The advantage of doing this is that I could have = multiple Conference servers that are running that are registered their master = focus.

 

We can implement Load Balancing across Conference = servers without the UA realizing it as it is not connecting to a = specific Focus on a specific server. A second advantage is that if in the course = of a meeting if the focus were to go down or the server went down the = participants can attempt to rejoin the call. In such a case the Master Focus would = see that the Conference specific focus is down and recreate it allowing users to = quickly rejoin the conference.

 

Of course one needs to work out the details of the communication and keepalive between the = Master Focus and the Conference focus it creates.

 

 OL: I agree that this is one of the possible ways to = implement Load Balancing. The Factory-Focus "decomposition" allows for that without requiring the factory to forward SIP messages during stable = sessions. I am much less sure about the second advantage - redundancy. It is still can be implemented with additional interface between the factory and = its focuses (as Shiva points out) but I wouldn't impose standard SIP = procedures/conventions in order to implement it - there are so many (proprietary and standard) = ways to address redundancy that I wouldn't put it as a requirement for SIP conferencing.

 

...skip
Instead of dealing with Conference aware UA's and Conference = Unaware UA's we could assume all participants in the Conference to be = Conference Aware.

...skip

<ARC> =
 It is extremely important to acknowledge = conference-unaware endpoints.

...skip

</ARC> =

OL: One of the first requirements (in the conferencing-requirements draft) is = to be able to accommodate basic UAs in a SIP = conference. That being said based on the chosen approach (and the examined = scenarios) on the SIP level there is no need for differentiation between = conference-aware and conference-unaware participants neither for a conference factory nor = for a focus.

...skip

<ARC> =

...skip
 Now a = question again for the authors of =  draft-johnston-sipping-cc-conferencing-01.txt:

* section 4.5 callflow - you show alice sending an invite to a = conf-factory URI but the ladder diagram shows it being received by a = 'Focus'.
The definition of a focus


3.1 Focus UA

  A focus, as defined in the framework, hosts a SIP conference = and
  maintains a SIP signaling relationship with each participant in = the
  conference. A focus contains a conference-aware user agent = that
  supports the conferencing call control conventions as defined in = this
  document.

Since a 'Focus' hosts 'a specific' conference, I find it a little = disconcerting
that the call flows show messages with a factory-URI reaching a focus. I = thought
it may be clearer, if we limit a 'focus' to be the target of a specific URI = meant
for a specific conference. If a person sends an INVITE to a factory-URI = or
a 'conf-app-URI' < like an IVR etc which then contacts a Factory after = auth etc>
it should not be received by a Focus, should it ?

</ARC>

OL:  I agree with this comment - the = picture on its own is "disconcerting". In the shown scenario the factory and the focus are logical entities that located in a single physical = device (called "focus" in the picture). We will either rearrange the drawing or add a text clarifying the case.

Thanks you, = guys, for all your comments,

Orit. =

------_=_NextPart_001_01C2DCEC.FB97D720-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Feb 26 01:23:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00210 for ; Wed, 26 Feb 2003 01:23:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1Q6Wx701721 for sipping-archive@odin.ietf.org; Wed, 26 Feb 2003 01:32:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1Q6Wxp01718 for ; Wed, 26 Feb 2003 01:32:59 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00203 for ; Wed, 26 Feb 2003 01:23:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1Q6WBp01703; Wed, 26 Feb 2003 01:32:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1Q6Urp01637 for ; Wed, 26 Feb 2003 01:30:53 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00183 for ; Wed, 26 Feb 2003 01:21:01 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.58]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h1Q6OxYH003264 for ; Wed, 26 Feb 2003 01:24:59 -0500 (EST) Message-ID: <3E5C5DB4.1030703@dynamicsoft.com> Date: Wed, 26 Feb 2003 01:24:52 -0500 From: Jonathan Rosenberg Organization: dynamicsoft 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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] new I-D on the "grand unified theory of nat traversal" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, If you take a look at draft-ietf-sipping-nat-scenarios, the general conclusoin you come to is "what a mess!". There are a million different solutions, and some of them work in some cases some times. There is no unifying mechanism which works very well in almost all of the cases. I have been working on a methodology for integrating the various pieces into a semi-coherent story about what clients need to do in order to handle a wide variety of situations. I have written it up, and submitted as an I-D. Until it appears in the archives, you can pick it up at: http://www.jdrosen.net/papers/draft-rosenberg-sipping-ice-00.txt http://www.jdrosen.net/papers/draft-rosenberg-sipping-ice-00.html Its called Interactive Connectivity Establishment (ICE). Its a bit rough around the edges, and needs a lot more examples and use cases, but hopefully you will get the idea. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Feb 26 05:42:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00402 for ; Wed, 26 Feb 2003 05:42:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QApVa29767 for sipping-archive@odin.ietf.org; Wed, 26 Feb 2003 05:51:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QApVp29764 for ; Wed, 26 Feb 2003 05:51:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00388 for ; Wed, 26 Feb 2003 05:41:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QAohp29727; Wed, 26 Feb 2003 05:50:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QAnap29655 for ; Wed, 26 Feb 2003 05:49:36 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00314 for ; Wed, 26 Feb 2003 05:39:37 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1QAhFnS009770; Wed, 26 Feb 2003 11:43:15 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVKM6DJ; Wed, 26 Feb 2003 11:43:14 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h1QAhEll016045; Wed, 26 Feb 2003 12:43:14 +0200 (EET) Message-ID: <3E5C9A41.797F33F5@lmf.ericsson.se> Date: Wed, 26 Feb 2003 12:43:13 +0200 X-Sybari-Trust: 82c866b7 9ffcebbb a5ee123c 00000138 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sipping@ietf.org CC: Henning Schulzrinne , petri.koskelainen@nokia.com, xiaotaow@cs.columbia.edu Subject: Re: [Sipping] I-D ACTION:draft-wu-sipping-floor-control-03.txt References: <200301161306.IAA08897@ietf.org> 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, the definition of the FL semantics for the grouping framework needs more elaboration. You need to say whether or not only one control line is allowed per group and include an IANA considerations section as follows: IANA Considerations IANA needs to register the following new "semantics" attribute for the SDP grouping framework [RFC3388]: Semantics Token Reference ------------------- ----- --------- Floor control FL [RFCxxxx] It should be registered in the SDP parameters registry (http://www.iana.org/assignments/sdp-parameters) under Semantics for the "group" SDP Attribute. You should also add IANA considerations for a=moderate In Section 8.1, you write: "the conference server uses a=moderated line to mute all media tools of the participant". Does the conference server set to inactive the SDP direction attributes as well or it leaves them as they are (e.g., sendrecv)? Thanks, Gonzalo Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Use of Session Initiation Protocol (SIP) and Simple > Object Access > Protocol (SOAP) for Conference Floor Control > Author(s) : X. Wu et al. > Filename : draft-wu-sipping-floor-control-03.txt > Pages : 33 > Date : 2003-1-15 > > During a conference, floor control coordinates simultaneous access to > shared resource in multimedia conferences. Floor control allows > applications and users to gain safe and mutually exclusive or non- > exclusive access to the shared resources. This document defines an > approach of using Session Initiation Protocol (SIP) event > notification mechanism and Simple Object Access Protocol (SOAP) to > perform floor control. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-wu-sipping-floor-control-03.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-wu-sipping-floor-control-03.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-wu-sipping-floor-control-03.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ------------------------------------------------------------------------ -- 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 mailnull@www1.ietf.org Wed Feb 26 06:22:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01198 for ; Wed, 26 Feb 2003 06:22:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QBVq532189 for sipping-archive@odin.ietf.org; Wed, 26 Feb 2003 06:31:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QBVqp32186 for ; Wed, 26 Feb 2003 06:31:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01191 for ; Wed, 26 Feb 2003 06:21:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QBVIp32165; Wed, 26 Feb 2003 06:31:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QBUup32121 for ; Wed, 26 Feb 2003 06:30:56 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01174 for ; Wed, 26 Feb 2003 06:20:56 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1QBOonS021922; Wed, 26 Feb 2003 12:24:50 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id F4Q8RWRM; Wed, 26 Feb 2003 12:24:50 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h1QBOoll018726; Wed, 26 Feb 2003 13:24:50 +0200 (EET) Message-ID: <3E5CA400.45D287C7@lmf.ericsson.se> Date: Wed, 26 Feb 2003 13:24:48 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: john.elwell@siemens.com, frank.derks@philips.com, olivier.rousseau@col.bsf.alcatel.fr, patrick.mourot@sxb.bsf.alcatel.fr CC: Jon Peterson , sipping Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Overlap in QSIG 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, I have noticed that the SIP-QSIG draft describes how to use overlap signalling in a SIP network. http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-00.txt I believe that this draft should not describe overlap procedures. It should reference the overlap mapping draft instead: http://www.ietf.org/internet-drafts/draft-ietf-sipping-overlap-04.txt A short section explaining the differences between overlap in QSIG and in ISUP (e.g., INFORMATION message instead of SAM) is OK, but I would not like to see the whole overlap mapping explained here again. We have gone thru some pain adding several considerations and motivational text to the overlap draft so that we have rough consensus on it, and we do not need to re-create that here again. Thanks, Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Feb 26 07:28:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02396 for ; Wed, 26 Feb 2003 07:28:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QCbr604549 for sipping-archive@odin.ietf.org; Wed, 26 Feb 2003 07:37:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QCbrp04546 for ; Wed, 26 Feb 2003 07:37:53 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02391 for ; Wed, 26 Feb 2003 07:27:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QCbBp04096; Wed, 26 Feb 2003 07:37:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QCaJp03751 for ; Wed, 26 Feb 2003 07:36:19 -0500 Received: from mailgate.siemenscomms.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02371 for ; Wed, 26 Feb 2003 07:26:18 -0500 (EST) Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #45905) id <0HAX00K011DQCZ@siemenscomms.co.uk> for sipping@ietf.org; Wed, 26 Feb 2003 12:29:50 +0000 (GMT) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #45905) with ESMTP id <0HAX00JMS1DQWM@siemenscomms.co.uk>; Wed, 26 Feb 2003 12:29:50 +0000 (GMT) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Feb 2003 12:30:12 +0000 Content-return: allowed Date: Wed, 26 Feb 2003 12:30:27 +0000 From: "Elwell, John" To: "'Gonzalo Camarillo'" , frank.derks@philips.com, olivier.rousseau@col.bsf.alcatel.fr, patrick.mourot@sxb.bsf.alcatel.fr Cc: Jon Peterson , sipping Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Subject: [Sipping] RE: Overlap in QSIG 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: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Gonzallo, Well, we tried to do this originally, but the overlap draft was a moving target and, as you point out, was ISUP-specific rather than generic. Even now the overlap draft is still work in progress rather than an RFC - when do you envisage completion? John Elwell - Technical Consultant Tel: +44 (0)115 943 4989 Fax: +44 (0)115 943 4969 e-mail: mailto:john.elwell@siemens.com web: http://www.siemens-design-services.com Siemens Communications Technology Drive, Beeston, Nottingham, NG9 1LA. England. "Siemens Communications - a division of Siemens plc, Registered No: 727817, England. Registered office: Siemens House, Oldbury, Bracknell, Berkshire, RG12 8FZ. This communication contains information which is confidential and may also be privileged. It is for the exclusive use of the addressee. If you are not the addressee please note that any distribution, reproduction, copying, publication or use of this communication or the information is prohibited. If you have received this communication in error, please contact us immediately and also delete the communication from your computer. We accept no liability for any loss or damage suffered by any person arising from use of this e-mail." > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: 26 February 2003 11:25 > To: john.elwell@siemens.com; frank.derks@philips.com; > olivier.rousseau@col.bsf.alcatel.fr; patrick.mourot@sxb.bsf.alcatel.fr > Cc: Jon Peterson; sipping > Subject: Overlap in QSIG draft > > > Hello, > > I have noticed that the SIP-QSIG draft describes how to use overlap > signalling in a SIP network. > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-00.txt > > I believe that this draft should not describe overlap procedures. It > should reference the overlap mapping draft instead: > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-overlap-04.txt > > A short section explaining the differences between overlap in QSIG and > in ISUP (e.g., INFORMATION message instead of SAM) is OK, but I would > not like to see the whole overlap mapping explained here > again. We have > gone thru some pain adding several considerations and > motivational text > to the overlap draft so that we have rough consensus on it, and we do > not need to re-create that here again. > > Thanks, > > Gonzalo > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Feb 26 07:33:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02483 for ; Wed, 26 Feb 2003 07:33:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QCgo104739 for sipping-archive@odin.ietf.org; Wed, 26 Feb 2003 07:42:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QCgop04736 for ; Wed, 26 Feb 2003 07:42:50 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02462 for ; Wed, 26 Feb 2003 07:32:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QCg6p04722; Wed, 26 Feb 2003 07:42:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QCfQp04673 for ; Wed, 26 Feb 2003 07:41:26 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02448 for ; Wed, 26 Feb 2003 07:31:24 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1QCZInS010871; Wed, 26 Feb 2003 13:35:18 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FD4HM686; Wed, 26 Feb 2003 13:35:18 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h1QCZIll023354; Wed, 26 Feb 2003 14:35:18 +0200 (EET) Message-ID: <3E5CB484.B9A35ADE@lmf.ericsson.se> Date: Wed, 26 Feb 2003 14:35:16 +0200 X-Sybari-Trust: 8463fd3f 9ffcebbb 7a95d2f4 00000138 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Elwell, John" CC: frank.derks@philips.com, olivier.rousseau@col.bsf.alcatel.fr, patrick.mourot@sxb.bsf.alcatel.fr, Jon Peterson , sipping References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: Overlap in QSIG 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit John, the last version of the draft (which was released two or three weeks ago) will be presented to the IESG shortly. I believe that we have addressed all the issues that were raised... the document could be approved in a reasonably short period of time. We'll keep you updated. Gonzalo "Elwell, John" wrote: > > Gonzallo, > > Well, we tried to do this originally, but the overlap draft was a moving > target and, as you point out, was ISUP-specific rather than generic. Even > now the overlap draft is still work in progress rather than an RFC - when do > you envisage completion? > > John Elwell - Technical Consultant > Tel: +44 (0)115 943 4989 > Fax: +44 (0)115 943 4969 > e-mail: mailto:john.elwell@siemens.com > web: http://www.siemens-design-services.com > > Siemens Communications > Technology Drive, Beeston, Nottingham, NG9 1LA. England. > > "Siemens Communications - a division of Siemens plc, Registered No: > 727817, England. Registered office: Siemens House, Oldbury, Bracknell, > Berkshire, RG12 8FZ. > This communication contains information which is confidential and may > also be privileged. It is for the exclusive use of the addressee. If you > are not the addressee please note that any distribution, reproduction, > copying, publication or use of this communication or the information is > prohibited. If you have received this communication in error, please > contact us immediately and also delete the communication from your > computer. We accept no liability for any loss or damage suffered by any > person arising from use of this e-mail." > > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: 26 February 2003 11:25 > > To: john.elwell@siemens.com; frank.derks@philips.com; > > olivier.rousseau@col.bsf.alcatel.fr; patrick.mourot@sxb.bsf.alcatel.fr > > Cc: Jon Peterson; sipping > > Subject: Overlap in QSIG draft > > > > > > Hello, > > > > I have noticed that the SIP-QSIG draft describes how to use overlap > > signalling in a SIP network. > > > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-00.txt > > > > I believe that this draft should not describe overlap procedures. It > > should reference the overlap mapping draft instead: > > > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-overlap-04.txt > > > > A short section explaining the differences between overlap in QSIG and > > in ISUP (e.g., INFORMATION message instead of SAM) is OK, but I would > > not like to see the whole overlap mapping explained here > > again. We have > > gone thru some pain adding several considerations and > > motivational text > > to the overlap draft so that we have rough consensus on it, and we do > > not need to re-create that here again. > > > > Thanks, > > > > Gonzalo > > -- 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 mailnull@www1.ietf.org Wed Feb 26 09:03:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05494 for ; Wed, 26 Feb 2003 09:03:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QECen11145 for sipping-archive@odin.ietf.org; Wed, 26 Feb 2003 09:12:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QECep11142 for ; Wed, 26 Feb 2003 09:12:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05438 for ; Wed, 26 Feb 2003 09:02:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QEBwp10996; Wed, 26 Feb 2003 09:11:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QEAbp10870 for ; Wed, 26 Feb 2003 09:10:37 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05010; Wed, 26 Feb 2003 09:00:35 -0500 (EST) Message-Id: <200302261400.JAA05010@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 26 Feb 2003 09:00:35 -0500 Subject: [Sipping] I-D ACTION:draft-jain-sipping-persistent-conn-reqs-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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Persistent Connection Management in the Session Initiation Protocol (SIP) Author(s) : R. Jain, V. Gurbani Filename : draft-jain-sipping-persistent-conn-reqs-00.txt Pages : 15 Date : 2003-2-25 SIP over connection-oriented transport protocol based systems are likely to face certain distinct performance and behavioral issues that are not manifest when SIP is transported over connectionless protocols. Allowing SIP entities to mutually conserve connections over a predictable, extended period of time is one of the leading requirements to help SIP entities deliver their optimal performance in the network. Overall, this document contemplates transport layer connection management issues relating to SIP. Requirements and potential solutions for introducing a backward compatible notion of persistent connections in SIP are presented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jain-sipping-persistent-conn-reqs-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-jain-sipping-persistent-conn-reqs-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-jain-sipping-persistent-conn-reqs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-25160143.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-jain-sipping-persistent-conn-reqs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-jain-sipping-persistent-conn-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-25160143.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Feb 26 11:10:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14028 for ; Wed, 26 Feb 2003 11:10:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QGKDB22128 for sipping-archive@odin.ietf.org; Wed, 26 Feb 2003 11:20:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QGKDp22123 for ; Wed, 26 Feb 2003 11:20:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13954 for ; Wed, 26 Feb 2003 11:10:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QGJCp21941; Wed, 26 Feb 2003 11:19:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QGE1p21671 for ; Wed, 26 Feb 2003 11:14:01 -0500 Received: from dgesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13774; Wed, 26 Feb 2003 11:03:56 -0500 (EST) Received: from pmismtp06.wcomnet.com ([166.38.62.54]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0HAX00FESBBBFL@firewall.wcom.com>; Wed, 26 Feb 2003 16:04:23 +0000 (GMT) Received: from pmismtp06.wcomnet.com by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HAX00M01BBB3Q@pmismtp06.wcomnet.com>; Wed, 26 Feb 2003 16:04:23 +0000 (GMT) Received: from hsinnreich2 ([166.50.97.127]) by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HAX00L3JBBAHT@pmismtp06.wcomnet.com>; Wed, 26 Feb 2003 16:04:23 +0000 (GMT) Date: Wed, 26 Feb 2003 10:04:22 -0600 From: Henry Sinnreich In-reply-to: <3E5CC3DB.20706@polytech.univ-nantes.fr> To: "'Antoine Duval'" , sip@ietf.org, sipping@ietf.org Cc: Alan Johnston , Rohan Mahy , Eric Burger Message-id: <004d01c2ddb0$ba9fc290$bd8332a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Subject: [Sipping] RE: [Sip] whiteboard Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I believe the shared whiteboard is of special interest to the conferencing design team of the SIPPING WG - where this belongs BTW. Thanks, Henry Henry Sinnreich WorldCom 400 International Parkway Richardson, Texas 75081 USA > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Antoine Duval > Sent: Wednesday, February 26, 2003 7:41 AM > To: sip@ietf.org > Subject: [Sip] whiteboard > > > Hi everybody ! > > I'm searching information for developping a shared whiteboard > (protocol > and application) with sip, but i'm not satisfied of results... > > That why, i'm posting this email here, in case you can help me. > > Any idea ? > > Antoine > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Feb 26 11:40:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15150 for ; Wed, 26 Feb 2003 11:40:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QGntr24520 for sipping-archive@odin.ietf.org; Wed, 26 Feb 2003 11:49:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QGntp24517 for ; Wed, 26 Feb 2003 11:49:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15146 for ; Wed, 26 Feb 2003 11:39:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QGn6p24477; Wed, 26 Feb 2003 11:49:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QGlEp24356 for ; Wed, 26 Feb 2003 11:47:14 -0500 Received: from mail1.mediatrix.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15077 for ; Wed, 26 Feb 2003 11:37:06 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 26 Feb 2003 11:41:01 -0500 Message-ID: <2702075D4DE2B043BF5EB82E9CFAD45B509166@mail1.mediatrix.com> Thread-Topic: [Sipforum-discussion] SIP Telephony Device Requirements, Configuration and Data Thread-Index: AcLSeWhMUDwJq31HQSmHO2OqXzAEQwA/R8UA From: "Eric Tremblay" To: "Henry Sinnreich" , =?iso-8859-1?Q?J=F6rgen_Bj=F6rkner?= , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1QGlEp24357 Subject: [Sipping] RE: [Sipforum-discussion] SIP Telephony Device Requirements, Configuration and Data Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Henry, Here is a somewhat lengthy email with a few comments about the SIP Telephony Device Requirements draft: SIP-2, DNS SRV: SIP clients MUST t support RFC2782 [3] and MAY support the SIP service examples [4] for basic PBX-like or Centrex- like functions. SIP clients MUST support DNS SRV for locating a SIP Server. When making a SRV query, the client MUST t use the DNS additional information in the response that contains the IP addresses for the A records. If the DNS additional information is not present, the client MUST make DNS A record queries to resolve the hostnames. [EricT] I suggest referencing RFC 3263 (Locating SIP Servers) in the above section. I don't know what services are being referred to when saying "and MAY support the SIP service examples [4] for basic PBX-like or Centrex-like functions.". This section is about DNS SRV, but I found nothing in the latest SIP Services Examples draft about DNS SRV... SIP-3, Do Not Disturb: SIP clients MUST be able to set the state of the client as Do Not Disturb. Clients MUST respond to new INVITES with a ô486 Busy Hereö. Clients MUST respond to re-INVITES on existing call legs as normal behavior [4]. [EricT] I suggest rewording to something like "It must be possible for the SIP device user to configure the device state to Do Not Disturb. ...", as it is generally the user that sets the DND state ;) SIP-4, call hold resume: SIP clients MUST be able to place a call on hold/resume [4]. [EricT] Should it focus on the usage of RFC 3264, with the use of a=sendonly instead of c=0.0.0.0? Also with a focus that the answer does not automatically comes with a "held" sdp? I suggest adding something like "SIP clients MUST follow RFC 3264 when placing a call on hold. More specifically, the a=sendonly attribute MUST be used. The SDP answer of SIP clients that are being placed on hold MUST NOT contain "held" SDP, unless the user session was originally on hold." SIP-7, message waiting indicator: SIP clients MUST support SIP message waiting and an indicator for integration with voicemail platforms [5]. [EricT] This is kind of hard, since there is not RFC yet for this and different vendor/integrators are using different draft versions which sometimes do not interoperate. Should maybe add a note to this effect... Maybe something like "No RFC exist yet for this service. SIP clients MUST implement this service in its RFC form when it becomes available." SIP-9, transfer: SIP devices MUST support REFER and NOTIFY as required to support the transfer [6]. SIP clients MAY support escaped headers in the Refer-To: header. [EricT] Same problem as SIP-7... I suggest upgrading the "MAY support escaped headers..." to MUST, as not supporting this has impact on attended call transfer. SIP-11, attended call transfer: SIP devices MUST support attended call transfer [3], [4]. SIP clients MAY support escaped headers in the Refer-To: header. [EricT] Reference [3] makes no sense here ;) Should probably be [6]. SIP-12, music on hold: SIP devices MUST support music on hold [4]. [EricT] Not sure why this service is a MUST? Maybe in enterprise environments, but what about homes? SIP-15: DTMF RTP payload: SIP clients MUST be able to send DTMF specified by RFC2833 [7]. Payload type negotiation MUST comply with RFC 3264 [8]. Payload type MUST remain constant throughout the session. For example, if an endpoint decides to renegotiate codecs or put the call on hold, the payload type for the re-invite MUST be the same as initial payload type. [EricT] Should probably refer to RFC 3388. Maybe add "SIP devices SHOULD support Flow Identification (FID) as defined in RFC 3388." SIP-20, reason phrase display: If the ôReason Phraseö of a response message is displayed, the client MUST use ôReason Phraseö in the response packet. The client MUST not use an internal ôStatus Codeö table. Another SIP device MAY respond with ô403 Forbiddenö, or various other messages. [EricT] I am not sure about the above two MUST. Something tells me that the client could rely on an internal table if there was a problem with language negotiation... I don't know what the last sentence means??? "Another SIP device MAY ..." It makes no sense to me... SIP-25, Dynamic login/logout for user mobility: SIP devices MUST support user mobility. SIP clients MUST store a static profile in non-volatile memory so that this information is available during the power up sequence. SIP clients MUST allow a user to walk up to a client, login, and be able to send and receive calls with his profile information. For emergency numbers (e.g. 911) the client MUST send the credentials (username/password) of the static profile. [EricT] We are developing analog adapters and don't remember receiving such a request. I suggest either changing the MUST to SHOULD or adding some text to specify that it is a MUST for devices with the proper interface to do it and a SHOULD for devices with a limited interface. I know we could possibly configure this through a web interface, but the point is that there are a lot of vendore that currently just want to replace the wire, not the phone and its interface... App-5, SIMPLE Integration: SIP devices MUST provide a ôbuddy- list/addressbookö and use SIP extensions to leverage presence [21]. [EricT] This also does not applies well to black phones applications. I suggest changing this to "MAY". FW/NAT-2, NAT capable configuration: SIP devices MUST be able to operate behind a static NAT/PAT (Network Address Translation/Port Address Translation) device using the STUN protocol [x22]. SIP clients MUST be able to populate SIP messages with the public, external address of the NAT/PAT device and use specific port ranges for RTP. FW/NAT-3, UPnP capable configuration SIP devices MUST be able to operate with a UPnP (http://www.upnp.org/) firewall device. [EricT] I suggest using a MUST on only one of these, and a MAY on the other. I am not fully aware of all details about these two protocols, but I think a device could very well work behind a firewall by using only one mechanism. I think the draft should clearly state which mechanism is preferred. As a last point, I suggest splitting this draft into two or more drafts. One about generic requirements for SIP devices, and one (or more) about the configuration mechanism along with the data that can be configured. The first draft could refer the second one. The draft, as it is right now, defines basic requirements, then some configuration framework and its requirement, and then data (and data representation). I don't think those mix well. Focusing would probably make the documents easier to maintain ;) I might come back later with more comments on configuration/data. Best Regards, EricT -----Original Message----- From: Henry Sinnreich [mailto:Henry.Sinnreich@wcom.com] Sent: Monday, February 10, 2003 9:49 To: 'Jörgen Björkner'; sipforum-discussion@lists.su.se Subject: [Sipforum-discussion] SIP Telephony Device Requirements, Configuration and Data For everyone interested SIP phones and other SIP communication devices, and the 56 IETF coming next month, please see if you like or dislike or don't care about the draft: http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-00.txt The idea is to have discussions on the lists, and if there is interest and rough consensus to move ahead with an informational RFC. Would appreciate your comments to sipping@ietf.org , and also to sipforum-discussion@lists.su.se Thanks, Henry Henry Sinnreich WorldCom 400 International Parkway Richardson, Texas 75081 USA _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Feb 26 12:58:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18166 for ; Wed, 26 Feb 2003 12:58:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QI7ia30850 for sipping-archive@odin.ietf.org; Wed, 26 Feb 2003 13:07:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QI7ip30847 for ; Wed, 26 Feb 2003 13:07:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18114 for ; Wed, 26 Feb 2003 12:57:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QI77p30206; Wed, 26 Feb 2003 13:07:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QI6Lp30030 for ; Wed, 26 Feb 2003 13:06:21 -0500 Received: from fox.iptel.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18052; Wed, 26 Feb 2003 12:56:12 -0500 (EST) Received: from jku07.fokus.fraunhofer.de (port-212-202-200-46.reverse.qdsl-home.de [212.202.200.46]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id h1QHxSJ31894; Wed, 26 Feb 2003 18:59:28 +0100 Message-Id: <5.2.0.9.0.20030226125028.00b3e288@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 26 Feb 2003 12:54:38 +0100 To: jh@lohi.eng.song.fi, Stuart Jacobs From: Jiri Kuthan Subject: Re: [Sip] Re: [Sipping] New version of the SIP-AAA reqs draft Cc: Allison Mankin , sipping@ietf.org, sip@ietf.org In-Reply-To: <15963.31403.288541.988747@harjus.eng.song.fi> References: <5.1.1.6.0.20030221110917.04229140@pophost.gte.com> <5.1.1.6.0.20030221110917.04229140@pophost.gte.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Sorry for latency -- yes, I think that is a very important issue, and mentioning it in the draft would be very good. (Has anyone else made the observation too that operationally-related questions are rarely replied here?) I agree too it takes awareness of dialog state. It doesn't imply though, a proxy needs to be stateful -- record-routing can help, most likely along with some message integrity check if the dialog information is sensitive (which is most likely the case with AAA). -jiri At 03:16 PM 2/25/2003, jh@lohi.eng.song.fi wrote: >nobody replied to my bye question, but after some more thinking i have >myself come to the conclusion that it is impossible for a regular sip >proxy without a dialog state or a crypto identification of all requests >from its clients to do any accounting at all. > >so it would be important for a sip-aaa requirements draft to list the >preconditions for sip accounting. > >-- juha > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 27 03:29:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22754 for ; Thu, 27 Feb 2003 03:29:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1R8d4p31173 for sipping-archive@odin.ietf.org; Thu, 27 Feb 2003 03:39:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R8d3p31170 for ; Thu, 27 Feb 2003 03:39:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22746 for ; Thu, 27 Feb 2003 03:28:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R8bxp31112; Thu, 27 Feb 2003 03:37:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R8Ysp30242 for ; Thu, 27 Feb 2003 03:34:54 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22668 for ; Thu, 27 Feb 2003 03:24:29 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1R8SMnS003912; Thu, 27 Feb 2003 09:28:22 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FWT8VVG2; Thu, 27 Feb 2003 09:28:21 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h1R8SLGh027422; Thu, 27 Feb 2003 10:28:21 +0200 (EET) Message-ID: <3E5DCC24.D13CB979@lmf.ericsson.se> Date: Thu, 27 Feb 2003 10:28:20 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jiri Kuthan CC: jh@lohi.eng.song.fi, Stuart Jacobs , Allison Mankin , sipping@ietf.org Subject: Re: [Sip] Re: [Sipping] New version of the SIP-AAA reqs draft References: <5.1.1.6.0.20030221110917.04229140@pophost.gte.com> <5.1.1.6.0.20030221110917.04229140@pophost.gte.com> <5.2.0.9.0.20030226125028.00b3e288@mailhost.fokus.gmd.de> 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Juha, [removing SIP (but keeping SIPPING) from the cc: ] Do you mean that you would like to see a note along these lines added to the draft? "Note that, in order to perform accounting, a SIP proxy server should see and authenticate every message sent over the dialog." Gonzalo Jiri Kuthan wrote: > > Sorry for latency -- yes, I think that is a very important issue, > and mentioning it in the draft would be very good. (Has anyone else > made the observation too that operationally-related questions are > rarely replied here?) > > I agree too it takes awareness of dialog state. It doesn't imply though, > a proxy needs to be stateful -- record-routing can help, most likely > along with some message integrity check if the dialog information > is sensitive (which is most likely the case with AAA). > > -jiri > > At 03:16 PM 2/25/2003, jh@lohi.eng.song.fi wrote: > >nobody replied to my bye question, but after some more thinking i have > >myself come to the conclusion that it is impossible for a regular sip > >proxy without a dialog state or a crypto identification of all requests > >from its clients to do any accounting at all. > > > >so it would be important for a sip-aaa requirements draft to list the > >preconditions for sip accounting. > > > >-- juha > > > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol > >Use sip-implementors@cs.columbia.edu for questions on current sip > >Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP -- 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 mailnull@www1.ietf.org Thu Feb 27 06:56:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26008 for ; Thu, 27 Feb 2003 06:56:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RC6w010910 for sipping-archive@odin.ietf.org; Thu, 27 Feb 2003 07:06:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RC6wp10907 for ; Thu, 27 Feb 2003 07:06:58 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26000 for ; Thu, 27 Feb 2003 06:56:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RC68p10869; Thu, 27 Feb 2003 07:06:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RC4sp10810 for ; Thu, 27 Feb 2003 07:04:54 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25969 for ; Thu, 27 Feb 2003 06:54:24 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.36 #1 (Debian)) id 18oMg7-0004vA-00; Thu, 27 Feb 2003 13:58:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15965.64859.634330.779067@harjus.eng.song.fi> Date: Thu, 27 Feb 2003 13:58:19 +0200 To: Gonzalo Camarillo Cc: Jiri Kuthan , Stuart Jacobs , Allison Mankin , sipping@ietf.org Subject: Re: [Sip] Re: [Sipping] New version of the SIP-AAA reqs draft In-Reply-To: <3E5DCC24.D13CB979@lmf.ericsson.se> References: <5.1.1.6.0.20030221110917.04229140@pophost.gte.com> <5.2.0.9.0.20030226125028.00b3e288@mailhost.fokus.gmd.de> <3E5DCC24.D13CB979@lmf.ericsson.se> X-Mailer: VM 7.07 under Emacs 21.2.1 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Gonzalo Camarillo writes: > Do you mean that you would like to see a note along these lines added to > the draft? > > "Note that, in order to perform accounting, a SIP proxy server should > see and authenticate every message sent over the dialog." unfortunately in most common cases the sip proxy cannot authenticate every message. in order to be able to account a request, the proxy should be able to either authenticate it (if it was send by its own user) or know that i came from a trusted another proxy that has already authenticated the request. in order to know that the requstest was sent by its own user, the proxy should either be dialog aware or have somekind of security association with its user. neither of these is possible with products that are in common use today. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 27 07:19:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26429 for ; Thu, 27 Feb 2003 07:19:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RCT5P12666 for sipping-archive@odin.ietf.org; Thu, 27 Feb 2003 07:29:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCT5p12663 for ; Thu, 27 Feb 2003 07:29:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26424 for ; Thu, 27 Feb 2003 07:18:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCSFp12623; Thu, 27 Feb 2003 07:28:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCRmp12600 for ; Thu, 27 Feb 2003 07:27:48 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26405 for ; Thu, 27 Feb 2003 07:17:18 -0500 (EST) Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP for sipping@ietf.org; Thu, 27 Feb 2003 13:21:07 +0100 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Feb 2003 13:21:06 +0100 Message-Id: From: "Beck01, Wolfgang" To: sipping@ietf.org Subject: RE: [Sip] Re: [Sipping] New version of the SIP-AAA reqs draft Date: Thu, 27 Feb 2003 13:21:06 +0100 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: , From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Thursday, February 27, 2003 9:28 AM > To: Jiri Kuthan > > Juha, > > Do you mean that you would like to see a note along these > lines added to > the draft? > > "Note that, in order to perform accounting, a SIP proxy server should > see and authenticate every message sent over the dialog." > I don't think it's possible to do reliable accounting within a proxy if any or both of the UAs are cheating. The caller can deliberately ignore Record-Route and bypass the proxy when sending an INVITE. The callee can send broken BYEs that will be discarded by the caller but will be accepted by the accounting proxy. What kind of accounting information do we want to collect: The number of SIP messages per user? This is possible with an accounting proxy. Call minutes? How does the proxy know what kind of session is being established if the SDP is encrypted? Only the endpoints and the bandwidth reservation infrastructure can do this kind of accounting. The only way I see is to include some form of micropayment tokens ("postage stamps") in SIP messages. draft-johnston-sip-osp-token-04.txt describes such a token. Periodical session updates containing tokens prevent disputes about the actual length of the call. If the callee has tokens, he can charge for the call. The trusted third party that generates those tokens can be an OSP server or may be a proxy that inserts some header. (see http://www.ietf.org/internet-drafts/draft-beck-sipping-svc-charging-req-01.txt) -- Wolfgang Beck T-Systems Nova GmbH _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 27 07:35:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26863 for ; Thu, 27 Feb 2003 07:35:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RCj2q14180 for sipping-archive@odin.ietf.org; Thu, 27 Feb 2003 07:45:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCj1p14177 for ; Thu, 27 Feb 2003 07:45:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26857 for ; Thu, 27 Feb 2003 07:34:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCiKp14130; Thu, 27 Feb 2003 07:44:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RChQp14096 for ; Thu, 27 Feb 2003 07:43:26 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26826 for ; Thu, 27 Feb 2003 07:32:55 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1RCZZ210820 for ; Thu, 27 Feb 2003 14:35:35 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 27 Feb 2003 14:36:50 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 27 Feb 2003 14:36:49 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 27 Feb 2003 14:36:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Re: [Sipping] New version of the SIP-AAA reqs draft Date: Thu, 27 Feb 2003 14:36:48 +0200 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945183@esebe013.ntc.nokia.com> Thread-Topic: [Sip] Re: [Sipping] New version of the SIP-AAA reqs draft Thread-Index: AcLeWLLnPVQ1guQ6QCWvlW8yy5pR4QAAkBnw To: , Cc: , , , X-OriginalArrivalTime: 27 Feb 2003 12:36:48.0506 (UTC) FILETIME=[E54B25A0:01C2DE5C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1RChQp14097 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, In the end, doesn't this also depend heavily on what the purpose for collecting accounting data is? If you're only doing accounting for the purposes of traffic analysis or logging, i.e., event based accounting at the proxy, I doubt that authentication or origin of the messages is real critical. On the other hand, if you're collecting data for charging purposes, then authentication and integrity of the SIP messages is critical. However, hasn't billing based on accounting data collected by proxies been discouraged on this list several times before? Cheers, Aki > -----Original Message----- > From: ext jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: 27 February, 2003 13:58 > To: Gonzalo Camarillo > Cc: Jiri Kuthan; Stuart Jacobs; Allison Mankin; sipping@ietf.org > Subject: Re: [Sip] Re: [Sipping] New version of the SIP-AAA > reqs draft > > > Gonzalo Camarillo writes: > > > Do you mean that you would like to see a note along these > lines added to > > the draft? > > > > "Note that, in order to perform accounting, a SIP proxy > server should > > see and authenticate every message sent over the dialog." > > unfortunately in most common cases the sip proxy cannot authenticate > every message. in order to be able to account a request, the proxy > should be able to either authenticate it (if it was send by its own > user) or know that i came from a trusted another proxy that > has already > authenticated the request. > > in order to know that the requstest was sent by its own > user, the proxy > should either be dialog aware or have somekind of security > association > with its user. neither of these is possible with products > that are in > common use today. > > -- juha > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 27 07:37:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26927 for ; Thu, 27 Feb 2003 07:37:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RClm114283 for sipping-archive@odin.ietf.org; Thu, 27 Feb 2003 07:47:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RClmp14280 for ; Thu, 27 Feb 2003 07:47:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26922 for ; Thu, 27 Feb 2003 07:37:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCl6p14255; Thu, 27 Feb 2003 07:47:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCk1p14210 for ; Thu, 27 Feb 2003 07:46:01 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26893 for ; Thu, 27 Feb 2003 07:35:31 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.36 #1 (Debian)) id 18oNJs-0004xh-00; Thu, 27 Feb 2003 14:39:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15966.1788.184832.423324@harjus.eng.song.fi> Date: Thu, 27 Feb 2003 14:39:24 +0200 To: "Beck01, Wolfgang" Cc: sipping@ietf.org, stu.jacobs@labs.gte.com, mankin@psg.com Subject: RE: [Sip] Re: [Sipping] New version of the SIP-AAA reqs draft In-Reply-To: References: X-Mailer: VM 7.07 under Emacs 21.2.1 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Beck01, Wolfgang writes: > What kind of accounting information do we want to collect: The number > > of SIP messages per user? This is possible with an accounting > proxy. unfortunately not. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 27 07:45:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27751 for ; Thu, 27 Feb 2003 07:45:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RCt5c14623 for sipping-archive@odin.ietf.org; Thu, 27 Feb 2003 07:55:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCt5p14620 for ; Thu, 27 Feb 2003 07:55:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27626 for ; Thu, 27 Feb 2003 07:44:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCsEp14533; Thu, 27 Feb 2003 07:54:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCrNp14461 for ; Thu, 27 Feb 2003 07:53:23 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27152; Thu, 27 Feb 2003 07:42:53 -0500 (EST) Message-Id: <200302271242.HAA27152@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 27 Feb 2003 07:42:52 -0500 Subject: [Sipping] I-D ACTION:draft-jennings-sipping-certs-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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Certificate Discover for SIP Author(s) : C. Jennings Filename : draft-jennings-sipping-certs-00.txt Pages : 12 Date : 2003-2-26 This draft describes a scheme where SIP user agents can create self signed certificates for use with the SIP S/MIME mechanism and can then store the certificate on a web server associated with the address of record (AOR) for the user. Other user agents that want to call that AOR can retrieve these certificates from the web server. With no extra expense or effort on the end users behalf, it is possible to have a reasonable degree of confidence of the identities of the parties in a SIP session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jennings-sipping-certs-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-jennings-sipping-certs-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-jennings-sipping-certs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-26160409.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-jennings-sipping-certs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-jennings-sipping-certs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-26160409.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 27 07:45:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27765 for ; Thu, 27 Feb 2003 07:45:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RCt5214640 for sipping-archive@odin.ietf.org; Thu, 27 Feb 2003 07:55:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCt5p14637 for ; Thu, 27 Feb 2003 07:55:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27633 for ; Thu, 27 Feb 2003 07:44:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCsVp14575; Thu, 27 Feb 2003 07:54:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCrbp14469 for ; Thu, 27 Feb 2003 07:53:37 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27206; Thu, 27 Feb 2003 07:43:06 -0500 (EST) Message-Id: <200302271243.HAA27206@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 27 Feb 2003 07:43:06 -0500 Subject: [Sipping] I-D ACTION:draft-burger-sipping-dir-transcode-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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Directed Transcoding Author(s) : E. Burger Filename : draft-burger-sipping-dir-transcode-00.txt Pages : 17 Date : 2003-2-26 This document describes a mechanism for invoking transcoding services in a SIP network. A user, proxy server, or other agent can transparently request these services, without modification to the existing network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-burger-sipping-dir-transcode-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-burger-sipping-dir-transcode-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-burger-sipping-dir-transcode-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-26160444.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-burger-sipping-dir-transcode-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-burger-sipping-dir-transcode-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-26160444.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 27 07:45:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27785 for ; Thu, 27 Feb 2003 07:45:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RCt8V14658 for sipping-archive@odin.ietf.org; Thu, 27 Feb 2003 07:55:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCt8p14655 for ; Thu, 27 Feb 2003 07:55:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27640 for ; Thu, 27 Feb 2003 07:44:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCsNp14555; Thu, 27 Feb 2003 07:54:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCrWp14465 for ; Thu, 27 Feb 2003 07:53:32 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27188; Thu, 27 Feb 2003 07:43:02 -0500 (EST) Message-Id: <200302271243.HAA27188@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 27 Feb 2003 07:43:01 -0500 Subject: [Sipping] I-D ACTION:draft-peterson-sipping-ieprep-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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Considerations on the IEPREP requirements for SIP Author(s) : J. Peterson Filename : draft-peterson-sipping-ieprep-00.txt Pages : 10 Date : 2003-2-26 The IEPREP working group has provided the SIPPING WG with a framework and requirements draft for prioritized communications services in SIP. The considerations raised in that draft are examined here, and some feedback and implementation recommendations based on its requirements are provided. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-peterson-sipping-ieprep-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-peterson-sipping-ieprep-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-peterson-sipping-ieprep-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-26160433.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-peterson-sipping-ieprep-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-peterson-sipping-ieprep-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-26160433.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 27 07:47:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28059 for ; Thu, 27 Feb 2003 07:47:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RCv0414792 for sipping-archive@odin.ietf.org; Thu, 27 Feb 2003 07:57:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCv0p14789 for ; Thu, 27 Feb 2003 07:57:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28017 for ; Thu, 27 Feb 2003 07:46:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCuSp14758; Thu, 27 Feb 2003 07:56:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCrup14485 for ; Thu, 27 Feb 2003 07:53:56 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27295; Thu, 27 Feb 2003 07:43:26 -0500 (EST) Message-Id: <200302271243.HAA27295@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 27 Feb 2003 07:43:25 -0500 Subject: [Sipping] I-D ACTION:draft-rosenberg-sipping-ice-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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Interactive Connectivity Establishment (ICE): A Methodology for Nettwork Address Translator (NAT) Traversal for the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-rosenberg-sipping-ice-00.txt Pages : 35 Date : 2003-2-26 This document describes a methodology for Network Address Translator (NAT) traversal for the Session Initiation Protocol (SIP). This methodology is called Interactive Connectivity Establishment (ICE). ICE is not a new protocol, but rather makes use of existing protocols, such as Simple Traversal of UDP Through NAT (STUN), Traversal Using Relay NAT (TURN) and even Real Specific IP (RSIP). ICE works through the mutual cooperation of both endpoints in a SIP dialog. By having the endpoints work together in NAT traversal, a number of important properties are obtained. ICE always works, independent of the types or number of NATs. It always represents the cheapest solution for a carrier. It always results in the minimum voice latency. It can be done with no increase in call setup delays. It is far less brittle than STUN. ICE also facilitates the transition of the Internet from IPv4 to IPv6, supporting calls between dual-stack and v6 clients behind a 4to6 NAT. Preconditions can be used in conjunction with ICE, to guarantee that the phone never rings unless the users will both hear and see each other when they pick up. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-ice-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rosenberg-sipping-ice-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-rosenberg-sipping-ice-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-26160526.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosenberg-sipping-ice-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosenberg-sipping-ice-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-26160526.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 27 07:49:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28226 for ; Thu, 27 Feb 2003 07:49:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RCxJW14996 for sipping-archive@odin.ietf.org; Thu, 27 Feb 2003 07:59:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCxJp14990 for ; Thu, 27 Feb 2003 07:59:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28147 for ; Thu, 27 Feb 2003 07:48:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCwjp14932; Thu, 27 Feb 2003 07:58:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCs1p14496 for ; Thu, 27 Feb 2003 07:54:01 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27318; Thu, 27 Feb 2003 07:43:30 -0500 (EST) Message-Id: <200302271243.HAA27318@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 27 Feb 2003 07:43:30 -0500 Subject: [Sipping] I-D ACTION:draft-kotar-sipping-dss1-sip-iw-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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Interworking between Digital Subscriber Signalling System No. one (DSS1) and Session Initiation Author(s) : P. Kotar Filename : draft-kotar-sipping-dss1-sip-iw-00.txt Pages : 36 Date : 2003-2-26 This document specifies the interworking between the Digital Subscriber Signalling System No.one (DSS1) as specified in [1] and the Session Initiation Protocol (SIP) as specified in [2]. SIP is an Internet application-layer control protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include, in particular, telephone calls. DSS1 is a signalling protocol for establishing, modifying and terminating circuit-switched calls, in particular telephone calls, within Public Integrated Services Digital Networks (ISDN)and between the Public network and Private Networks. DSS1 is specified in a number of ETSI Standards and published also as ITU-T standards. The interworking SHALL be described from DSS1 viewpoint for the basic call procedures. The interworking between the above signalling protocols occurs in a Media Gateway Controller (MGC), also called Softswitch which contains the protocol functionality for the ISDN subscribers and the SIP protocol functionality. In case of contradictions between the mapping described in the present document and the requirements specified in the corresponding DSS1 standards and SIP RFC , the procedures in the DSS1 standards and SIP RFC applies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kotar-sipping-dss1-sip-iw-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-kotar-sipping-dss1-sip-iw-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-kotar-sipping-dss1-sip-iw-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-26160536.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kotar-sipping-dss1-sip-iw-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-kotar-sipping-dss1-sip-iw-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-26160536.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 27 07:49:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28247 for ; Thu, 27 Feb 2003 07:49:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RCxbK15043 for sipping-archive@odin.ietf.org; Thu, 27 Feb 2003 07:59:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCxbp15040 for ; Thu, 27 Feb 2003 07:59:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28172 for ; Thu, 27 Feb 2003 07:49:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCwqp14953; Thu, 27 Feb 2003 07:58:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCtOp14675 for ; Thu, 27 Feb 2003 07:55:24 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27706; Thu, 27 Feb 2003 07:44:54 -0500 (EST) Message-Id: <200302271244.HAA27706@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 27 Feb 2003 07:44:54 -0500 Subject: [Sipping] I-D ACTION:draft-rosenberg-sipping-callerprefs-usecases-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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Use Cases for Session Initiation Protocol (SIP) Caller Preferences Author(s) : J. Rosenberg, P. Kyzivat Filename : draft-rosenberg-sipping-callerprefs-usecases-00.txt Pages : 24 Date : 2003-2-26 This document describes a set of use cases for the SIP Caller Preferences and Callee Capabilities extension. Each use case is presented as a desired routing decision, followed by the actual headers and processing logic which would result in that decision. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-callerprefs-usecases-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rosenberg-sipping-callerprefs-usecases-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-rosenberg-sipping-callerprefs-usecases-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-26160836.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosenberg-sipping-callerprefs-usecases-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosenberg-sipping-callerprefs-usecases-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-26160836.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 27 08:04:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29570 for ; Thu, 27 Feb 2003 08:04:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RDEfI17097 for sipping-archive@odin.ietf.org; Thu, 27 Feb 2003 08:14:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RDEfp17094 for ; Thu, 27 Feb 2003 08:14:41 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29511 for ; Thu, 27 Feb 2003 08:04:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RDDdp17053; Thu, 27 Feb 2003 08:13:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RDCip17004 for ; Thu, 27 Feb 2003 08:12:44 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29284 for ; Thu, 27 Feb 2003 08:02:12 -0500 (EST) Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 27 Feb 2003 14:06:08 +0100 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Feb 2003 14:06:07 +0100 Message-Id: From: "Beck01, Wolfgang" To: jh@lohi.eng.song.fi Cc: sipping@ietf.org Subject: RE: [Sip] Re: [Sipping] New version of the SIP-AAA reqs draft Date: Thu, 27 Feb 2003 14:06:03 +0100 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: , > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: Thursday, February 27, 2003 1:39 PM > To: Beck, Wolfgang > Cc: sipping@ietf.org; stu.jacobs@labs.gte.com; mankin@psg.com > Subject: RE: [Sip] Re: [Sipping] New version of the SIP-AAA reqs draft > > > Beck01, Wolfgang writes: > > > What kind of accounting information do we want to collect: > The number > > > of SIP messages per user? This is possible with an accounting > > proxy. > > unfortunately not. well, at least in theory: the UAs have TLS connections to their proxies, the proxies trust each other and the ingress proxies insert P-Asserted-Identity headers. I wonder if it is really useful to count SIP messages per user on all proxies in the path. Can you give some examples? In the router world, we only do accounting on the first hop where there is some kind of security association, the 'sealed CPE' or PPP link. We don't do IP accounting in the core. -- Wolfgang Beck T-Systems Nova GmbH _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 27 08:48:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02547 for ; Thu, 27 Feb 2003 08:48:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RDwK320331 for sipping-archive@odin.ietf.org; Thu, 27 Feb 2003 08:58:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RDwKp20328 for ; Thu, 27 Feb 2003 08:58:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02466 for ; Thu, 27 Feb 2003 08:47:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RDvQp20287; Thu, 27 Feb 2003 08:57:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RDuvp20245 for ; Thu, 27 Feb 2003 08:56:57 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02380 for ; Thu, 27 Feb 2003 08:46:26 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.36 #1 (Debian)) id 18oOQW-000523-00; Thu, 27 Feb 2003 15:50:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15966.6044.760088.605681@harjus.eng.song.fi> Date: Thu, 27 Feb 2003 15:50:20 +0200 To: "Beck01, Wolfgang" Cc: sipping@ietf.org Subject: RE: [Sip] Re: [Sipping] New version of the SIP-AAA reqs draft In-Reply-To: References: X-Mailer: VM 7.07 under Emacs 21.2.1 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Beck01, Wolfgang writes: > well, at least in theory: the UAs have TLS connections to their > proxies, the > proxies trust each other and the ingress proxies > insert P-Asserted-Identity > headers. how does the proxy know that a ua that has tls connection to it, is its user? tls alone is not enough. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 27 09:17:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04329 for ; Thu, 27 Feb 2003 09:17:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RERXN22733 for sipping-archive@odin.ietf.org; Thu, 27 Feb 2003 09:27:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RERWp22730 for ; Thu, 27 Feb 2003 09:27:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04284 for ; Thu, 27 Feb 2003 09:17:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1REQHp22618; Thu, 27 Feb 2003 09:26:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1REPbp22562 for ; Thu, 27 Feb 2003 09:25:37 -0500 Received: from p2.piuha.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04081 for ; Thu, 27 Feb 2003 09:15:04 -0500 (EST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 6762E6A90D; Thu, 27 Feb 2003 16:18:58 +0200 (EET) Message-ID: <3E5E1E2A.2040109@piuha.net> Date: Thu, 27 Feb 2003 16:18:18 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jh@lohi.eng.song.fi, aki.niemi@nokia.com Cc: sipping@ietf.org Subject: Re: [Sip] Re: [Sipping] New version of the SIP-AAA reqs draft References: <5.1.1.6.0.20030221110917.04229140@pophost.gte.com> <5.1.1.6.0.20030221110917.04229140@pophost.gte.com> <5.2.0.9.0.20030226125028.00b3e288@mailhost.fokus.gmd.de> In-Reply-To: <5.2.0.9.0.20030226125028.00b3e288@mailhost.fokus.gmd.de> 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit There are different reasons for collecting accounting data. Only one of these reasons is billing based on it. Even if you bill based on usage, it probably depends on the particular business models what "usage" is. It could be a one-time fee per call, not tracking of session lengths. I agree that billing based on what proxies know about bandwidths, codecs, session lengths is troublesome (at least in the general case, maybe possible in some specific networks). But one key question is whether SIP AAA is only for proxies or for all types of SIP nodes. I think it should not be just for proxies. SIP user agents of course would also know session lengths and other parameters. (Not for regular user terminals of course but for some services offered by the network.) Jari _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 27 09:54:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06291 for ; Thu, 27 Feb 2003 09:54:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RF50D25488 for sipping-archive@odin.ietf.org; Thu, 27 Feb 2003 10:05:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RF50p25485 for ; Thu, 27 Feb 2003 10:05:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06270 for ; Thu, 27 Feb 2003 09:54:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RF4Lp25439; Thu, 27 Feb 2003 10:04:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RF3jp25402 for ; Thu, 27 Feb 2003 10:03:45 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06234 for ; Thu, 27 Feb 2003 09:53:13 -0500 (EST) Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 27 Feb 2003 15:57:07 +0100 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Feb 2003 15:57:06 +0100 Message-Id: From: "Beck01, Wolfgang" To: jh@lohi.eng.song.fi Cc: sipping@ietf.org Subject: Re: [Sipping] New version of the SIP-AAA reqs draft Date: Thu, 27 Feb 2003 15:57:05 +0100 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: , > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: Thursday, February 27, 2003 2:50 PM > To: Beck, Wolfgang > Cc: sipping@ietf.org > Subject: RE: [Sip] Re: [Sipping] New version of the SIP-AAA reqs draft > > > Beck01, Wolfgang writes: > > > well, at least in theory: the UAs have TLS connections to their > > proxies, the > proxies trust each other and the ingress proxies > > insert P-Asserted-Identity > headers. > > how does the proxy know that a ua that has tls connection to it, is > its user? tls alone is not enough. > During TLS handshake, the proxy obtains a X509 certificate from the UA. The cert. contains a subject name that identifies the peer. This can be used to create a P-Asserted-Identity header. Only the proxy that is directly connected via TLS to the customer can do that of, of course. All following proxies have to rely on P-Asserted-Identity (or OSP-token?). You can use digest authentication on top of TLS to discriminate SIP users that share a TLS connection using a proxy. -- Wolfgang Beck T-Systems Nova GmbH _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 27 10:23:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07857 for ; Thu, 27 Feb 2003 10:23:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RFXZe27554 for sipping-archive@odin.ietf.org; Thu, 27 Feb 2003 10:33:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RFXZp27551 for ; Thu, 27 Feb 2003 10:33:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07843 for ; Thu, 27 Feb 2003 10:23:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RFWgp27517; Thu, 27 Feb 2003 10:32:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RFVKp27457 for ; Thu, 27 Feb 2003 10:31:20 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07777 for ; Thu, 27 Feb 2003 10:20:47 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.36 #1 (Debian)) id 18oPtp-00057R-00; Thu, 27 Feb 2003 17:24:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15966.11705.826758.743794@harjus.eng.song.fi> Date: Thu, 27 Feb 2003 17:24:41 +0200 To: "Beck01, Wolfgang" Cc: sipping@ietf.org Subject: Re: [Sipping] New version of the SIP-AAA reqs draft In-Reply-To: References: X-Mailer: VM 7.07 under Emacs 21.2.1 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Beck01, Wolfgang writes: > During TLS handshake, the proxy obtains a X509 certificate from the > UA. so you assume somekind of pki and mutual authentication of ua and proxy? if so, we don't have any of it in real products and practices. > The cert. contains a subject name that identifies the peer. This can be > used to create a P-Asserted-Identity header. Only the proxy that is directly > connected via TLS to the customer can do that of, of course. All following > proxies have to rely on P-Asserted-Identity (or OSP-token?). You can use > digest authentication on top of TLS to discriminate SIP users that share a > TLS connection using a proxy. if you don't have the certificate system that you outlined above, the proxy can't do digest authentication, because you don't know if the user sending the request is your user or not. dialog state would help. another thing that would help is always using as fro uri the uri of the sending user, which would allow the proxy to know if the user can be challenged or not. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 27 10:37:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08443 for ; Thu, 27 Feb 2003 10:37:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RFlZU29060 for sipping-archive@odin.ietf.org; Thu, 27 Feb 2003 10:47:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RFlYp29057 for ; Thu, 27 Feb 2003 10:47:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08432 for ; Thu, 27 Feb 2003 10:37:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RFknp29006; Thu, 27 Feb 2003 10:46:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RFjSp28912 for ; Thu, 27 Feb 2003 10:45:28 -0500 Received: from imo-r03.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08337 for ; Thu, 27 Feb 2003 10:34:54 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r03.mx.aol.com (mail_out_v34.21.) id g.17a.1753a7a2 (4196); Thu, 27 Feb 2003 10:38:09 -0500 (EST) Message-ID: <17a.1753a7a2.2b8f8adf@aol.com> Date: Thu, 27 Feb 2003 10:38:07 EST Subject: Re: [Sipping] Comments on Overlap-04 To: jon.peterson@neustar.biz, sipping@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_17a.1753a7a2.2b8f8adf_boundary" X-Mailer: 6.0 for Windows XP sub 10501 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --part1_17a.1753a7a2.2b8f8adf_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 2/24/2003 2:23:44 PM Eastern Standard Time, jon.peterson@neustar.biz writes: > [MIke's] Comments on draft-ietf-sipping-overlap-04: > > General: > > The ability of one call to result in multiple IAMs being sent into the PSTN > continues to be a serious problem for overlap which must be solved. > > This concern has been the subject of whole libraries of previous > mail; I think we need to agree to disagree on this point. As we've said in > the past, the draft allows this condition to arise only if operators choose > to configure their networks in a fashion that allows it. Yes, that's why I didn't go into detail. We'll just agree that we disagree on this and will never convince the other. > > Section 3.1: > > All references to one number being a "prefix" of another should be deleted. > This text indicates that overlap can not be used where this "prefix" > situation can occur, however, one of the purposes of overlap is to handle > the situation in which there are varying lengths of numbers in some > destination area, something that would naturally exist if one number really > could be a "prefix" of another. This creates a major contradiction. > > Not necessarily a contradiction, actually. There are varying lengths > of numbers in some numbering plans. That does not entail, however, that one > number can necessarily be a prefix of another. The numbers +9990123 and > +99912345 could exist in the same numbering plan without creating any > problems for overlap signaling. The concern is if the numbers +9990123 and > +99901234 were to exist in the same numbering plan. > However, there is still no identified case in the world-wide numbering > plan in which one number is a "prefix" of another. If there were, overlap > signaling to get to it would certainly be allowed just as it would be in > the existing PSTN. If one believes that this "prefix" situation really > exists, then the overlap procedures defined in this draft must correctly > support it. > We can't necessarily verify that it's the case, but people keep > telling us that this happens in practice in the PSTN. As usual, it is tough > to provide a counter-existence proof. I think we still need this text. > One doesn't have to come up with a "counter-existence proof" for unsubstantiated claims. But anyone who claims that this situation exists should be able to come up with an existence proof. However, my point is, if you believe this situation exists, and the text of the draft says it does, then the overlap procedures must handle it properly. They can not say that overlap can't be used in this case. Note that any gateway trying to decide not to use overlap would be unaware that this situation exists. > Section 3.3 contains the statement: > > As a general rule, a media stream corresponding to the response to an > INVITE with a greater number of digits should be given more priority > than media streams from responses with less digits. > > This continues to be a problem, since it is not always the case. If the > originator dialed more digits than were needed when overlap was being used, > the media stream corresponding to the response with the fewer digits would > be the one to use. The PSTN had no problem with this. SIP is going to have > to figure out a way to correctly handle it. > > Our text satisfies particular early-media concerns, and is valid, in > my opinion. If fewer digits than the minimum length of a number in the > numbering plan are dialed, a gateway could still attempt to pass backwards > media to the UAC in order to provide early media data. The behavior that > occurs when more digits are dialed than necessary is, no doubt, specific to > different nationalities, but it seems reasonable to assume that superfluous > digits will be discarded. No one, to date, has asserted anything to the > contrary anyway. > Yes, superfluous digits are discarded. In the overlap case, they are discarded by the destination exchange that doesn't need them. Any previous exchange or gateway would not know they were superfluous. It would give "precedence" to the wrong call setup (with more digits) and release the desired one, which the called party has actually answered. I don't think this issue is related to "early media". > Section 3.5 contains the statement: > > If the gateway is attached to the PSTN in an area where en-bloc > signalling is used, a REL for the previous IAM and a new IAM should > be generated. > > This causes confusion since all areas would allow en-bloc, although some do > not allow overlap, for example, an area where US SS#7 according to T1.113 > is used. In those areas, since overlap is not allowed, the gateway or > switch which provides interworking into that non-overlap area must perform > the overlap to en-bloc procedures (by time outs, detecting enough digits, > etc.) There can not be a "previous IAM" sent to the PSTN, since the gateway > or switch would not have sent one until it knew it had enough digits to > send a complete IAM, after which it would stop accepting or sending any > further digits. > > First of all, if you send an incomplete number into an en-bloc > signaling network, that are ISUP failure responses (REL with cause 28) that > will be sent in response. Our text identifies what one should do if the > call has not already been rejected. Gateway very well might be stupid > enough to send incomplete addresses into a network that cannot accept them, > and it seems dangerous to assume otherwise. > This paragraph should be worded as: > > If the gateway is attached to the PSTN in an area where overlap > signalling > is not allowed, it must not send an IAM until it determines that it has > received the full number in one or more INVITEs, using a process similar > to > that described in Section 2. It must not send SAMs or additional IAMs > after > My comment stands. > Mike Pierce > > --part1_17a.1753a7a2.2b8f8adf_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 2/24/2= 003 2:23:44 PM Eastern Standard Time, jon.peterson@neustar.biz writes:


[MIke's] Comments on draft-= ietf-sipping-overlap-04:=20

General:=20

The ability of one call to result in multiple IAMs being sent into the P= STN continues to be a serious problem for overlap which must be solved.  
=20
<JFP> This concern has been the subject of whole libra= ries of previous mail; I think we need to agree to disagree on this point. A= s we've said in the past, the draft allows this condition to arise only if o= perators choose to configure their networks in a fashion that allows it. <= ;/JFP>



<MP>Yes, that's why I didn't go into detail. We'll just agree that= we disagree on this and will never convince the other.</MP>


Section 3.1:=20

All references to one number being a "prefix" of another should be delet= ed. This text indicates that overlap can not be used where this "prefix" sit= uation can occur, however, one of the purposes of overlap is to handle the s= ituation in which there are varying lengths of numbers in some destination a= rea, something that would naturally exist if one number really could be a "p= refix" of another. This creates a major contradiction.  <= /FONT>
=20
<JFP> Not necessarily a contradiction, actually. There= are varying lengths of numbers in some numbering plans. That does not entai= l, however, that one number can necessarily be a prefix of another. The numb= ers +9990123 and +99912345 could exist in the same numbering plan without cr= eating any problems for overlap signaling. The concern is if the numbers +99= 90123 and +99901234 were to exist in the same numbering plan. &n= bsp;   
<MP>However, there is still no identified case in the world-wide n= umbering plan in which one number is a "prefix" of another. If there were, o= verlap signaling to get to it would certainly be allowed just as it would be= in the existing PSTN. If one believes that this "prefix" situation really e= xists, then the overlap procedures defined in this draft must correctly supp= ort it. </MP}

<JFP> We can't necessarily verify that it's the case,=20= but people keep telling us that this happens in practice in the PSTN. As usu= al, it is tough to provide a counter-existence proof. I think we still need=20= this text. </JFP>

<MP> One doesn't have to come up with a "counter-existence proof"=20= for unsubstantiated claims. But anyone who claims that this situation exists= should be able to come up with an existence proof. However, my point is, if= you believe this situation exists, and the text of the draft says it does,=20= then the overlap procedures must handle it properly. They can not say that o= verlap can't be used in this case. Note that any gateway trying to decide no= t to use overlap would be unaware that this situation exists.</MP>


Section 3.3 contains the st= atement:=20

 As a general rule, a media stream corresponding to the response t= o an=20
 INVITE with a greater number of digits should be given more prior= ity=20
 than media streams from responses with less digits.=20

This continues to be a problem, since it is not always the case. If the=20= originator dialed more digits than were needed when overlap was being used,=20= the media stream corresponding to the response with the fewer digits would b= e the one to use. The PSTN had no problem with this. SIP is going to have to= figure out a way to correctly handle it.=20

<JFP> Our text satisfies particular early-media concer= ns, and is valid, in my opinion. If fewer digits than the minimum length of=20= a number in the numbering plan are dialed, a gateway could still attempt to=20= pass backwards media to the UAC in order to provide early media data. The be= havior that occurs when more digits are dialed than necessary is, no doubt,=20= specific to different nationalities, but it seems reasonable to assume that=20= superfluous digits will be discarded. No one, to date, has asserted anything= to the contrary anyway. </JFP>



<MP>Yes, superfluous digits are discarded. In the overlap case, th= ey are discarded by the destination exchange that doesn't need them. Any pre= vious exchange or gateway would not know they were superfluous. It would giv= e "precedence" to the wrong call setup (with more digits) and release the de= sired one, which the called party has actually answered. I don't think this=20= issue is related to "early media".</MP>


Section 3.5 contains the st= atement:=20

 If the gateway is attached to the PSTN in an area where en-bloc=20
 signalling is used, a REL for the previous IAM and a new IAM shou= ld=20
 be generated.=20

This causes confusion since all areas would allow en-bloc, although some= do not allow overlap, for example, an area where US SS#7 according to T1.11= 3 is used. In those areas, since overlap is not allowed, the gateway or swit= ch which provides interworking into that non-overlap area must perform the o= verlap to en-bloc procedures (by time outs, detecting enough digits, etc.) T= here can not be a "previous IAM" sent to the PSTN, since the gateway or swit= ch would not have sent one until it knew it had enough digits to send a comp= lete IAM, after which it would stop accepting or sending any further digits.= =20

<JFP> First of all, if you send an incomplete number i= nto an en-bloc signaling network, that are ISUP failure responses (REL with=20= cause 28) that will be sent in response. Our text identifies what one should= do if the call has not already been rejected. Gateway very well might be st= upid enough to send incomplete addresses into a network that cannot accept t= hem, and it seems dangerous to assume otherwise. </JFP>


This paragraph should be worded as:=20

 If the gateway is attached to the PSTN in an area where overlap s= ignalling=20
 is not allowed, it must not send an IAM until it determines that=20= it has=20
 received the full number in one or more INVITEs, using a process=20= similar to   
 that described in Section 2. It must not send SAMs or additional=20= IAMs after=20
 that one IAM.



<MP>My comment stands.</MP>


Mike Pierce=20





--part1_17a.1753a7a2.2b8f8adf_boundary-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 27 11:00:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09377 for ; Thu, 27 Feb 2003 11:00:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RGAhC30962 for sipping-archive@odin.ietf.org; Thu, 27 Feb 2003 11:10:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RGAgp30959 for ; Thu, 27 Feb 2003 11:10:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09363 for ; Thu, 27 Feb 2003 11:00:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RG9sp30900; Thu, 27 Feb 2003 11:09:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RG8rp30831 for ; Thu, 27 Feb 2003 11:08:53 -0500 Received: from imo-m06.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09203 for ; Thu, 27 Feb 2003 10:58:19 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-m06.mx.aol.com (mail_out_v34.21.) id r.12f.2426e6da (14374); Thu, 27 Feb 2003 11:02:10 -0500 (EST) Message-ID: <12f.2426e6da.2b8f9081@aol.com> Date: Thu, 27 Feb 2003 11:02:09 EST Subject: Re: [Sipping] Overlap in QSIG draft To: Gonzalo.Camarillo@lmf.ericsson.se, john.elwell@siemens.com CC: sipping@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_12f.2426e6da.2b8f9081_boundary" X-Mailer: 6.0 for Windows XP sub 10501 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --part1_12f.2426e6da.2b8f9081_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 2/26/2003 8:07:06 AM Eastern Standard Time, Gonzalo.Camarillo@lmf.ericsson.se writes: > I have noticed that the SIP-QSIG draft describes how to use overlap > signalling in a SIP network. > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-00.txt > > I believe that this draft should not describe overlap procedures. It > should reference the overlap mapping draft instead: > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-overlap-04.txt > In a message dated 2/26/2003 8:17:56 AM Eastern Standard Time, Gonzalo.Camarillo@lmf.ericsson.se writes: > the last version of the draft (which was released two or three weeks > ago) will be presented to the IESG shortly. I believe that we have > addressed all the issues that were raised... the document could be > approved in a reasonably short period of time. > For the record, while I agree that the QSIG draft should reference rather then repeat what is specified elsewhere, I do not believe that all the issues that have been raised concerning the overlap draft have been addressed or resolved. I have commented extensively on that draft, and I believe that many of those comments have been ignored. If these issues are not addressed, I am sure that others (existing network operators) will specify that interworking with the PSTN must be done according to Q.1912.SIP, which is currently being developed by ITU-T SG11. Mike Pierce Artel --part1_12f.2426e6da.2b8f9081_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 2/26/2= 003 8:07:06 AM Eastern Standard Time, Gonzalo.Camarillo@lmf.ericsson.se writ= es:


I have noticed that the SIP= -QSIG draft describes how to use overlap
signalling in a SIP network.

http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-00.txt

I believe that this draft should not describe overlap procedures. It
should reference the overlap mapping draft instead:

http://www.ietf.org/internet-drafts/draft-ietf-sipping-overlap-04.txt




In a message dated 2/26/2003 8:17:56 AM Eastern Standard Time, Gonzalo.C= amarillo@lmf.ericsson.se writes:


the last version of the dra= ft (which was released two or three weeks
ago) will be presented to the IESG shortly. I believe that we have
addressed all the issues that were raised... the document could be
approved in a reasonably short period of time.=20




For the record, while I agree that the QSIG draft should reference rathe= r then repeat what is specified elsewhere, I do not believe that all the iss= ues that have been raised concerning the overlap draft have been addressed o= r resolved. I have commented extensively on that draft, and I believe that m= any of those comments have been ignored. If these issues are not addressed,=20= I am sure that others (existing network operators) will specify that interwo= rking with the PSTN must be done according to Q.1912.SIP, which is currently= being developed by ITU-T SG11.

Mike Pierce
Artel
--part1_12f.2426e6da.2b8f9081_boundary-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 27 12:02:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11634 for ; Thu, 27 Feb 2003 12:02:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RHCFE03849 for sipping-archive@odin.ietf.org; Thu, 27 Feb 2003 12:12:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RHCFp03846 for ; Thu, 27 Feb 2003 12:12:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11579 for ; Thu, 27 Feb 2003 12:01:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RHBYp03765; Thu, 27 Feb 2003 12:11:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RHAAp03616 for ; Thu, 27 Feb 2003 12:10:10 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11456 for ; Thu, 27 Feb 2003 11:59:34 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1RH3TYe020086; Thu, 27 Feb 2003 18:03:29 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FD4HXNPM; Thu, 27 Feb 2003 18:03:29 +0100 Received: from lmf.ericsson.se (sealwa04-205.sw.ericsson.se [130.100.249.205]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h1RH3PGh029288; Thu, 27 Feb 2003 19:03:27 +0200 (EET) Message-ID: <3E5E44DB.64599F38@lmf.ericsson.se> Date: Thu, 27 Feb 2003 19:03:23 +0200 X-Sybari-Trust: 84e5783f 9ffcebbb 7a95d2f4 00000138 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mpierce1@aol.com CC: john.elwell@siemens.com, sipping@ietf.org, Jon Peterson Subject: Re: [Sipping] Overlap in QSIG draft References: <12f.2426e6da.2b8f9081@aol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mike, >For the record, while I agree that the QSIG draft should reference >rather then repeat what is specified elsewhere, I do not believe >that all the issues that have been raised concerning the overlap draft >have been addressed or resolved. I have commented >extensively on that draft, and I believe that many of those comments >have been ignored. If these issues are not addressed, I am >sure that others (existing network operators) will specify that >interworking with the PSTN must be done according to Q.1912.SIP, >which is currently being developed by ITU-T SG11. Jon wrote you a note the other day explaining in which points we agreed with you and in which ones we did not (and why). We have discussed the same issues several times and explained you why we cannot specify some of the things you proposed. I do not think we need to discuss them again now. 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 mailnull@www1.ietf.org Thu Feb 27 15:41:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21663 for ; Thu, 27 Feb 2003 15:41:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RKpcx20327 for sipping-archive@odin.ietf.org; Thu, 27 Feb 2003 15:51:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RKpcp20324 for ; Thu, 27 Feb 2003 15:51:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21607 for ; Thu, 27 Feb 2003 15:40:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RKofp20277; Thu, 27 Feb 2003 15:50:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RKnHp20208 for ; Thu, 27 Feb 2003 15:49:17 -0500 Received: from cs.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21265 for ; Thu, 27 Feb 2003 15:38:38 -0500 (EST) Received: from cisalpino.cs.columbia.edu (cisalpino.cs.columbia.edu [128.59.19.194]) by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id h1RKgX0C013615; Thu, 27 Feb 2003 15:42:33 -0500 (EST) Date: Thu, 27 Feb 2003 15:42:32 -0500 (EST) From: Xiaotao Wu To: Gonzalo Camarillo cc: , Henning Schulzrinne , Subject: Re: [Sipping] I-D ACTION:draft-wu-sipping-floor-control-03.txt In-Reply-To: <3E5C9A41.797F33F5@lmf.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , inline. thanks! On Wed, 26 Feb 2003, Gonzalo Camarillo wrote: > Hi, > > the definition of the FL semantics for the grouping framework needs more > elaboration. You need to say whether or not only one control line is > allowed per group and include an IANA considerations section as follows: > > IANA Considerations > > IANA needs to register the following new "semantics" attribute for > the SDP grouping framework [RFC3388]: > > Semantics Token Reference > ------------------- ----- --------- > Floor control FL [RFCxxxx] > > > It should be registered in the SDP parameters registry > (http://www.iana.org/assignments/sdp-parameters) under Semantics for > the "group" SDP Attribute. > > You should also add IANA considerations for a=moderate > Thanks! Will add this in. > > In Section 8.1, you write: "the conference server uses a=moderated line > to mute all media tools of the participant". Does the conference server > set to inactive the SDP direction attributes as well or it leaves them > as they are (e.g., sendrecv)? I think the conference server should leave them as they are. The 'a=type:moderated' is for conference attribute in session level. It should not change the attributes of any media. Thanks! -Xiaotao > > Thanks, > > Gonzalo > > > > Internet-Drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > Title : Use of Session Initiation Protocol (SIP) and Simple > > Object Access > > Protocol (SOAP) for Conference Floor Control > > Author(s) : X. Wu et al. > > Filename : draft-wu-sipping-floor-control-03.txt > > Pages : 33 > > Date : 2003-1-15 > > > > During a conference, floor control coordinates simultaneous access to > > shared resource in multimedia conferences. Floor control allows > > applications and users to gain safe and mutually exclusive or non- > > exclusive access to the shared resources. This document defines an > > approach of using Session Initiation Protocol (SIP) event > > notification mechanism and Simple Object Access Protocol (SOAP) to > > perform floor control. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-wu-sipping-floor-control-03.txt > > > > To remove yourself from the IETF Announcement list, send a message to > > ietf-announce-request with the word unsubscribe in the body of the message. > > > > Internet-Drafts are also available by anonymous FTP. Login with the username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-wu-sipping-floor-control-03.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-wu-sipping-floor-control-03.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > ------------------------------------------------------------------------ > > -- > 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 mailnull@www1.ietf.org Thu Feb 27 16:15:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24119 for ; Thu, 27 Feb 2003 16:15:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RLPna22321 for sipping-archive@odin.ietf.org; Thu, 27 Feb 2003 16:25:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RLPnp22318 for ; Thu, 27 Feb 2003 16:25:49 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24072 for ; Thu, 27 Feb 2003 16:15:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RLONp22249; Thu, 27 Feb 2003 16:24:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RLNZp22217 for ; Thu, 27 Feb 2003 16:23:35 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24047 for ; Thu, 27 Feb 2003 16:12:54 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA21523; Thu, 27 Feb 2003 16:16:47 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA25606; Thu, 27 Feb 2003 16:16:48 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Feb 2003 16:16:47 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5EE0@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henry Sinnreich'" Cc: "'sipping@ietf.org'" , "'sipforum-discussion@lists.su.se'" Date: Thu, 27 Feb 2003 16:16:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] Comments on draft-sinnreich-sipdev-req-00.txt (long) Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , I've looked through this draft and have several comments. SIP-8, local dial plan: I'm unhappy with requiring a local dialing plan. Many of my customers wish to force all calls through the local proxy SIP-13, client-based conferencing: I don't know what the sentence "SIP devices MUST be able to support handset based conferencing" means. I understand the next sentence. Are you proposing that each handset follow the SIP conferencing requirements? If not, what, exactly, is the requirement? SIP-15: DTMF RTP payload I'm confused why this is a MUST. If the device only supports G.711 or better (i.e. no low bandwidth, highly compressed) codecs, why is it a requirement to generate 2833? SIP-22 through SIP-26, multi-line support I'm having problems with the terminology. "Multiline" to me means the ability to handle more than one call at a time (all but one on hold). Here you mean "multiple users on the same UA" I think the requirements are okay (at MAY), but we need a new term that really means multiple users registered at one UA. I'll note that there is a possible problem with our basic standards. To allow multiple users at the same UA, the UA, the registrar and the incoming proxy all have to support such a thing. There is no way for the UA to know if that is possible. SIP-24, multi-line call waiting indicator I don't understand "If call waiting is set for an identity, the client MUST respond with "486 Busy Here" when an incoming call to that identity is received and the client has an existing call with any of the identities" Are you disallowing the possibility of more than one waiting call for an identity? How else do I understand "call waiting is set"? SIP-25, Dynamic login/logout I disagree with the architecture assumption made here. I think emergency calls should NOT depend on any kind of authentication. Thus, I think it should not be necessary to register before making an emergency call, and thus there is no need for a default identity. Specifically, if your proposal was implemented, and, for whatever reason, authentication failed, and a user could not make an emergency call, I think someone is in DEEP doo-doo. I think we need some convention for identity (ie what is in the From) to aid law enforcement in tracking malicious calls to emergency centers, but, please, don't depend on authentication. As far as I know, emergency centers would rather get some "anonymous" calls than miss a call because someone configured something wrong. SIPsec-2 password protection I dislike this requirement. I think the problems it generates outweigh the security it provides. Specifically, to make this work, you have to put a default password in the device, so you can get in the first time, and you need some kind of a reset function when people forget the settings. The former almost always gets left in this state, which opens up a huge attack, the latter always eventually gets known, and exploited. Our systems have VERY limited configuration done at the terminal - basically, just how you get an IP address. Everything else we store on a server and download. This works well for us, and putting a password on the IP settings is just not justified. SIPsec-4, INVITE user portion acceptance You don't have the corresponding output requirements - SIP devices must have a setting that forces all outbound messages to a specific proxy. This is a clear requirement for many operators. International-1, language support I have a very minor problem with "The setting for this header MUST be provisioned". My problem is that it could be interpreted as disallowing a separate language preference for each user who is registered when multi-user support is provided. We certainly would not provision the PHONE with language. We would have a user profile setting for this. App-2, hold ring-back Do you expect the phone to send any SIP message when it starts to ring? Maybe you should say what you expect. App-5, SIMPLE Integration I think this is not well specified. SIMPLE has so many possible variations, I don't see what we say. I also think there is no "address book" spec yet, and specifically, an address book may have many more addresses in it than you get presence for. Web-1 I object to this requirement. We provide a very nice UI on our device to specify things like ring tones and forwarding preferences. It happens that we also have a web UI that can do this, but we really don't need it. I'll note that the wording is awkward. The first sentence says "SIP devices MUST support a web server", while the second sentence says "Web pages ... MAY be [in] ..centralized web servers" The latter is more correct than the former. Web-2 Object in that not all such settings make sense to be remotely settable. Forwarding behavior may be, ringtones may not be, at least with respect to a user. FW/NAT-1, outbound proxy support I think this is too tightly specified. Specifically, I think the device needs to accept an outbound proxy. It must be configurable to always use this proxy, and for each user, there must be a full uri that may or may not be in the same domain as the outbound proxy. There is no need to explicitly know the domain; you need to know the URI. It may be that your implementation affixes a registration name to a default domain. Ours doesn't. We authenticate with a username and then return an AOR. I think that is quite reasonable. That means the first MUST (default domain) can go away. Int-1: (buttons) I would not want this to be interpreted as requiring any specific hard buttons. Any/all of these could be in some soft UI. Int-3 There are several paragraphs after the first one in Int-3 that I can't make any sense of. Is some of it supposed to be an Int-4? The fragment "End user options..." is not a sentence. Lines-1 This requirement gets confused with the prior multi-line section above. Consolidation and terminology change is needed. Section 3 First of all, at least at the moment, there is no SIP mechanism to do any of this, and I suspect it won't be a sip mechanism that does it, although it could be a form of PUBLISH. So, I think using terms like "User Agent" is incorrect. Perhaps use Profile Server and Profile Client. There are several cases where the word "may" became "MAY" inappropriately. I also think there are "device profiles" that are associated with a particular UA, "user profiles" that are associated with a particular user, and a hybrid, where there is a profile for a particular user at a particular device. These need names, we need a name for any of them, and the text has to be edited to use the correct one of these. I have some problems with: Change Notification is the means by which the profile server tells the user agent that profiles of interest have changed. Typically, the intention would be for the user agent to get those changes or the updated profiles. My problem is that this is a database, the terminal may change it, or an external web accessed page may change it. In the former, the device has to inform the database that it is changed. In the latter, the database has to inform the device that it is changed. Both of these are change notifications. OpenExt-1: and OpenExt-2: are the same. I think extensibility of the data object is more important than "intelligence" at the server, whatever that means. ENR-5: Also is needed to support multiple users on the same UA. CN-3: Could we have some justification for this? I'm not objecting to a MAY, I want the device to MAY support a scheduled change. SEC-n I have some problems with authentication, because I envision this to be close to the first thing you do after you have an IP address. The device is either provisioned with, or learns the profile server from DHCP. It contacts it first, before any registration, .... You don't have a lot to authenticate either end with, except the aforementioned password which I think is worse than nothing. Section 4 I am confused over what this intended to be. Are we talking about settings that are made manually at the device, not covered by a device profile described in Section 3? I personally think we should be minimizing such things. Right now, ideally, I think you learn the profile server from DHCP and get everything from that except the IP address/mask stuff that you also get from DHCP. It's a tossup whether you learn the sip proxy from DHCP or the profile server. You certainly shouldn't be having a "Session Timer" setting that doesn't come from the device profile. Also has the confusion on the term "line" There is a typo in the chapter number in the first sentence. Network-2 We should be clear whether we intend this wording to imply you have more than one setting, or whether there is one setting and it is applied to both media and signalling. I think there are potentially many settings, one for each media type and one for signalling. Dial-1: Dial Plan. I object. We SHOULD recommend a "Dial" button and not rely on a dial plan. A dial plan should at best be a MAY. Regional-4: I recognize that some sites will not support DHCP. DHCP should be the preferred way to find the time server. The text should say that. If you don't have DHCP, it has to be provisioned, and thus we need this in the list, I just think its use should be discouraged. Phonebook-1: The text seems to not allow a phonebook to be stored on the profile server. It should allow that. The problem is the word "stored". PhoneServers-1: I don't understand why you would encourage phonebooks to be stored in someplace other than the profile server. I can see some difficulty in storing history there, although we would do it that way. 4.11 Ringer Behavior The text "These devices SHOULD ignore all line related settings that do no affect the default outbound line settings they receive" has a typo, and it confuses how "default" should work. They are line settings. There is a default line. It should state something like "... all line settings other than the default line's settings" The last paragraph of this section should be deleted. It doesn't help, and it ignores the most common choice of ringtone selection by caller. 4.12 User Related Settings This text is very confusing to me. I'm certainly agreeable to supporting multiple users registered at a UA. I'm interested in supporting multiple call appearances per user (or per UA if you prefer, they are the same as long as you don't restrict one user to a SINGLE appearance) The picture you seem to have is a physical or UI button per line, and you want to assign a user to a line. Okay, if that's what you want as long as I can assign more than one line to one user. Our system works a bit differently but the effect is the same with regard to allowing multiple users registered at one UA, and multiple call appearances per user. The only thing I can make out of this text is that you want to be able to have some prior configuration that has some default association between a line button and a user. While we wouldn't do that, I understand that such a facility may be useful for some vendors. The text is far from clear about that, if indeed that is what you meant. Roaming means that a user walks up to a phone and does something that causes him to be registered. In your picture, it causes one or more line buttons to be associated with him. That isn't a configuration mechanism, that's a run time dynamic assignment mechanism. Registering on a UA may cause a new user profile to be downloaded, I get that, but this section is on device configuration, as best I can figure out, and this text doesn't make much sense to me here. 4.13 Line Related Settings Another very confusing section for me. My problem is that I don't see a 1to1 correspondence between a "line" and an address of record. The whole "line" concept is POTS specific. There are users and there are call appearances. You can have one or more users, and each user can have zero or more call appearances. Each user has an AoR, but you can have more than one active call at this AoR at a particular device. It could be that if you changed "line" to "registered user", the text could make some sense, but it might need more work than that. You clearly don't have a separate registration if a user has more than one "line" in your sense of "line"; The first call to the user's AoR would show up on his first "line", the second would show at his second "line". There doesn't have to be any knowledge of this in anything except the device. There doesn't have to be a URI for each line. 4.16 through 4.20 These are, or should at least have the option to be, PER USER settings, not per device settings. I'm having a little conflicting views problems, because we implement these things in the proxy server not the device, but we're having some problems with the idea of "ring once then forward". Generally, we think that forwarding behavior is best done at the server since you have to do it anyway when the user is not logged in. On the other hand, not all servers will do that, and so maybe requiring the phone to be able to do it may be necessary. I did not review sections 5 and higher. Brian _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 27 16:18:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24232 for ; Thu, 27 Feb 2003 16:18:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RLSh022493 for sipping-archive@odin.ietf.org; Thu, 27 Feb 2003 16:28:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RLShp22490 for ; Thu, 27 Feb 2003 16:28:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24227 for ; Thu, 27 Feb 2003 16:18:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RLS4p22471; Thu, 27 Feb 2003 16:28:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RLRBp22373 for ; Thu, 27 Feb 2003 16:27:11 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24151 for ; Thu, 27 Feb 2003 16:16:31 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h1RLJnC23381; Thu, 27 Feb 2003 21:19:49 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Feb 2003 16:19:58 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214E77@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'jh@lohi.eng.song.fi'" , "Beck01, Wolfgang" Cc: sipping@ietf.org Subject: RE: [Sipping] New version of the SIP-AAA reqs draft Date: Thu, 27 Feb 2003 16:19:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , I agree with Juha that it's pretty unlikely that a UA will have an X.509 cert it can use to do mutual TLS auth with a proxy. The proxy should definitely authenticate itself to the UA with a certificate, but it is much more plausible that the UA will authenticate itself to the proxy with Digest. This is the model presented in RFC3261, anyway. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: Thursday, February 27, 2003 7:25 AM > To: Beck01, Wolfgang > Cc: sipping@ietf.org > Subject: Re: [Sipping] New version of the SIP-AAA reqs draft > > > Beck01, Wolfgang writes: > > > During TLS handshake, the proxy obtains a X509 certificate from the > > UA. > > so you assume somekind of pki and mutual authentication of ua > and proxy? > if so, we don't have any of it in real products and practices. > > > The cert. contains a subject name that identifies the > peer. This can be > > used to create a P-Asserted-Identity header. Only the > proxy that is directly > > connected via TLS to the customer can do that of, of > course. All following > > proxies have to rely on P-Asserted-Identity (or > OSP-token?). You can use > > digest authentication on top of TLS to discriminate SIP > users that share a > > TLS connection using a proxy. > > if you don't have the certificate system that you outlined above, the > proxy can't do digest authentication, because you don't know > if the user > sending the request is your user or not. dialog state would help. > another thing that would help is always using as fro uri the > uri of the > sending user, which would allow the proxy to know if the user can be > challenged or not. > > -- juha > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Feb 27 16:46:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25189 for ; Thu, 27 Feb 2003 16:46:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RLuUV24496 for sipping-archive@odin.ietf.org; Thu, 27 Feb 2003 16:56:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RLuTp24493 for ; Thu, 27 Feb 2003 16:56:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25184 for ; Thu, 27 Feb 2003 16:45:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RLtfp24463; Thu, 27 Feb 2003 16:55:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RLsHp24413 for ; Thu, 27 Feb 2003 16:54:17 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25146 for ; Thu, 27 Feb 2003 16:43:36 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h1RLlSXp025396 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 27 Feb 2003 16:47:31 -0500 (EST) Message-ID: <3E5E877A.7060701@cs.columbia.edu> Date: Thu, 27 Feb 2003 16:47:38 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Henry Sinnreich'" , "'sipping@ietf.org'" , "'sipforum-discussion@lists.su.se'" Subject: Re: [Sipping] Comments on draft-sinnreich-sipdev-req-00.txt (long) References: <313680C9A886D511A06000204840E1CF030B5EE0@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF030B5EE0@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > SIP-15: DTMF RTP payload > I'm confused why this is a MUST. If the device only supports > G.711 or better (i.e. no low bandwidth, highly compressed) codecs, > why is it a requirement to generate 2833? It's a lot easier if you don't have to recognize DTMF from tones. (Doing reliable DTMF recognition is surprisingly tricky; in particular, it's hard to do this without a full reconstruction of the audio signal, i.e., playout delay compensation.) Thus, it seems silly to waste CPU resources on the client to generate a sine waveform just waste more of them trying to detect which one it was on the ACD server or gateway. It's trivial to implement 2833 sending, so is there a reason *NOT* to require it? _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 28 02:11:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16155 for ; Fri, 28 Feb 2003 02:11:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1S7LN902971 for sipping-archive@odin.ietf.org; Fri, 28 Feb 2003 02:21:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1S7LNp02968 for ; Fri, 28 Feb 2003 02:21:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16146 for ; Fri, 28 Feb 2003 02:10:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1S7KXp02950; Fri, 28 Feb 2003 02:20:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RA69p03490 for ; Thu, 27 Feb 2003 05:06:09 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24042 for ; Thu, 27 Feb 2003 04:55:42 -0500 (EST) Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 27 Feb 2003 10:59:11 +0100 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Feb 2003 10:59:06 +0100 Message-Id: From: "Beck01, Wolfgang" To: sipping@ietf.org Cc: jh@lohi.eng.song.fi, stu.jacobs@labs.gte.com, mankin@psg.com Subject: RE: [Sip] Re: [Sipping] New version of the SIP-AAA reqs draft Date: Thu, 27 Feb 2003 10:59:04 +0100 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: , > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Thursday, February 27, 2003 9:28 AM > To: Jiri Kuthan > > Juha, > > Do you mean that you would like to see a note along these > lines added to > the draft? > > "Note that, in order to perform accounting, a SIP proxy server should > see and authenticate every message sent over the dialog." > I don't think it's possible to do reliable accounting within a proxy if any or both of the UAs are cheating. The caller can deliberately ignore Record-Route and bypass the proxy when sending an INVITE. The callee can send broken BYEs that will be discarded by the caller but will be accepted by the accounting proxy. What kind of accounting information do we want to collect: The number of SIP messages per user? This is possible with an accounting proxy. Call minutes? How does the proxy know what kind of session is being established if the SDP is encrypted? Only the endpoints and the bandwidth reservation infrastructure can do this kind of accounting. The only way I see is to include some form of micropayment tokens ("postage stamps") in SIP messages. draft-johnston-sip-osp-token-04.txt describes such a token. Periodical session updates containing tokens prevent disputes about the actual length of the call. If the callee has tokens, he can charge for the call. The trusted third party that generates those tokens can be an OSP server or may be a proxy that inserts some header. (see http://www.ietf.org/internet-drafts/draft-beck-sipping-svc-charging-req-01.txt) -- Wolfgang Beck T-Systems Nova GmbH _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 28 04:07:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17945 for ; Fri, 28 Feb 2003 04:07:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1S9IIw10504 for sipping-archive@odin.ietf.org; Fri, 28 Feb 2003 04:18:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1S9IIp10501 for ; Fri, 28 Feb 2003 04:18:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17939 for ; Fri, 28 Feb 2003 04:07:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1S9HYp10475; Fri, 28 Feb 2003 04:17:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1S9Fap10371 for ; Fri, 28 Feb 2003 04:15:36 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17841 for ; Fri, 28 Feb 2003 04:04:42 -0500 (EST) Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 28 Feb 2003 10:08:14 +0100 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Feb 2003 10:08:13 +0100 Message-Id: From: "Beck01, Wolfgang" To: jon.peterson@neustar.biz, jh@lohi.eng.song.fi Cc: sipping@ietf.org Subject: RE: [Sipping] proxy accounting, was: New version of the SIP-AAA reqs draft Date: Fri, 28 Feb 2003 10:08:10 +0100 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: , > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Thursday, February 27, 2003 10:20 PM > > I agree with Juha that it's pretty unlikely that a UA will > have an X.509 > cert it can use to do mutual TLS auth with a proxy. The proxy should > definitely authenticate itself to the UA with a certificate, > but it is much > more plausible that the UA will authenticate itself to the proxy with > Digest. This is the model presented in RFC3261, anyway. > I was referring to theoretical possibility, deliberately ignoring ugly real-world details. Btw, RfC3261 proposes S/MIME certificates stored in UAs to identify end users. Maybe Juha and I are talking about different things. The question was: can any proxy on the path do a per-user accounting? If it is not used for billing, there is no incentive for users to tamper with the SIP headers and a certain percentage of incorrect accounting records is tolerable. If it is used for billing - proxy usage, not call duration - then we need some proof of origin. We have: - Digest + P-Asserted-Identity -> Problems with BYE and CANCEL, untrusted proxies - TLS + P-Asserted-Identity -> no certs on today's UAs, only within one trust domain - S/MIME signatures -> no implementations in sight - OSP-Token -> not a standard yet, no implementations (?) -- Wolfgang Beck T-Systems Nova GmbH _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 28 04:31:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18304 for ; Fri, 28 Feb 2003 04:31:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1S9frQ12305 for sipping-archive@odin.ietf.org; Fri, 28 Feb 2003 04:41:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1S9fqp12302 for ; Fri, 28 Feb 2003 04:41:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18292 for ; Fri, 28 Feb 2003 04:30:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1S9fCp12264; Fri, 28 Feb 2003 04:41:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1S9eJp12235 for ; Fri, 28 Feb 2003 04:40:19 -0500 Received: from p2.piuha.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18268 for ; Fri, 28 Feb 2003 04:29:24 -0500 (EST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 979A36A903; Fri, 28 Feb 2003 11:33:18 +0200 (EET) Message-ID: <3E5F2CB6.6000700@piuha.net> Date: Fri, 28 Feb 2003 11:32:38 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Beck01, Wolfgang" Cc: jon.peterson@neustar.biz, jh@lohi.eng.song.fi, sipping@ietf.org Subject: Re: [Sipping] proxy accounting, was: New version of the SIP-AAA reqs 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > - Digest + P-Asserted-Identity -> Problems with BYE and CANCEL, untrusted proxies > - TLS + P-Asserted-Identity -> no certs on today's UAs, only within one trust domain > - S/MIME signatures -> no implementations in sight > - OSP-Token -> not a standard yet, no implementations (?) Yes, though I would modify this a bit. I wouldn't group Digest and P-Asserted-Identity under the same heading; the difference is that in the first the proxy itself is doing the checking whereas in the other you are relying on someone else to have done it for you. Also, what is "proxy usage"? Is it routing an INVITE, REGISTER through the proxy, or is it counting every SIP protocol message? If former, limitations you mentioned above may not matter. Aren't the digest problems with ACK and CANCEL, not with BYE? And I believe there's limited support for authentication of ACK, just that no new challenge can be generated. Thus, I think the table should be: - P-Asserted-Identity -> Only reliable in an environment with trusted proxies - Digest -> Ok in some cases, Digest limitations for CANCEL maybe ACK in some other cases - TLS + P-Asserted-Identity -> no certs on today's UAs, only within one trust domain - S/MIME signatures -> no implementations in sight - OSP-Token -> not a standard yet, no implementations (?) (This table applies only when talking about accounting for the purpose of billing.) Jari _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 28 05:24:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19492 for ; Fri, 28 Feb 2003 05:24:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SAYUb14783 for sipping-archive@odin.ietf.org; Fri, 28 Feb 2003 05:34:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SAYUp14780 for ; Fri, 28 Feb 2003 05:34:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19485 for ; Fri, 28 Feb 2003 05:23:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SAXYp14767; Fri, 28 Feb 2003 05:33:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SAWkp14730 for ; Fri, 28 Feb 2003 05:32:46 -0500 Received: from rautu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19435 for ; Fri, 28 Feb 2003 05:21:46 -0500 (EST) Received: from jh by rautu with local (Exim 3.35 #1 (Debian)) id 18oilZ-0000DI-00; Fri, 28 Feb 2003 13:33:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15967.18652.915252.507261@lohi.eng.song.fi> Date: Fri, 28 Feb 2003 13:32:44 +0200 To: "Beck01, Wolfgang" Cc: jon.peterson@neustar.biz, sipping@ietf.org Subject: RE: [Sipping] proxy accounting, was: New version of the SIP-AAA reqs draft In-Reply-To: References: X-Mailer: VM 7.07 under Emacs 21.2.1 From: Juha Heinanen Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Beck01, Wolfgang writes: > - Digest + P-Asserted-Identity -> Problems with BYE and CANCEL, > - untrusted proxies as i said, it would help quite a bit if we would change the rule how from header is constructed when sending a request within a dialog. i propose that in the next version of the sip rfc, the uri of the sender of the request is always used. that would help the proxy to figure out if it can challenge the request. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 28 05:26:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19575 for ; Fri, 28 Feb 2003 05:26:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SAamZ14901 for sipping-archive@odin.ietf.org; Fri, 28 Feb 2003 05:36:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SAalp14898 for ; Fri, 28 Feb 2003 05:36:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19571 for ; Fri, 28 Feb 2003 05:25:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SAaBp14867; Fri, 28 Feb 2003 05:36:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SAZop14830 for ; Fri, 28 Feb 2003 05:35:50 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19520 for ; Fri, 28 Feb 2003 05:24:54 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.36 #1 (Debian)) id 18ohl3-00065w-00; Fri, 28 Feb 2003 12:28:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15967.14816.912911.978133@harjus.eng.song.fi> Date: Fri, 28 Feb 2003 12:28:48 +0200 To: jari.arkko@piuha.net Cc: "Beck01, Wolfgang" , jon.peterson@neustar.biz, sipping@ietf.org Subject: Re: [Sipping] proxy accounting, was: New version of the SIP-AAA reqs draft In-Reply-To: <3E5F2CB6.6000700@piuha.net> References: <3E5F2CB6.6000700@piuha.net> X-Mailer: VM 7.07 under Emacs 21.2.1 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jari Arkko writes: > Aren't the digest problems with ACK and CANCEL, not with BYE? no the problem is with any request within a dialog. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 28 05:33:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19674 for ; Fri, 28 Feb 2003 05:33:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SAhnY15928 for sipping-archive@odin.ietf.org; Fri, 28 Feb 2003 05:43:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SAhnp15925 for ; Fri, 28 Feb 2003 05:43:49 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19671 for ; Fri, 28 Feb 2003 05:32:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SAh9p15906; Fri, 28 Feb 2003 05:43:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SAgNp15836 for ; Fri, 28 Feb 2003 05:42:23 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19638 for ; Fri, 28 Feb 2003 05:31:27 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1SAZMnS017446; Fri, 28 Feb 2003 11:35:22 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id F5DZ7ADS; Fri, 28 Feb 2003 11:35:22 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h1SAZMGh020797; Fri, 28 Feb 2003 12:35:22 +0200 (EET) Message-ID: <3E5F3B69.913DE777@lmf.ericsson.se> Date: Fri, 28 Feb 2003 12:35:21 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: jh@lohi.eng.song.fi CC: "Beck01, Wolfgang" , sipping@ietf.org, stu.jacobs@labs.gte.com, mankin@psg.com, Jari Arkko Subject: Re: [Sip] Re: [Sipping] New version of the SIP-AAA reqs draft References: <15966.1788.184832.423324@harjus.eng.song.fi> 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Juha, I still do not quite understand your arguments. Could you please elaborate on why a proxy cannot know that a message comes from a particular UA? Thanks, Gonzalo jh@lohi.eng.song.fi wrote: > > Beck01, Wolfgang writes: > > > What kind of accounting information do we want to collect: The number > > > of SIP messages per user? This is possible with an accounting > > proxy. > > unfortunately not. > > -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 28 05:41:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19806 for ; Fri, 28 Feb 2003 05:41:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SAq6g16181 for sipping-archive@odin.ietf.org; Fri, 28 Feb 2003 05:52:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SAq6p16178 for ; Fri, 28 Feb 2003 05:52:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19799 for ; Fri, 28 Feb 2003 05:41:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SApFp16138; Fri, 28 Feb 2003 05:51:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SAo0p16091 for ; Fri, 28 Feb 2003 05:50:00 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19770 for ; Fri, 28 Feb 2003 05:39:03 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1SAgrYe022475; Fri, 28 Feb 2003 11:42:54 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id F5DZ7CN4; Fri, 28 Feb 2003 11:42:53 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h1SAgrGh021210; Fri, 28 Feb 2003 12:42:53 +0200 (EET) Message-ID: <3E5F3D2C.C76388E0@lmf.ericsson.se> Date: Fri, 28 Feb 2003 12:42:52 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sipping , John Loughney CC: Dean Willis , Rohan Mahy , Allison Mankin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] WGLC on draft-ietf-sipping-aaa-req-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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, we have had some discussions about the SIP-AAA work in the mailing list lately. In order to take advantage of this interest, I would like to WGLC the SIP-AAA requirements draft. http://www.ietf.org/internet-drafts/draft-ietf-sipping-aaa-req-02.txt By last calling this document, we want to try to keep the focus of the WG on the requirements, before we jump into discussing solutions. This WGLC will end on April 4th. Thanks, Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 28 05:44:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19854 for ; Fri, 28 Feb 2003 05:44:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SAsuB16279 for sipping-archive@odin.ietf.org; Fri, 28 Feb 2003 05:54:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SAsup16276 for ; Fri, 28 Feb 2003 05:54:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19847 for ; Fri, 28 Feb 2003 05:43:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SAsAp16257; Fri, 28 Feb 2003 05:54:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SArDp16226 for ; Fri, 28 Feb 2003 05:53:13 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19824 for ; Fri, 28 Feb 2003 05:42:16 -0500 (EST) Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 28 Feb 2003 11:45:51 +0100 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Feb 2003 11:45:51 +0100 Message-Id: From: "Beck01, Wolfgang" To: jari.arkko@piuha.net Cc: jon.peterson@neustar.biz, jh@lohi.eng.song.fi, sipping@ietf.org Subject: RE: [Sipping] proxy accounting Date: Fri, 28 Feb 2003 11:45:43 +0100 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: , Jari, > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Friday, February 28, 2003 10:33 AM > > > - Digest + P-Asserted-Identity -> Problems with BYE and > CANCEL, untrusted proxies > > - TLS + P-Asserted-Identity -> no certs on today's UAs, > only within one trust domain > > - S/MIME signatures -> no implementations in sight > > - OSP-Token -> not a standard yet, no implementations (?) > > Yes, though I would modify this a bit. I wouldn't group Digest and > P-Asserted-Identity under the same heading; the difference is that > in the first the proxy itself is doing the checking whereas in the > other you are relying on someone else to have done it for you. I was thinking of a combination where the first proxy authenticates with digest and inserts a P-Asserted-Identity header afterwards. taking your comment into account, the list looks like this: Digest: proxy relies on itself P-Asserted-Identity: proxy relies on the first proxy to do the checking (using digest or TLS) and on intermediate proxies not discarding P-Asserted-Identity. S/MIME: proxy relies on the CA to do the checking OSP-Token: proxy relies on the OSP-Server to do the checking > Also, what is "proxy usage"? Is it routing an INVITE, REGISTER > through the proxy, or is it counting every SIP protocol message? I meant counting protocol messages. > Aren't the digest problems with ACK and CANCEL, not with BYE? > And I believe there's limited support for authentication of ACK, > just that no new challenge can be generated. You are right, I was mixing things up, Digest has other limitations here. Imagine a scenario where all proxies in a path subsequently challenge all requests of a UA. Call setup times will be bad. -- Wolfgang Beck T-Systems Nova GmbH _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 28 05:45:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19878 for ; Fri, 28 Feb 2003 05:45:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SAuF116344 for sipping-archive@odin.ietf.org; Fri, 28 Feb 2003 05:56:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SAuFp16341 for ; Fri, 28 Feb 2003 05:56:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19869 for ; Fri, 28 Feb 2003 05:45:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SAt9p16318; Fri, 28 Feb 2003 05:55:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SAs2p16246 for ; Fri, 28 Feb 2003 05:54:02 -0500 Received: from rautu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19833 for ; Fri, 28 Feb 2003 05:42:55 -0500 (EST) Received: from jh by rautu with local (Exim 3.35 #1 (Debian)) id 18ojso-0000GV-00; Fri, 28 Feb 2003 14:44:58 +0200 To: Gonzalo Camarillo Cc: "Beck01, Wolfgang" , sipping@ietf.org, stu.jacobs@labs.gte.com, mankin@psg.com, Jari Arkko Subject: Re: [Sip] Re: [Sipping] New version of the SIP-AAA reqs draft In-Reply-To: <3E5F3B69.913DE777@lmf.ericsson.se> References: <15966.1788.184832.423324@harjus.eng.song.fi> <3E5F3B69.913DE777@lmf.ericsson.se> X-Mailer: VM 7.07 under Emacs 21.2.1 Message-Id: From: Juha Heinanen Date: Fri, 28 Feb 2003 14:44:58 +0200 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Gonzalo Camarillo writes: > I still do not quite understand your arguments. Could you please > elaborate on why a proxy cannot know that a message comes from a > particular UA? for example, i can send an invite where To header looks like this: To: my proxy can then map it via enum, for example, to a request uri sip:jh@tutpro.com which the proxy of tutpro.com then delivers to me. when i send a bye to my proxy to close this call, from header has the above To uri that my proxy can't use to determine that it should challenge the request, my current understanding is that in order to be able to challenge the request, the proxy should keep dialog state. if you know some other way for the proxy to determine from the bye request alone that its own user has sent it, please let me know and i'll instantly add that capability to my proxy. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 28 05:52:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20037 for ; Fri, 28 Feb 2003 05:52:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SB3FO16639 for sipping-archive@odin.ietf.org; Fri, 28 Feb 2003 06:03:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SB3Fp16636 for ; Fri, 28 Feb 2003 06:03:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20014 for ; Fri, 28 Feb 2003 05:52:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SB2Pp16586; Fri, 28 Feb 2003 06:02:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SB1Rp16549 for ; Fri, 28 Feb 2003 06:01:27 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19990 for ; Fri, 28 Feb 2003 05:50:29 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1SAsPYe025568; Fri, 28 Feb 2003 11:54:25 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id F4SNV4WW; Fri, 28 Feb 2003 11:54:24 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h1SAsOGh021838; Fri, 28 Feb 2003 12:54:24 +0200 (EET) Message-ID: <3E5F3FDF.B5A878FD@lmf.ericsson.se> Date: Fri, 28 Feb 2003 12:54:23 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Juha Heinanen CC: "Beck01, Wolfgang" , sipping@ietf.org, stu.jacobs@labs.gte.com, mankin@psg.com, Jari Arkko Subject: Re: [Sip] Re: [Sipping] New version of the SIP-AAA reqs draft References: <15966.1788.184832.423324@harjus.eng.song.fi> <3E5F3B69.913DE777@lmf.ericsson.se> 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Juha, Here you have a figure of the scenario you have just described: alice.com . . . bob.com . proxy proxy . . . Alice . . . . . . . . . . . . . . . . . . . . Bob We have an INVITE from alice@alice.com to bob@bob.com Now, you have a BYE from Bob to Alice. In your scenario, which proxy is doing accounting, alice.com or bob.com? Thanks for the clarification, Gonzalo Juha Heinanen wrote: > > Gonzalo Camarillo writes: > > > I still do not quite understand your arguments. Could you please > > elaborate on why a proxy cannot know that a message comes from a > > particular UA? > > for example, i can send an invite where To header looks like this: > > To: > > my proxy can then map it via enum, for example, to a request uri > > sip:jh@tutpro.com > > which the proxy of tutpro.com then delivers to me. > > when i send a bye to my proxy to close this call, from header has the > above To uri that my proxy can't use to determine that it should > challenge the request, > > my current understanding is that in order to be able to challenge the > request, the proxy should keep dialog state. if you know some other way > for the proxy to determine from the bye request alone that its own user > has sent it, please let me know and i'll instantly add that capability > to my proxy. > > -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 28 06:42:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21172 for ; Fri, 28 Feb 2003 06:42:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SBrDL19684 for sipping-archive@odin.ietf.org; Fri, 28 Feb 2003 06:53:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SBrDp19681 for ; Fri, 28 Feb 2003 06:53:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21155 for ; Fri, 28 Feb 2003 06:42:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SBqWp19644; Fri, 28 Feb 2003 06:52:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SBpIp19579 for ; Fri, 28 Feb 2003 06:51:18 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21100 for ; Fri, 28 Feb 2003 06:40:19 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.36 #1 (Debian)) id 18oiw0-0006Ap-00; Fri, 28 Feb 2003 13:44:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15967.19340.437382.154213@harjus.eng.song.fi> Date: Fri, 28 Feb 2003 13:44:12 +0200 To: Gonzalo Camarillo Cc: "Beck01, Wolfgang" , sipping@ietf.org, stu.jacobs@labs.gte.com, mankin@psg.com, Jari Arkko Subject: Re: [Sip] Re: [Sipping] New version of the SIP-AAA reqs draft In-Reply-To: <3E5F3FDF.B5A878FD@lmf.ericsson.se> References: <15966.1788.184832.423324@harjus.eng.song.fi> <3E5F3B69.913DE777@lmf.ericsson.se> <3E5F3FDF.B5A878FD@lmf.ericsson.se> X-Mailer: VM 7.07 under Emacs 21.2.1 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Gonzalo Camarillo writes: > Here you have a figure of the scenario you have just described: > > alice.com . . . bob.com > . proxy proxy . > . . > Alice . . . . . . . . . . . . . . . . . . . . Bob > > We have an INVITE from alice@alice.com to bob@bob.com no, originally, we have an invite from alice@alice.com to 33983900@sip.song.fi that gets translated by enum to bob@bob.com. > > Now, you have a BYE from Bob to Alice. In your scenario, which proxy is > doing accounting, alice.com or bob.com? both proxies account both placed and received calls of their own users. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 28 06:44:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21208 for ; Fri, 28 Feb 2003 06:44:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SBsmB19779 for sipping-archive@odin.ietf.org; Fri, 28 Feb 2003 06:54:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SBsmp19774 for ; Fri, 28 Feb 2003 06:54:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21187 for ; Fri, 28 Feb 2003 06:43:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SBs6p19754; Fri, 28 Feb 2003 06:54:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SBrPp19703 for ; Fri, 28 Feb 2003 06:53:25 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21165 for ; Fri, 28 Feb 2003 06:42:26 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1SBnXm27350 for ; Fri, 28 Feb 2003 13:49:33 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 28 Feb 2003 13:46:22 +0200 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 28 Feb 2003 13:46:22 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 28 Feb 2003 13:46:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 28 Feb 2003 13:46:21 +0200 Message-ID: Thread-Topic: [Sip] Re: [Sipping] New version of the SIP-AAA reqs draft Thread-Index: AcLfGHT5kq88JkaZR3ydK8n1QsJ2iwABjtjQ To: X-OriginalArrivalTime: 28 Feb 2003 11:46:22.0002 (UTC) FILETIME=[03C50920:01C2DF1F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1SBrPp19704 Subject: [Sipping] Introduction to Accounting Management (from IETF 53) Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi all, Those of you at IETF 53 may remember that Bernard Aboba gave a presentation about some of the shortcomings of RADIUS, especially with regards to accounting. I searched the procedings pages and noticed that the presentation was not there. I've put a copy of the presentation here: http://www-nrc.nokia.com/sua/Accounting.ppt, if anyone is interested in reading it. It may be relevent to the current discussion. best regards, 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 mailnull@www1.ietf.org Fri Feb 28 06:55:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21474 for ; Fri, 28 Feb 2003 06:55:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SC5km20130 for sipping-archive@odin.ietf.org; Fri, 28 Feb 2003 07:05:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SC5kp20127 for ; Fri, 28 Feb 2003 07:05:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21456 for ; Fri, 28 Feb 2003 06:54:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SC5Ap20107; Fri, 28 Feb 2003 07:05:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SC4Ip20069 for ; Fri, 28 Feb 2003 07:04:18 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21437 for ; Fri, 28 Feb 2003 06:53:19 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1SBvEnS015836; Fri, 28 Feb 2003 12:57:14 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id F5DZ7R36; Fri, 28 Feb 2003 12:57:13 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h1SBvDGh025891; Fri, 28 Feb 2003 13:57:13 +0200 (EET) Message-ID: <3E5F4E98.6A71919E@lmf.ericsson.se> Date: Fri, 28 Feb 2003 13:57:12 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: jh@lohi.eng.song.fi CC: sipping , John Loughney , Dean Willis , Rohan Mahy , Allison Mankin Subject: Re: [Sipping] WGLC on draft-ietf-sipping-aaa-req-02.txt References: <3E5F3D2C.C76388E0@lmf.ericsson.se> <15967.19436.579654.967847@harjus.eng.song.fi> 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Juha, I was not refering to you. I was talking about the Diameter-Radious-Web services discussions. Your point falls perfectly within the scope of this WGLC. Thanks, Gonzalo jh@lohi.eng.song.fi wrote: > > Gonzalo Camarillo writes: > > > By last calling this document, we want to try to keep the focus of the > > WG on the requirements, before we jump into discussing solutions. > > i have been talking about requirements, i.e., what is required to make > accounting possible at all, and i don't think the current document > really addresses that question. > > - juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 28 07:26:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22789 for ; Fri, 28 Feb 2003 07:26:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SCaUO22304 for sipping-archive@odin.ietf.org; Fri, 28 Feb 2003 07:36:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SCaUp22301 for ; Fri, 28 Feb 2003 07:36:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22668 for ; Fri, 28 Feb 2003 07:25:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SCZjp22246; Fri, 28 Feb 2003 07:35:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SCY2p22178 for ; Fri, 28 Feb 2003 07:34:02 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22155 for ; Fri, 28 Feb 2003 07:23:02 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1SCQwnS025738; Fri, 28 Feb 2003 13:26:58 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id F4SNWS2R; Fri, 28 Feb 2003 13:26:58 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h1SCQwGh027712; Fri, 28 Feb 2003 14:26:58 +0200 (EET) Message-ID: <3E5F5590.412D66D8@lmf.ericsson.se> Date: Fri, 28 Feb 2003 14:26:56 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: jh@lohi.eng.song.fi CC: "Beck01, Wolfgang" , sipping@ietf.org, stu.jacobs@labs.gte.com, mankin@psg.com, Jari Arkko Subject: Re: [Sip] Re: [Sipping] New version of the SIP-AAA reqs draft References: <15966.1788.184832.423324@harjus.eng.song.fi> <3E5F3B69.913DE777@lmf.ericsson.se> <3E5F3FDF.B5A878FD@lmf.ericsson.se> <15967.19340.437382.154213@harjus.eng.song.fi> 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Juha, OK, now I understand what you mean. Your proxy decides to perform or to not perform accounting for a particular request based on the From header field of the request. That is a poor choice. The proxy should challenge the request (e.g., using digest). This way, the proxy can ensure that the request comes from that particular user. Your proxy can keep from challenging a particular request if the request carries a P-asserted-identity, for instance. Your proxy can refuse to route any request unless the user has provided proper credentials or the network has provided credentials for the user. Gonzalo jh@lohi.eng.song.fi wrote: > > Gonzalo Camarillo writes: > > > Here you have a figure of the scenario you have just described: > > > > alice.com . . . bob.com > > . proxy proxy . > > . . > > Alice . . . . . . . . . . . . . . . . . . . . Bob > > > > We have an INVITE from alice@alice.com to bob@bob.com > > no, originally, we have an invite from alice@alice.com to > 33983900@sip.song.fi that gets translated by enum to bob@bob.com. > > > > Now, you have a BYE from Bob to Alice. In your scenario, which proxy is > > doing accounting, alice.com or bob.com? > > both proxies account both placed and received calls of their own users. > > -- juha -- 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 mailnull@www1.ietf.org Fri Feb 28 07:29:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23103 for ; Fri, 28 Feb 2003 07:29:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SCeRn23388 for sipping-archive@odin.ietf.org; Fri, 28 Feb 2003 07:40:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SCeRp23385 for ; Fri, 28 Feb 2003 07:40:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23065 for ; Fri, 28 Feb 2003 07:29:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SCdjp23263; Fri, 28 Feb 2003 07:39:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SCZcp22232 for ; Fri, 28 Feb 2003 07:35:38 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22490; Fri, 28 Feb 2003 07:24:39 -0500 (EST) Message-Id: <200302281224.HAA22490@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sipping@ietf.org, mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 28 Feb 2003 07:24:39 -0500 Subject: [Sipping] I-D ACTION:draft-mahy-sipping-media-policy-control-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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Media Policy Manipulation in the Conference Policy Control Protocol Author(s) : R. Mahy, N. Ismail Filename : draft-mahy-sipping-media-policy-control-00.txt Pages : 19 Date : 2003-2-27 The SIP conferencing framework defines a model for tightly-coupled conferencing in the Session Initiation Protocol (SIP), in which a Conference Policy Control Protocol is used to manipulate policies relevant to a specific conference, such as conference membership policy, authorization policy, and media policy. This document describes a logical model to describe media processing in a SIP conference. It also defines specific protocol semantics and a specific syntax to manipulate that model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mahy-sipping-media-policy-control-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mahy-sipping-media-policy-control-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-mahy-sipping-media-policy-control-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-27132718.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mahy-sipping-media-policy-control-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mahy-sipping-media-policy-control-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-27132718.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 28 07:30:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23137 for ; Fri, 28 Feb 2003 07:30:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SCeos23420 for sipping-archive@odin.ietf.org; Fri, 28 Feb 2003 07:40:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SCenp23417 for ; Fri, 28 Feb 2003 07:40:49 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23100 for ; Fri, 28 Feb 2003 07:29:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SCeDp23366; Fri, 28 Feb 2003 07:40:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SCaQp22289 for ; Fri, 28 Feb 2003 07:36:26 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22655; Fri, 28 Feb 2003 07:25:27 -0500 (EST) Message-Id: <200302281225.HAA22655@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 28 Feb 2003 07:25:27 -0500 Subject: [Sipping] I-D ACTION:draft-peterson-sipping-role-authz-00.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Role-based Authorization Requirements for the Session Initiation Protocol Author(s) : J. Peterson Filename : draft-peterson-sipping-role-authz-00.txt Pages : 10 Date : 2003-2-27 This document lays out a set of requirements related to role-based authorization for the Session Initiation Protocol. While numerous authentication mechanisms are described in the base SIP specification, role-based authorization provides information used to make policy decisions based on the attributes of a participant in a session. This approach provides a richer framework for authorization, as well as allow greater privacy for users of an identity system. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-peterson-sipping-role-authz-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-peterson-sipping-role-authz-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-peterson-sipping-role-authz-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-27132842.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-peterson-sipping-role-authz-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-peterson-sipping-role-authz-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-27132842.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 28 07:36:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21209 for ; Fri, 28 Feb 2003 06:44:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SBsmT19793 for sipping-archive@odin.ietf.org; Fri, 28 Feb 2003 06:54:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SBsmp19776 for ; Fri, 28 Feb 2003 06:54:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21189 for ; Fri, 28 Feb 2003 06:43:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SBs4p19734; Fri, 28 Feb 2003 06:54:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SBrJp19699 for ; Fri, 28 Feb 2003 06:53:19 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21159 for ; Fri, 28 Feb 2003 06:42:21 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.36 #1 (Debian)) id 18oixY-0006Ax-00; Fri, 28 Feb 2003 13:45:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15967.19436.579654.967847@harjus.eng.song.fi> Date: Fri, 28 Feb 2003 13:45:48 +0200 To: Gonzalo Camarillo Cc: sipping , John Loughney , Dean Willis , Rohan Mahy , Allison Mankin Subject: [Sipping] WGLC on draft-ietf-sipping-aaa-req-02.txt In-Reply-To: <3E5F3D2C.C76388E0@lmf.ericsson.se> References: <3E5F3D2C.C76388E0@lmf.ericsson.se> X-Mailer: VM 7.07 under Emacs 21.2.1 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Gonzalo Camarillo writes: > By last calling this document, we want to try to keep the focus of the > WG on the requirements, before we jump into discussing solutions. i have been talking about requirements, i.e., what is required to make accounting possible at all, and i don't think the current document really addresses that question. - juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 28 07:47:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24445 for ; Fri, 28 Feb 2003 07:47:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SCwHm24657 for sipping-archive@odin.ietf.org; Fri, 28 Feb 2003 07:58:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SCwHp24654 for ; Fri, 28 Feb 2003 07:58:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24428 for ; Fri, 28 Feb 2003 07:47:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SCvep24617; Fri, 28 Feb 2003 07:57:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SCqAp24156 for ; Fri, 28 Feb 2003 07:52:10 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23995 for ; Fri, 28 Feb 2003 07:41:10 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.36 #1 (Debian)) id 18ojss-0006FT-00; Fri, 28 Feb 2003 14:45:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15967.22989.940714.971963@harjus.eng.song.fi> Date: Fri, 28 Feb 2003 14:45:01 +0200 To: Gonzalo Camarillo Cc: "Beck01, Wolfgang" , sipping@ietf.org, stu.jacobs@labs.gte.com, mankin@psg.com, Jari Arkko Subject: Re: [Sip] Re: [Sipping] New version of the SIP-AAA reqs draft In-Reply-To: <3E5F5590.412D66D8@lmf.ericsson.se> References: <15966.1788.184832.423324@harjus.eng.song.fi> <3E5F3B69.913DE777@lmf.ericsson.se> <3E5F3FDF.B5A878FD@lmf.ericsson.se> <15967.19340.437382.154213@harjus.eng.song.fi> <3E5F5590.412D66D8@lmf.ericsson.se> X-Mailer: VM 7.07 under Emacs 21.2.1 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Gonzalo Camarillo writes: > OK, now I understand what you mean. Your proxy decides to perform or to > not perform accounting for a particular request based on the From header > field of the request. That is a poor choice. The proxy should challenge > the request (e.g., using digest). This way, the proxy can ensure that > the request comes from that particular user. so are you saying that a user cannot place a call to the user of my proxy unless the user is also a user of the same proxy or has been challenged by someone else that my proxy trusts? if so, we'll have very little sip traffic in our networks. it would be the same as disallowing a user of an email server from receiving email unless it was sent by another email server that the email server trusts. also, if the proxy serves multiple realms, how can it know which realm the user that send the request within a dialog belongs to so that it can insert the proper realm in the digest challenge? today there is no header in the request where the user could tell that it belongs to a certain realm. the from header is the only one, but it only works for sure for initial requests. > Your proxy can keep from challenging a particular request if the request > carries a P-asserted-identity, for instance. as i said, there would be very little sip traffic if you impose such a rule. besides it is a p header and not part of sip. if you remember i tried to make it a real header, but failed to convince people. now you make the whole accounting process to depend on it. i don't think we should accept as working group documents anything that depends on p headers. > Your proxy can refuse to route any request unless the user has provided > proper credentials or the network has provided credentials for the user. see above. with today's means, i don't even know which realm the user is supposed to belong to. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 28 08:12:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26100 for ; Fri, 28 Feb 2003 08:12:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SDMpl27076 for sipping-archive@odin.ietf.org; Fri, 28 Feb 2003 08:22:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SDMpp27073 for ; Fri, 28 Feb 2003 08:22:51 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26073 for ; Fri, 28 Feb 2003 08:11:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SDMEp27046; Fri, 28 Feb 2003 08:22:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SDLnp27027 for ; Fri, 28 Feb 2003 08:21:49 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26033 for ; Fri, 28 Feb 2003 08:10:48 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1SDEjnS011621; Fri, 28 Feb 2003 14:14:45 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FD4H85W8; Fri, 28 Feb 2003 14:14:44 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h1SDEiGh000575; Fri, 28 Feb 2003 15:14:44 +0200 (EET) Message-ID: <3E5F60C2.3BD1E9B4@lmf.ericsson.se> Date: Fri, 28 Feb 2003 15:14:42 +0200 X-Sybari-Trust: 47b1b803 9ffcebbb 7a95d2f4 00000138 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: jh@lohi.eng.song.fi CC: "Beck01, Wolfgang" , sipping@ietf.org, stu.jacobs@labs.gte.com, mankin@psg.com, Jari Arkko Subject: Re: [Sip] Re: [Sipping] New version of the SIP-AAA reqs draft References: <15966.1788.184832.423324@harjus.eng.song.fi> <3E5F3B69.913DE777@lmf.ericsson.se> <3E5F3FDF.B5A878FD@lmf.ericsson.se> <15967.19340.437382.154213@harjus.eng.song.fi> <3E5F5590.412D66D8@lmf.ericsson.se> <15967.22989.940714.971963@harjus.eng.song.fi> 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Juha, > so are you saying that a user cannot place a call to the user of my > proxy unless the user is also a user of the same proxy or has been > challenged by someone else that my proxy trusts? if so, we'll have very > little sip traffic in our networks. it would be the same as disallowing > a user of an email server from receiving email unless it was sent by > another email server that the email server trusts. Everything depends on your trust model. If your proxy is performing some type of accounting that you (the user) wants it to perform (e.g., some type of service), the proxy will accept "anonymous" and no password as credentials, because the proxy is not concerned with UAs trying to cheat. Therefore, external users will be able to call you. And if you are not concerned about security either and you want to base your service in the contents of the To (or From) fields, then your UA can actually modify the To field. What it cannot modify is the tag. If your proxy does not trust the UA because it is a billing proxy, for instance, your proxy will only accept requests with proper credentials or requests that are going to be routed to a known (by the proxy) UA. But ensuring that the UA does not cheat is outside of the scope of the requirements, and it can be done in several ways. > also, if the proxy serves multiple realms, how can it know which realm > the user that send the request within a dialog belongs to so that it can > insert the proper realm in the digest challenge? today there is no > header in the request where the user could tell that it belongs to a > certain realm. the from header is the only one, but it only works for > sure for initial requests. You can change the contents of the From field. No problem. In fact, one of the reasons we removed the To and From URIs from the dialog identifiers (only the tags remain) was to address this type of situation. 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 mailnull@www1.ietf.org Fri Feb 28 08:41:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27668 for ; Fri, 28 Feb 2003 08:41:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SDqLi29249 for sipping-archive@odin.ietf.org; Fri, 28 Feb 2003 08:52:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SDqLp29246 for ; Fri, 28 Feb 2003 08:52:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27580 for ; Fri, 28 Feb 2003 08:41:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SDpLp29189; Fri, 28 Feb 2003 08:51:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SDojp29129 for ; Fri, 28 Feb 2003 08:50:45 -0500 Received: from alaska.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27531 for ; Fri, 28 Feb 2003 08:39:43 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by alaska.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1SDhcpX023292; Fri, 28 Feb 2003 14:43:38 +0100 (MET) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id F4SNXJFJ; Fri, 28 Feb 2003 14:43:37 +0100 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.6/8.12.6/lmf-2.1-jcs) with ESMTP id h1SDhbGh002388; Fri, 28 Feb 2003 15:43:37 +0200 (EET) Message-ID: <3E5F6787.A2229EF1@lmf.ericsson.se> Date: Fri, 28 Feb 2003 15:43:35 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Juha Heinanen CC: "Beck01, Wolfgang" , jon.peterson@neustar.biz, sipping@ietf.org Subject: Re: [Sipping] proxy accounting, was: New version of the SIP-AAAreqs draft References: <15967.18652.915252.507261@lohi.eng.song.fi> 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Juha, > i > propose that in the next version of the sip rfc, the uri of the sender > of the request is always used. that would help the proxy to figure out > if it can challenge the request. This is what I said in one of my previous mails. Per RFC 3261, you are free to change your URL if you want. No change to the spec needed. 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 mailnull@www1.ietf.org Fri Feb 28 08:43:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27821 for ; Fri, 28 Feb 2003 08:43:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SDrvb29387 for sipping-archive@odin.ietf.org; Fri, 28 Feb 2003 08:53:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SDrvp29384 for ; Fri, 28 Feb 2003 08:53:57 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27759 for ; Fri, 28 Feb 2003 08:42:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SDr7p29346; Fri, 28 Feb 2003 08:53:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SDqcp29265 for ; Fri, 28 Feb 2003 08:52:38 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27636 for ; Fri, 28 Feb 2003 08:41:36 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.36 #1 (Debian)) id 18okpL-0006JJ-00; Fri, 28 Feb 2003 15:45:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15967.26615.548199.865215@harjus.eng.song.fi> Date: Fri, 28 Feb 2003 15:45:27 +0200 To: Gonzalo Camarillo Cc: "Beck01, Wolfgang" , sipping@ietf.org, stu.jacobs@labs.gte.com, mankin@psg.com, Jari Arkko Subject: Re: [Sip] Re: [Sipping] New version of the SIP-AAA reqs draft In-Reply-To: <3E5F60C2.3BD1E9B4@lmf.ericsson.se> References: <15966.1788.184832.423324@harjus.eng.song.fi> <3E5F3B69.913DE777@lmf.ericsson.se> <3E5F3FDF.B5A878FD@lmf.ericsson.se> <15967.19340.437382.154213@harjus.eng.song.fi> <3E5F5590.412D66D8@lmf.ericsson.se> <15967.22989.940714.971963@harjus.eng.song.fi> <3E5F60C2.3BD1E9B4@lmf.ericsson.se> X-Mailer: VM 7.07 under Emacs 21.2.1 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Gonzalo Camarillo writes: > You can change the contents of the From field. No problem. In fact, one > of the reasons we removed the To and From URIs from the dialog > identifiers (only the tags remain) was to address this type of > situation. currently your text says: The From URI of the request MUST be set to the local URI from the dialog state. ... It is expected that mandatory reflection of the original To and From URI in mid-dialog requests will be deprecated in a subsequent revision of this specification. so before that is done and the text is changed so that the from uri MUST be the from uri of the user sending the request, there can't be any challenging or accounting of requests within the dialog. alternatively, we must add another header or field to the request that tells what realm the ua sending the request claims to belong to. for example, take a look at eap/tls. there the user has a means to tell what realm he/she wants to authenticate with. currently we are lacking this possibility in sip, which is a major shortcoming. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 28 08:46:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28024 for ; Fri, 28 Feb 2003 08:46:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SDunS29606 for sipping-archive@odin.ietf.org; Fri, 28 Feb 2003 08:56:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SDunp29603 for ; Fri, 28 Feb 2003 08:56:49 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27994 for ; Fri, 28 Feb 2003 08:45:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SDu8p29551; Fri, 28 Feb 2003 08:56:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SDtjp29509 for ; Fri, 28 Feb 2003 08:55:45 -0500 Received: from lohi.eng.song.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27918 for ; Fri, 28 Feb 2003 08:44:43 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.36 #1 (Debian)) id 18oksS-0006JP-00; Fri, 28 Feb 2003 15:48:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15967.26807.957641.310193@harjus.eng.song.fi> Date: Fri, 28 Feb 2003 15:48:39 +0200 To: Gonzalo Camarillo Cc: "Beck01, Wolfgang" , jon.peterson@neustar.biz, sipping@ietf.org Subject: Re: [Sipping] proxy accounting, was: New version of the SIP-AAAreqs draft In-Reply-To: <3E5F6787.A2229EF1@lmf.ericsson.se> References: <15967.18652.915252.507261@lohi.eng.song.fi> <3E5F6787.A2229EF1@lmf.ericsson.se> X-Mailer: VM 7.07 under Emacs 21.2.1 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Gonzalo Camarillo writes: > This is what I said in one of my previous mails. Per RFC 3261, you are > free to change your URL if you want. No change to the spec needed. the text that i quoted, doesn't say so. in order to get this capability implemented in UAs, it must be a MUST in the text, or. alternatively, we must have a new header/field where the realm can be placed. the same goes for the P header. i don't know any general purpose sip ua that is implementing it. -- juha _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 28 09:13:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29294 for ; Fri, 28 Feb 2003 09:13:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SEO9N31614 for sipping-archive@odin.ietf.org; Fri, 28 Feb 2003 09:24:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SEO9p31611 for ; Fri, 28 Feb 2003 09:24:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29282 for ; Fri, 28 Feb 2003 09:13:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SENSp31571; Fri, 28 Feb 2003 09:23:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SEMwp31520 for ; Fri, 28 Feb 2003 09:22:58 -0500 Received: from e5.ny.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29253; Fri, 28 Feb 2003 09:11:55 -0500 (EST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.7/8.12.2) with ESMTP id h1SEFZJn049498; Fri, 28 Feb 2003 09:15:35 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1SEFWJA057170; Fri, 28 Feb 2003 09:15:33 -0500 Importance: Normal Subject: Re: [Sipping] Comments on draft-rosenberg-sipping-conferencing-framework-01.txt To: aroychow@hss.hns.com, Cc: sipping@ietf.org, sipping-admin@ietf.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Zon-Yin Shae Date: Fri, 28 Feb 2003 09:15:32 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|February 24, 2003) at 02/28/2003 09:15:33 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1SEMwp31521 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Overall the draft looks good. I wish this conference frame work can be extended to cover the following enterprise/service conferencing scenario: When an application need a conference service, it only creates a conference ID (and its associated policy). By the time the application does not know (does not want to or can not specify) which conference service ( Focus) to use. Moreover, it is desired for the performance and scalability that a set of Focuses should work collaboratively to perform the distributed conference service. For example, 20 participants in a conference, 10 in CA and 10 in NY, it is better to have two Focuses (one in CA and one in NY) to jointly perform the service. Protocols among Focuses are required. Also, most of VoIP phone does support ad-hoc conference capability and is an useful media mixing resource. It can be useful (for the resource usage and scalability) that the Focus can delegate some of the media mixing function to be performed in these phones of the conference participants. Protocols among Focus and participants are required. There are some components are required in the above scenario to achieve the dynamic conference configuration. . 1. A conference is identified by a conference ID. A conference might be collaboratively serviced by more than one Focuses. Since URI is used for routing to only one UA, it would be more appropriate to carry the conference ID (and its associated policy) in the payload with standard URI. 2. The default Focus for a UA can be pre-configured or discovered using similar procedure of outbound proxy (or proxy server). 3. Protocols among Focuses (and conference policy server) are required. The Subscribe and Notify SIP mechanism with extended SDP can be used among Focuses to establish a collaboratively distributed service for a conference. 4. Protocols between Focus (and conference policy server) and participants are required. In Figure 2, the conference policy control protocol is only one way (from participant to conference policy server), it can be two way protocol to make use of the mixing resources in the participants (e.g., VoIP phone). One possibility is to extend REFER mechanism using (extended) SDP for carrying conferencing policy. Regards, zon-yin shae IBM Watson Research Center aroychow@hss.hns.com@ietf.org on 02/22/2003 10:37:44 AM Sent by: sipping-admin@ietf.org To: cc: sipping@ietf.org, sipping-admin@ietf.org Subject: Re: [Sipping] Comments on draft-rosenberg-sipping-conferencing-framework-01.txt Inline prefixed by The idea of having a unique URI for each conference is a good one. However a more scalable approach would be to have a master Focus or a group of them that register with a standard URI. This way users use a standard URI with a Conference ID as the payload in the Invite message.  This is directed to the master Focus that does the following * Retrieve the Conference ID * Check if a Focus corresponding to the conference exists * If the Conference specific Focus  does not exist create a new Focus with a unique URI derived from the Conference ID * Forward the call using the standard Refer mechanism to the new Focus with the Unique URI.  You may also want to read http://www.iptel.org/info/players/ietf/conferencing/draft-johnston-sipping-cc-conferencing-01.txt . Its provides the definition of a conference Factory URI, which could be used to create new conferences and their Focii. Note that when you send an INVITE to a factory URI, that entity returns the actual Conference-URI in the Contact header. Also, you may be using a central 'conference enabling application' that  asks you lots of questions before allowing you to create/join  a new conference. See an example of that in 4.3 of alan/orit's draft. Note however , that when you want to use a "standard wellknown URI" that has not been published to you by the conference server, you are assuming that there is some agreement for that domain on conference naming policies. I am not sure I like your idea of a payload contaning conf-id (what use is that ?) Also, note that for scalability (if thats your primary concern), this mechanism allows a way for you to start with a 'guessed URI' and from then on communicate directly with you assigned focus without routing everthing to what you call your 'master focus'. Instead of dealing with Conference aware UA's and Conference Unaware UA's we could assume all participants in the Conference to be Conference Aware. The Conference Unaware participants are routed through a Gateway (e.g. an IVR ) that provides a primitive interface to the conference unaware participants and a Conference aware interface to the Conference itself.  This would keep the model simpler and it can allow Conference aware UAs a way to control the conference.  It is extremely important to acknowledge conference-unaware endpoints. You cannot assume an IVR or any other application in all conference scenarios who 'aware' on behalf of an unaware UA. Again, reading both Jonathan and Alan/Orit's draft in conjunction may motivate you more on the requirement of conference unaware UAs. Remeber also , that most of the EPs deployed in SIP have zilch idea of what isFocus is as well as will not be aware of protocols to moderate a conference for a while. The other comment was in the area of the Conference policy control protocol. Is this something like the SDP which is carried as a payload in SIP or does it have specifics of it's own. Currently most of the operations that are part of the CPCP are also possible through SIP based mechanisms. Is there a need to define two parallel mechanisms within the same framework. I think what has been identifed here is a need for a conference policy control protocol. It is not ascertained yet which protocol will deliver these requirements. Thats as far as I know. The existing SDP specs do not meet all control requirements that come to my mind. Alan - would you mind reposting that link of conferencing work in progress  ? I thought I noticed some drafts attempting to address this in more detail Now a question again for the authors of  draft-johnston-sipping-cc-conferencing-01.txt: * section 4.5 callflow - you show alice sending an invite to a conf-factory URI but the ladder diagram shows it being received by a 'Focus'. The definition of a focus 3.1 Focus UA   A focus, as defined in the framework, hosts a SIP conference and   maintains a SIP signaling relationship with each participant in the   conference. A focus contains a conference-aware user agent that   supports the conferencing call control conventions as defined in this   document. Since a 'Focus' hosts 'a specific' conference, I find it a little disconcerting that the call flows show messages with a factory-URI reaching a focus. I thought it may be clearer, if we limit a 'focus' to be the target of a specific URI meant for a specific conference. If a person sends an INVITE to a factory-URI or a 'conf-app-URI' < like an IVR etc which then contacts a Factory after auth etc> it should not be received by a Focus, should it ? regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems 11717 Exploration Lane, Germantown MD 20876 (O): 301 212 7860  (M): 240 997 0066{@vtext.com} "Shiva"         To:         Sent by:         cc: sipping-admin@ietf.o         Subject:        [Sipping] rg Comments on draft-rosenberg-sipping-conferencing-fram 02/22/2003 01:57 AM ework-01.txt Please respond to shaj Hello, Overall the draft looks good.  Here are some of my comments on this draft The advantage of doing this is that I could have multiple Conference servers that are running that are registered their master focus. We can implement Load Balancing across Conference servers without the UA realizing it as it is not connecting to a specific Focus on a specific server. A second advantage is that if in the course of a meeting if the focus were to go down or the server went down the participants can attempt to rejoin the call. In such a case the Master Focus would see that the Conference specific focus is down and recreate it allowing users to quickly rejoin the conference. Of course one needs to work out the details of the communication and keepalive between the Master Focus and the Conference focus it creates. The other advantage is if there are global Conference policies these can be applied at the master and the Individual Conference focus needs to worry about the specifics of the conference it is dealing with. The other comment was in the area of the Conference policy control protocol. Is this something like the SDP which is carried as a payload in SIP or does it have specifics of it's own. Currently most of the operations that are part of the CPCP are also possible through SIP based mechanisms. Is there a need to define two parallel mechanisms within the same framework. Instead of dealing with Conference aware UA's and Conference Unaware UA's we could assume all participants in the Conference to be Conference Aware. The Conference Unaware participants are routed through a Gateway (e.g. an IVR ) that provides a primitive interface to the conference unaware participants and a Conference aware interface to the Conference itself.  This would keep the model simpler and it can allow Conference aware UAs a way to control the conference. Regards Shiva Cisco Systems _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 28 13:46:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08701 for ; Fri, 28 Feb 2003 13:46:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SIvQQ19245 for sipping-archive@odin.ietf.org; Fri, 28 Feb 2003 13:57:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SIvQp19242 for ; Fri, 28 Feb 2003 13:57:26 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08690 for ; Fri, 28 Feb 2003 13:46:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SIrSp19119; Fri, 28 Feb 2003 13:53:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SIqHp19065 for ; Fri, 28 Feb 2003 13:52:17 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08605 for ; Fri, 28 Feb 2003 13:41:09 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA25237 for ; Fri, 28 Feb 2003 13:45:04 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA17323 for ; Fri, 28 Feb 2003 13:45:06 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Feb 2003 13:45:05 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5EEF@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'sipping@ietf.org'" Date: Fri, 28 Feb 2003 13:45:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] Facing Up to Realities in SIP Deployments in Carrier networks Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , I urge you to read: http://www.vasaforum.org/Docs/SIPRFIAnalysisFinal-Web1202.doc It contains a sobering assessment of where we are in SIP deployment in carrier networks. Of course, carrier networks are not the only place SIP has a place, but this assessment still rings of truth to me beyond this specific market, and spurs me to ask what we in the IETF SIPish community can do to address the issues this report cites. First, read it. Then we can talk. Brian _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 28 14:48:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10454 for ; Fri, 28 Feb 2003 14:48:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SJx6Y23292 for sipping-archive@odin.ietf.org; Fri, 28 Feb 2003 14:59:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SJx6p23289 for ; Fri, 28 Feb 2003 14:59:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10431 for ; Fri, 28 Feb 2003 14:47:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SJtMp23089; Fri, 28 Feb 2003 14:55:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SJs2p23034 for ; Fri, 28 Feb 2003 14:54:02 -0500 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10290 for ; Fri, 28 Feb 2003 14:42:53 -0500 (EST) Received: from rshockeybox.shockey.us (h-69-3-5-197.MCLNVA23.covad.net [69.3.5.197]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id LAA30051; Fri, 28 Feb 2003 11:46:31 -0800 Message-Id: <5.2.0.9.2.20030228142656.04748988@shockey.us> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 28 Feb 2003 14:46:26 -0500 To: "Rosen, Brian" , "'sipping@ietf.org'" From: Richard Shockey Subject: Re: [Sipping] Facing Up to Realities in SIP Deployments in Carrier networks In-Reply-To: <313680C9A886D511A06000204840E1CF030B5EEF@whq-msgusr-02.pit .comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , At 01:45 PM 2/28/2003 -0500, Rosen, Brian wrote: >I urge you to read: >http://www.vasaforum.org/Docs/SIPRFIAnalysisFinal-Web1202.doc > >It contains a sobering assessment of where we are in SIP deployment >in carrier networks. Of course, carrier networks are not the >only place SIP has a place, but this assessment still rings of >truth to me beyond this specific market, and spurs me to ask what >we in the IETF SIPish community can do to address the issues this >report cites. > >First, read it. Then we can talk. > >Brian Brian ..why would anything in this report suprise you ..its essentially written by and for existing carriers who essentially look at VoIP as cannibalistic to their existing revenue streams. Where SIP is deploying in competitive greenfield carrier environments such as Yahoo/Japan, Vonage, China etc its working very well and we all have heard of extremely positive user experiences from ordinary consumers. I can almost agree with some the LEC's, to them there is no justification for SIP. Why should they engineer themselves out of monopoly profits ( and jobs ) to provide real and tangeable consumer benefits of lower costs and greater choice of services when the existing regulatory environment does not reward them for doing so.. I agree there are still major issues here ..DTMF, E911 and other government mandated services.. and If I hear any more whining about OoS from people who have never made a SIP phone call I'm just going to scream.. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 28 15:18:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12300 for ; Fri, 28 Feb 2003 15:18:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SKS5J25481 for sipping-archive@odin.ietf.org; Fri, 28 Feb 2003 15:28:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SKS5p25478 for ; Fri, 28 Feb 2003 15:28:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12282 for ; Fri, 28 Feb 2003 15:18:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SKOFp25347; Fri, 28 Feb 2003 15:24:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SKNfp25299 for ; Fri, 28 Feb 2003 15:23:41 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12090 for ; Fri, 28 Feb 2003 15:13:24 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA29347; Fri, 28 Feb 2003 15:16:26 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA29549; Fri, 28 Feb 2003 15:16:28 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Feb 2003 15:16:27 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5EF2@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Richard Shockey'" , "'sipping@ietf.org'" Subject: RE: [Sipping] Facing Up to Realities in SIP Deployments in Carrie r networks Date: Fri, 28 Feb 2003 15:16:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1SKNfp25300 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Richard I don't think getting into speculation on what motivates carriers to deploy SIP is germane. What is germane is: · If SIP-related standardization efforts has been slowing deployment. · If there are significant difficulties in interworking different vendors' products in laboratory trials of both SIP to SIP and SIP to legacy network element interoperability. · If Efforts to provide lawful intercept and emergency services will be hampered by the nature of SIP-based networks. · If potential users have difficulty comparing products because everyone uses different scalability metrics · If NAT and firewall traversal is a major issue limiting the deployment of SIP · If a standard framework for basic authentication and privacy of SIP-based communication is required · If there are significant new security issues relating to: - Interception of signaling and media traffic - Introduction of malicious traffic through open interfaces to SIP endpoints or other networks - The need to authenticate endpoints through insecure networks - Securing network and service management interfaces based on open standards. Note that the above list is largely text lifted from the document. If I think through these issues, I think most of them are just flat out true. It may be that some service providers don't care about them, but I think most will. I think that it is well worth our while to sort through this list and figure out if the problems can be solved, and how they should be solved. It may be that IETF is not the right place to solve all of them. Brian > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Friday, February 28, 2003 2:46 PM > To: Rosen, Brian; 'sipping@ietf.org' > Subject: Re: [Sipping] Facing Up to Realities in SIP Deployments in > Carrier networks > > > At 01:45 PM 2/28/2003 -0500, Rosen, Brian wrote: > >I urge you to read: > >http://www.vasaforum.org/Docs/SIPRFIAnalysisFinal-Web1202.doc > > > >It contains a sobering assessment of where we are in SIP deployment > >in carrier networks. Of course, carrier networks are not the > >only place SIP has a place, but this assessment still rings of > >truth to me beyond this specific market, and spurs me to ask what > >we in the IETF SIPish community can do to address the issues this > >report cites. > > > >First, read it. Then we can talk. > > > >Brian > > > Brian ..why would anything in this report suprise you ..its > essentially > written by and for existing carriers who essentially look at VoIP as > cannibalistic to their existing revenue streams. Where SIP is > deploying in > competitive greenfield carrier environments such as > Yahoo/Japan, Vonage, > China etc its working very well and we all have heard of > extremely positive > user experiences from ordinary consumers. > > I can almost agree with some the LEC's, to them there is no > justification > for SIP. Why should they engineer themselves out of monopoly > profits ( and > jobs ) to provide real and tangeable consumer benefits of > lower costs and > greater choice of services when the existing regulatory > environment does > not reward them for doing so.. > > I agree there are still major issues here ..DTMF, E911 and other > government mandated services.. > > and If I hear any more whining about OoS from people who have > never made a > SIP phone call I'm just going to scream.. > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology Initiatives > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 > or > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 mailnull@www1.ietf.org Fri Feb 28 16:11:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13468 for ; Fri, 28 Feb 2003 16:11:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SLK9a28727 for sipping-archive@odin.ietf.org; Fri, 28 Feb 2003 16:20:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SLK9p28724 for ; Fri, 28 Feb 2003 16:20:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13460 for ; Fri, 28 Feb 2003 16:10:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SLGKp28547; Fri, 28 Feb 2003 16:16:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SLF9p28519 for ; Fri, 28 Feb 2003 16:15:09 -0500 Received: from dgesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13337 for ; Fri, 28 Feb 2003 16:05:58 -0500 (EST) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0HB100M7MEMYGG@firewall.wcom.com> for sipping@ietf.org; Fri, 28 Feb 2003 21:06:34 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HB100401EK3Y6@pmismtp03.wcomnet.com>; Fri, 28 Feb 2003 21:06:34 +0000 (GMT) Received: from hsinnreich2 ([166.35.136.36]) by pmismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HB1004GIEMLFL@pmismtp03.wcomnet.com>; Fri, 28 Feb 2003 21:06:22 +0000 (GMT) Date: Fri, 28 Feb 2003 15:06:21 -0600 From: Henry Sinnreich Subject: RE: [Sipping] Facing Up to Realities in SIP Deployments in Carrie r networks In-reply-to: <313680C9A886D511A06000204840E1CF030B5EF2@whq-msgusr-02.pit.comms.marconi.com> To: "'Rosen, Brian'" , "'Richard Shockey'" , sipping@ietf.org Message-id: <000001c2df6d$3ebd7c30$248823a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I am not sure this is the right place for this discussion and that the points here are really true or even more, are they relevant? Not to speak of > > and If I hear any more whining about OoS from people who have > > never made a > > SIP phone call I'm just going to scream.. Get used to it: IP-IP phone calls over the public Internet are just better than the PSTN and lab tests have shown the same for SIP based IP conferencing. With such concerns, we would not have a booming mobile phone industry today, and as we know, concerns or not, mobile phones and the Internet have already started to bite into the "carrier grade" networks where all these concerns are presumably well taken care of. I will spare this list of why/who is already using or is going to use SIP, and for very good reasons :-)> >It may be that IETF is not the right place to > solve all of them. Right. Thanks, Henry > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of Rosen, Brian > Sent: Friday, February 28, 2003 2:16 PM > To: 'Richard Shockey'; 'sipping@ietf.org' > Subject: RE: [Sipping] Facing Up to Realities in SIP > Deployments in Carrie r networks > > > Richard > > I don't think getting into speculation on what motivates > carriers to deploy SIP is germane. What is germane is: > . If SIP-related standardization efforts has been slowing > deployment. > . If there are significant difficulties in interworking different > vendors' products in laboratory trials of both SIP to SIP and > SIP to legacy network element interoperability. > . If Efforts to provide lawful intercept and emergency > services will > be hampered by the nature of SIP-based networks. > . If potential users have difficulty comparing products because > everyone uses different scalability metrics > . If NAT and firewall traversal is a major issue limiting the > deployment of SIP > . If a standard framework for basic authentication and privacy of > SIP-based communication is required > . If there are significant new security issues relating to: > - Interception of signaling and media traffic > - Introduction of malicious traffic through open interfaces to SIP > endpoints or other networks > - The need to authenticate endpoints through insecure networks > - Securing network and service management interfaces based on open > standards. > > Note that the above list is largely text lifted from the document. > > If I think through these issues, I think most of them are > just flat out true. It may be that some service providers > don't care about them, but I think most will. I think that > it is well worth our while to sort through this list and > figure out if the problems can be solved, and how they should > be solved. It may be that IETF is not the right place to > solve all of them. > > Brian > > > -----Original Message----- > > From: Richard Shockey [mailto:richard@shockey.us] > > Sent: Friday, February 28, 2003 2:46 PM > > To: Rosen, Brian; 'sipping@ietf.org' > > Subject: Re: [Sipping] Facing Up to Realities in SIP Deployments in > > Carrier networks > > > > > > At 01:45 PM 2/28/2003 -0500, Rosen, Brian wrote: > > >I urge you to read: > > >http://www.vasaforum.org/Docs/SIPRFIAnalysisFinal-Web1202.doc > > > > > >It contains a sobering assessment of where we are in SIP > deployment > > >in carrier networks. Of course, carrier networks are not the only > > >place SIP has a place, but this assessment still rings of > truth to me > > >beyond this specific market, and spurs me to ask what we > in the IETF > > >SIPish community can do to address the issues this report cites. > > > > > >First, read it. Then we can talk. > > > > > >Brian > > > > > > Brian ..why would anything in this report suprise you ..its > > essentially > > written by and for existing carriers who essentially look > at VoIP as > > cannibalistic to their existing revenue streams. Where SIP is > > deploying in > > competitive greenfield carrier environments such as > > Yahoo/Japan, Vonage, > > China etc its working very well and we all have heard of > > extremely positive > > user experiences from ordinary consumers. > > > > I can almost agree with some the LEC's, to them there is no > > justification > > for SIP. Why should they engineer themselves out of monopoly > > profits ( and > > jobs ) to provide real and tangeable consumer benefits of > > lower costs and > > greater choice of services when the existing regulatory > > environment does > > not reward them for doing so.. > > > > I agree there are still major issues here ..DTMF, E911 and other > > government mandated services.. > > > > and If I hear any more whining about OoS from people who have > > never made a > > SIP phone call I'm just going to scream.. > > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > Richard Shockey, Senior Manager, Strategic Technology Initiatives > > NeuStar Inc. > > 46000 Center Oak Plaza - Sterling, VA 20166 > > Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 > > or > > ; > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the 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 mailnull@www1.ietf.org Fri Feb 28 16:13:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13525 for ; Fri, 28 Feb 2003 16:13:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SLM3028796 for sipping-archive@odin.ietf.org; Fri, 28 Feb 2003 16:22:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SLM3p28793 for ; Fri, 28 Feb 2003 16:22:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13497 for ; Fri, 28 Feb 2003 16:12:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SLI9p28644; Fri, 28 Feb 2003 16:18:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SLHhp28621 for ; Fri, 28 Feb 2003 16:17:43 -0500 Received: from rainier.illuminet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13412 for ; Fri, 28 Feb 2003 16:08:32 -0500 (EST) Received: from olwinexsmtp01.corp.illuminet.com (olwinexsmtp01.corp.illuminet.com [10.55.13.9]) by rainier.illuminet.com (8.8.8/8.8.8) with ESMTP id NAA24081; Fri, 28 Feb 2003 13:09:56 -0800 (PST) Received: by olwinexsmtp01.corp.illuminet.com with Internet Mail Service (5.5.2656.59) id ; Fri, 28 Feb 2003 13:09:56 -0800 Message-ID: <90B62898D7B43B448D1A7297980A8C5F6CE642@opwinex01.corp.illuminet.com> From: Kevin McCandless To: "'Richard Shockey'" , "Rosen, Brian" , "'sipping@ietf.org'" Subject: RE: [Sipping] Facing Up to Realities in SIP Deployments in Carrie r networks Date: Fri, 28 Feb 2003 13:09:55 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , comments inline..... > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Friday, February 28, 2003 1:46 PM > To: Rosen, Brian; 'sipping@ietf.org' > Subject: Re: [Sipping] Facing Up to Realities in SIP Deployments in > Carrier networks > > > At 01:45 PM 2/28/2003 -0500, Rosen, Brian wrote: > >I urge you to read: > >http://www.vasaforum.org/Docs/SIPRFIAnalysisFinal-Web1202.doc > > > >It contains a sobering assessment of where we are in SIP deployment > >in carrier networks. Of course, carrier networks are not the > >only place SIP has a place, but this assessment still rings of > >truth to me beyond this specific market, and spurs me to ask what > >we in the IETF SIPish community can do to address the issues this > >report cites. > > > >First, read it. Then we can talk. > > > >Brian > > > Brian ..why would anything in this report suprise you ..its > essentially > written by and for existing carriers who essentially look at VoIP as > cannibalistic to their existing revenue streams. Where SIP is > deploying in > competitive greenfield carrier environments such as > Yahoo/Japan, Vonage, > China etc its working very well and we all have heard of > extremely positive > user experiences from ordinary consumers. That is one person's opinion. We have a representative on the VASA Forum and they do not portray the negative motives that are seen here. The main point is economics. Does SIP/VOIP provide financial advantage to carriers and is it mature enough for full scale deployment? The resounding answer is NO! The carriers that did chase VOIP are either in chapter 11 or dissembled and the equipment sold in an online auction. > > I can almost agree with some the LEC's, to them there is no > justification > for SIP. Why should they engineer themselves out of monopoly > profits ( and > jobs ) to provide real and tangeable consumer benefits of > lower costs and > greater choice of services when the existing regulatory > environment does > not reward them for doing so.. > > I agree there are still major issues here ..DTMF, E911 and other > government mandated services.. > > and If I hear any more whining about OoS from people who have > never made a > SIP phone call I'm just going to scream.. QOS is a major issue. Many carriers have not deployed the underlying transport Qos to support application like SIP. What carriers offer end to end QOS? How many carriers have fully deployed the necessary MPLS and DIFFSERV technology?? Wake up and smell the coffee. The VASA report is the coffee. It may be a little bitter for those in Latte Land ;-) > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology Initiatives > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 > or > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 mailnull@www1.ietf.org Fri Feb 28 17:09:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14975 for ; Fri, 28 Feb 2003 17:09:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SMILY32710 for sipping-archive@odin.ietf.org; Fri, 28 Feb 2003 17:18:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SMILp32707 for ; Fri, 28 Feb 2003 17:18:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14963 for ; Fri, 28 Feb 2003 17:09:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SMEFp32509; Fri, 28 Feb 2003 17:14:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SMDnp32483 for ; Fri, 28 Feb 2003 17:13:49 -0500 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14782 for ; Fri, 28 Feb 2003 17:04:36 -0500 (EST) Received: from rshockeybox.shockey.us (h-69-3-5-197.MCLNVA23.covad.net [69.3.5.197]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id OAA04540; Fri, 28 Feb 2003 14:06:15 -0800 Message-Id: <5.2.0.9.2.20030228161742.023e9d28@shockey.us> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 28 Feb 2003 17:03:59 -0500 To: "Rosen, Brian" , "'sipping@ietf.org'" From: Richard Shockey Subject: RE: [Sipping] Facing Up to Realities in SIP Deployments in Carrie r networks In-Reply-To: <313680C9A886D511A06000204840E1CF030B5EF2@whq-msgusr-02.pit .comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1SMDnp32484 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit At 03:16 PM 2/28/2003 -0500, Rosen, Brian wrote: >Richard > >I don't think getting into speculation on what motivates carriers >to deploy SIP is germane. It is precisely germane... what motivates carriers is money, fear, greed and the economic benefits of one technology vs another, as well the regulatory environment they must live in. This report is a classic version of whining why they do'n't want to deploy a superior form of technology when the real reasons are manifestly self evident to anyone who cares to read their balance sheets or understand the regulatory constraints many of them live with. Most carriers are bankrupt, on the verge of bankruptcy, or worry about bankruptcy..and that includes US LEC's, major European PTT's and even NTT in Japan as well .. >What is germane is: >· If SIP-related standardization efforts has been slowing deployment. IMHO no though the IETF does have it own unique ways of doing things the process for SIP has been successful and open.. unlike that of the ITU..and need I remind you how many years it took the ITU to produce anything in H.323 that resembled inter operability? That we have been able to produce as much as we have in as short a period of time and reverse the tide of technical opinion on H.323 is a near miracle and a testament to the Herculean work of SIP, SIPPING and SIMPLE WG's. >· If there are significant difficulties in interworking different >vendors' products in laboratory trials of both SIP to SIP and SIP to legacy >network element interoperability. I cannot directly address the results of SIPit trials since my company does not directly have SIP products. I trust others can adequately address this issue. >· If Efforts to provide lawful intercept and emergency services will >be hampered by the nature of SIP-based networks. Our community is working on this and I believe we can deliver a better E911 than is currently deployed. At to the intercept issue .. geez I'm sorry ..any ISP with a decent packet sniffer is already reading all of their traffic.... to the FBI, NSA , MI5 etal the Internet is the greatest bonanza for intercept ever created.. nothing is encrypted find the ports and you can get suck in whatever you want. NOT one ISP on the planet is not reading or sampling headers right now in order for them to optimize the route announcements on their network or make fundamental economic decisions about about how to transit or peer their traffic. >· If potential users have difficulty comparing products because >everyone uses different scalability metrics I'M SHOCKED I'M SHOCKED marketing guys devise smoke and mirrors to describe the features and benefits of their products. >· If NAT and firewall traversal is a major issue limiting the >deployment of SIP Ok ..this is a problem .for consumer markets not for sensible enterprises that acquire their own routeable blocks of addreses. This is a larger problem of v4 vs v6 addressing we cannot solve here. >· If a standard framework for basic authentication and privacy of >SIP-based communication is required Privacy ... what privacy ...the entire signalling and media path is in the open but that does not seem to bother folks using SMTP. I'd love opportunistic encryption of both the signalling and media paths but I've yet to see the problem adequately dealt with in email ..so why is this suddenly a concern? >· If there are significant new security issues relating to: >- Interception of signaling and media traffic M&M attacks sure .. >- Introduction of malicious traffic through open interfaces to SIP >endpoints or other networks Well Brian ..yes you are right on target here ..the last thing we need is open SIP "relays" >- The need to authenticate endpoints through insecure networks >- Securing network and service management interfaces based on open >standards. > >Note that the above list is largely text lifted from the document. but its exactly what a legacy bunch of PPT bellheads would say .. thats my point.. >If I think through these issues, I think most of them are just flat out >true. Brian the simple problem effecting SIP deployment is much much larger..it goes to the heart of the current telecom meltdown and the implied threat that IP Communications has on carrier revenues. Once upon a time this was all a academic exercise to some service providers ...."oh yes this is very interesting we need to know more about blah blah" ..but times have changed and it is clear that from a purely revenue perspective VoIP is having a negative effect on TDM/SP revenues . VoIP dominated by H.323 now has 10% of the global market and has ripped 20 BILLION dollars out of the hands of International transport SP's. The effect at the margin of SIP as it deploys in greenfield is amazing etc. Its effect on national LD rates is pronounced its clear ..at least in the US we are seeing the beginning of flat rate monthly distance free pricing, though I will submit that mobile is having a effect on these models as well. I noted with some amusement the line in the document ..that there is no economic justification for deploying ENUM. Well HELLO..... I've had this conversation .. the reply I got from a major US LEC I spoke to was "OK what you are telling me enterprises are going to do this eventually but if I deploy this I'm going EBIDA negative in 24 months." >It may be that some service providers don't care about them, but I think >most will. It depends on how high you sit on the PPT management food chain > I think that it is well worth our while to sort through this >list and figure out if the problems can be solved, and how they should be >solved. It may be that IETF is not the right place to solve all of them. Well I can tell you where they will be solved ....in the US it will be in either the bankruptcy courts or the FCC. >Brian >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 28 17:57:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15819 for ; Fri, 28 Feb 2003 17:57:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SN6Gg02529 for sipping-archive@odin.ietf.org; Fri, 28 Feb 2003 18:06:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SN6Gp02526 for ; Fri, 28 Feb 2003 18:06:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15812 for ; Fri, 28 Feb 2003 17:57:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SN1Op02317; Fri, 28 Feb 2003 18:01:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SN0xp02252 for ; Fri, 28 Feb 2003 18:00:59 -0500 Received: from joy.songbird.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15755 for ; Fri, 28 Feb 2003 17:51:45 -0500 (EST) Received: from rshockeybox.shockey.us (h-69-3-5-197.MCLNVA23.covad.net [69.3.5.197]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id OAA07061; Fri, 28 Feb 2003 14:53:24 -0800 Message-Id: <5.2.0.9.2.20030228170758.022147b8@shockey.us> X-Sender: richard@shockey.us X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 28 Feb 2003 17:53:19 -0500 To: Kevin McCandless , "Rosen, Brian" , "'sipping@ietf.org'" From: Richard Shockey Subject: RE: [Sipping] Facing Up to Realities in SIP Deployments in Carrie r networks In-Reply-To: <90B62898D7B43B448D1A7297980A8C5F6CE642@opwinex01.corp.illu minet.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: , I can see this quickly getting out of hand and out of scope ..but one last parting shot then I'll retreat back to lurker land.... > > Brian ..why would anything in this report suprise you ..its > > essentially > > written by and for existing carriers who essentially look at VoIP as > > cannibalistic to their existing revenue streams. Where SIP is > > deploying in > > competitive greenfield carrier environments such as > > Yahoo/Japan, Vonage, > > China etc its working very well and we all have heard of > > extremely positive > > user experiences from ordinary consumers. > >That is one person's opinion. We have a representative on the VASA Forum >and they do not portray the negative motives that are seen here. The main >point is economics. Does SIP/VOIP provide financial advantage to carriers >and is it mature enough for full scale deployment? The word you missed was EXISTING carriers....to a greenfield player SIP works Japan is teaching us this ...If you have a massive investment in a C5 infrastructure and a 20 year depreciation schedule .yes there is a big problem here :-) > The resounding answer is >NO! The carriers that did chase VOIP are either in chapter 11 or dissembled >and the equipment sold in an online auction. Well a bit too much early "irrational exuberance" is classic market behavior for "disruptive technologies" but any competitent business historian will be delighted to remind you that it is usually the second wave of companies deploying technology that typically reaps the major economic gains. Microsoft being the classic case in point (they bought DOS and Word remember) ... and Kevin.. I'd be delighted to hear your views on the market effect of the MS Greenwich server on service provider revenues going forward. > > > > I can almost agree with some the LEC's, to them there is no > > justification > > for SIP. Why should they engineer themselves out of monopoly > > profits ( and > > jobs ) to provide real and tangeable consumer benefits of > > lower costs and > > greater choice of services when the existing regulatory > > environment does > > not reward them for doing so.. > > >QOS is a major issue. Many carriers have not deployed the underlying >transport Qos to support application like SIP. What carriers offer end to >end QOS? How many carriers have fully deployed the necessary MPLS and >DIFFSERV technology?? Kevin ..sorry ...this is just Bovine Effluent.. I'm sorry to lash out to you like this since I respect your opinion and work in other forums, but I believe you are dead wrong. MPLS and DIFSERVE have nothing to do with VoIP QoS.. even a modest VoIP carrier like ITXC does not need this kind of senseless overhead when they can monitor packet traffic effectively using clever techniques such as statistical analysis of traceroute data and reroute accordingly. Any major IP back bone carrier ..when pressed will tell you that capability utilization in the back bone is about 20%. If you can get the traffic to the back bone you are home free. The bottlenecks to VoIP are typically the internal LAN that does not have 802.p priority bitting in their switch fabric and the access link. This is what I hear from VoIP service providers slugging it out with customers day to day. There is not the slightest doubt in my mind based on reports and presentations by IP Professionals that ATT, UUnet or Sprint .. individually could carry the entire voice traffic of the planet Earth via SIP on their networks and not even hiccup. >Wake up and smell the coffee. The VASA report is the coffee. It may be a >little bitter for those in Latte Land ;-) This report strikes me a decaf .. fundamentally useless. The key moving forward is can consumer or enterprises buy IP transport independently of SIP service delivery. SIP is fundamentally an application on the Internet not a service of the network. Kevin on this I think we agree ..competition in telecom applications is a good thing. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Feb 28 17:57:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15832 for ; Fri, 28 Feb 2003 17:57:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SN6NC02545 for sipping-archive@odin.ietf.org; Fri, 28 Feb 2003 18:06:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SN6Mp02542 for ; Fri, 28 Feb 2003 18:06:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15816 for ; Fri, 28 Feb 2003 17:57:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SN29p02383; Fri, 28 Feb 2003 18:02:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SN1Wp02330 for ; Fri, 28 Feb 2003 18:01:32 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15772 for ; Fri, 28 Feb 2003 17:52:17 -0500 (EST) Received: from dingdong.cisco.com (IDENT:mirapoint@dingdong.cisco.com [64.102.17.16]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1SMsBNh029684; Fri, 28 Feb 2003 17:54:11 -0500 (EST) Received: from cisco.com (dhcp-64-102-93-200.cisco.com [64.102.93.200]) by dingdong.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABP68127; Fri, 28 Feb 2003 17:50:32 -0500 (EST) Message-ID: <3E5FE892.25339D1E@cisco.com> Date: Fri, 28 Feb 2003 17:54:10 -0500 From: Nilesh Trivedi X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Richard Shockey CC: "Rosen, Brian" , "'sipping@ietf.org'" Subject: Re: [Sipping] Facing Up to Realities in SIP Deployments inCarrie r networks References: <5.2.0.9.2.20030228161742.023e9d28@shockey.us> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit You make some interesting and realistic points about carrier deployments but are we trying to solve economical issues here ?? Brian, I understood that the goal of the paper you posted was purely technological in nature since most of the points you made addressed technical short-comings or issues the protocol is trying to deal with. More inline; Richard Shockey wrote: > At 03:16 PM 2/28/2003 -0500, Rosen, Brian wrote: > >Richard > > > >I don't think getting into speculation on what motivates carriers > >to deploy SIP is germane. > > It is precisely germane... what motivates carriers is money, fear, greed > and the economic benefits of one technology vs another, as well the > regulatory environment they must live in. This report is a classic version > of whining why they do'n't want to deploy a superior form of technology > when the real reasons are manifestly self evident to anyone who cares to > read their balance sheets or understand the regulatory constraints many of > them live with. > > Most carriers are bankrupt, on the verge of bankruptcy, or worry about > bankruptcy..and that includes US LEC's, major European PTT's and even NTT > in Japan as well .. > > >What is germane is: > >· If SIP-related standardization efforts has been slowing deployment. > > IMHO no though the IETF does have it own unique ways of doing things the > process for SIP has been successful and open.. unlike that of the ITU..and > need I remind you how many years it took the ITU to produce anything in > H.323 that resembled inter operability? That we have been able to produce > as much as we have in as short a period of time and reverse the tide of > technical opinion on H.323 is a near miracle and a testament to the > Herculean work of SIP, SIPPING and SIMPLE WG's. > > >· If there are significant difficulties in interworking different > >vendors' products in laboratory trials of both SIP to SIP and SIP to legacy > >network element interoperability. > > I cannot directly address the results of SIPit trials since my company does > not directly have SIP products. I trust others can adequately address this > issue. > > >· If Efforts to provide lawful intercept and emergency services will > >be hampered by the nature of SIP-based networks. > > Our community is working on this and I believe we can deliver a better E911 > than is currently deployed. What community are you referring to ??? > At to the intercept issue .. geez I'm sorry > ..any ISP with a decent packet sniffer is already reading all of their > traffic.... to the FBI, NSA , MI5 etal the Internet is the greatest bonanza > for intercept ever created.. nothing is encrypted find the ports and you > can get suck in whatever you want. > > NOT one ISP on the planet is not reading or sampling headers right now in > order for them to optimize the route announcements on their network or make > fundamental economic decisions about about how to transit or peer their > traffic. I think the point was totally missed. Nobody disagrees to the sniffing that you are pointing to but the point here is about creating specific holes in the deployment where the data can be specifically targetted for tapping and routed under the covers. This is covered as CALEA and regulatory requirements which to my knoweldge is still an issue with many SIP vendors out there. The question if I have to rephrase is: Does not having LI infrastructure a bottleneck to SIP deployment thereby discouraging carriers to not go the SIP route ?? > > > >· If potential users have difficulty comparing products because > >everyone uses different scalability metrics > > I'M SHOCKED I'M SHOCKED marketing guys devise smoke and mirrors to describe > the features and benefits of their products. > > >· If NAT and firewall traversal is a major issue limiting the > >deployment of SIP > > Ok ..this is a problem .for consumer markets not for sensible enterprises > that acquire their own routeable blocks of addreses. This is a larger > problem of v4 vs v6 addressing we cannot solve here. I disagree on both fronts. Where you say not a problem for enterprise, the fact of the matter is that NAT/PAT issues boil down to edges and this applies for all SIP deployments. Enterprises deal this with fronting thier border proxies that solve the translation problems but it still is an issue. On the other side of v4 and v6 addressing story, the reality is we are going to have v4 addresses for a longer period of time than previously thought and for successful SIP deployments, we ought to address it right here and I believe the WG is already working to find a common solution. > > > >· If a standard framework for basic authentication and privacy of > >SIP-based communication is required > > Privacy ... what privacy ...the entire signalling and media path is in the > open but that does not seem to bother folks using SMTP. I'd love > opportunistic encryption of both the signalling and media paths but I've > yet to see the problem adequately dealt with in email ..so why is this > suddenly a concern? > > > >· If there are significant new security issues relating to: > >- Interception of signaling and media traffic > > M&M attacks sure .. > > >- Introduction of malicious traffic through open interfaces to SIP > >endpoints or other networks > > Well Brian ..yes you are right on target here ..the last thing we need is > open SIP "relays" > > >- The need to authenticate endpoints through insecure networks > >- Securing network and service management interfaces based on open > >standards. > > > >Note that the above list is largely text lifted from the document. > > but its exactly what a legacy bunch of PPT bellheads would say .. thats my > point.. > > >If I think through these issues, I think most of them are just flat out > >true. > > Brian the simple problem effecting SIP deployment is much much larger..it > goes to the heart of the current telecom meltdown and the implied threat > that IP Communications has on carrier revenues. Once upon a time this was > all a academic exercise to some service providers ...."oh yes this is very > interesting we need to know more about blah blah" ..but times have changed > and it is clear that from a purely revenue perspective VoIP is having a > negative effect on TDM/SP revenues . VoIP dominated by H.323 now has 10% of > the global market and has ripped 20 BILLION dollars out of the hands of > International transport SP's. The effect at the margin of SIP as it > deploys in greenfield is amazing etc. Its effect on national LD rates is > pronounced its clear ..at least in the US we are seeing the beginning of > flat rate monthly distance free pricing, though I will submit that mobile > is having a effect on these models as well. > > I noted with some amusement the line in the document ..that there is no > economic justification for deploying ENUM. Well HELLO..... I've had this > conversation .. the reply I got from a major US LEC I spoke to was "OK > what you are telling me enterprises are going to do this eventually but if > I deploy this I'm going EBIDA negative in 24 months." > > >It may be that some service providers don't care about them, but I think > >most will. > > It depends on how high you sit on the PPT management food chain > > > I think that it is well worth our while to sort through this > >list and figure out if the problems can be solved, and how they should be > >solved. It may be that IETF is not the right place to solve all of them. > > Well I can tell you where they will be solved ....in the US it will be in > either the bankruptcy courts or the FCC. > > >Brian > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey, Senior Manager, Strategic Technology Initiatives > NeuStar Inc. > 46000 Center Oak Plaza - Sterling, VA 20166 > Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 > or > ; > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the 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 mailnull@www1.ietf.org Fri Feb 28 22:05:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21095 for ; Fri, 28 Feb 2003 22:05:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h213E7M15638 for sipping-archive@odin.ietf.org; Fri, 28 Feb 2003 22:14:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h213E7p15635 for ; Fri, 28 Feb 2003 22:14:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21092 for ; Fri, 28 Feb 2003 22:04:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2139mp15553; Fri, 28 Feb 2003 22:09:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2138Sp15502 for ; Fri, 28 Feb 2003 22:08:28 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20976 for ; Fri, 28 Feb 2003 21:59:09 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.6/8.12.6) with ESMTP id h21315F3026983; Fri, 28 Feb 2003 20:01:06 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] Questions regarding the draft-ietf-sipping-realtimefax-00.txt Date: Fri, 28 Feb 2003 20:01:05 -0700 Message-ID: Thread-Topic: [Sipping] Questions regarding the draft-ietf-sipping-realtimefax-00.txt thread-index: AcJPmY/sDsw+Q8CaT0up8YO2T0OSDSQA7wfA From: "Jean-Francois Mule" To: "Louis Guindon" , X-Approved: ondar Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2138Sp15503 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Louis, Sorry for the very late response, better later than never as they say... Good catch. See inline, this will be reflected in an upcoming update. Any objections to the understanding below? Jean-Francois. > -----Original Message----- > From: Louis Guindon [mailto:lguindon@mediatrix.com] > Sent: Thursday, August 29, 2002 1:59 PM > To: 'sipping@ietf.org' > Subject: [Sipping] Questions regarding the > draft-ietf-sipping-realtimefax-00.txt > > > Hi, > > I have question regarding the format of a att-field in the > SDP packet. In all examplesin the > draft-ietf-sipping-realtimefax-00.txt, we see > a=T38FaxFillBitRemoval:0 > a=T38FaxTranscodingMMR:0 > a=T38FaxTranscodingJBIG:0 > > In the section D.2.3 of ITU-T Rec. T.38 (04/2002) for > capabilities negotiation, it's stated that"Note that options > without values are boolean - their presence indicates that > they are valid for the session". This means that > "T38FaxFillBitRemoval", "T38FaxTranscodingMMR" and > "T38FaxTranscodingJBIG" are considered boolean. > > Only the present of T38FaxFillBitRemoval attribute without > value should be enough to determine if it's valid or not for > the session if I consider the RFC2327 (April 1998, page 18). > > Question: Why are we seeing the ":0" at the end? > > Can anyone confirm the following syntax for a SDP packet? > a=T38FaxFillBitRemoval <== Means valid > for the session > or incorrect syntax? This is the only correct option based on my reading of the latest T.38 recommendation (from 3/2002). Therefore, I have removed the media attribute lines for "T38FaxFillBitRemoval", "T38FaxTranscodingMMR" and "T38FaxTranscodingJBIG". > a=T38FaxFillBitRemoval:0 <== Means > invalid/valid for the > session? Incorrect syntax. But given some implementations, I'd recommend that implementaitons be flexible when receiving this media line attribute (if : is present, then get the boolean value)... > a=T38FaxFillBitRemoval:1 <== Means valid > for the session > or incorrect syntax? Incorrect syntax. > > Regards, > > > Louis Guindon > > Software Design Engineer > > Mediatrix Telecom, Inc. > > lguindon@mediatrix.com > > Tel : 819-829-8749 ext. 242 > > Fax : 819-829-1973 > > 4229, Garlock Street > > Sherbrooke, Qc J1L 2C8 > > > > This message and its attachment(s) contain protected > proprietary and > > confidential information of Mediatrix. It is intended > solely for the > > named addressee(s). If you are not an addressee indicated in this > > message (or responsible for delivery of the message to an > addressee), > > you may not copy or deliver this message or its attachment(s) to > > anyone. Rather, you should permanently delete this message and its > > attachment(s) and kindly notify the sender by email. No > warranty is > > made that the email or > > attachment(s) are free from computer virus or other defect. > > > > Ce message et son(ses) fichier(s) adjoint(s) peuvent contenir de > > l'information légale privilégiée ou confidentielle de > Mediatrix. Il > > est destiné exclusivement au(x) destinataire(s) > identifié(s). Si vous > > n'êtes pas un destinataire indiqué dans ce message (ou > responsable de > > la livraison du message au destinataire), vous ne pouvez copier ou > > livrer ce message ou son(ses) fichier(s) adjoint(s) à > quiconque. Vous > > devriez plutôt effacer de façon permanente ce message et son(ses) > > fichier(s) > > adjoint(s) et aimablement en avertir l'expéditeur par > courriel. Aucune > > garantie n'est donnée que ce courriel ou son(ses) > fichier(s) adjoint(s) ne > > contiennent pas de virus informatique ou autre défectuosité. > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP