From extest-admin@lists.bell-labs.com Fri Jun 1 05:00:44 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA03124 for ; Fri, 1 Jun 2001 05:00:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 023EE444D2 for ; Fri, 1 Jun 2001 05:00:11 -0400 (EDT) Subject: lists.bell-labs.com mailing list memberships reminder From: mailman-owner@lists.bell-labs.com To: iptel-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: extest-admin@lists.bell-labs.com Errors-To: extest-admin@lists.bell-labs.com X-BeenThere: extest@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk Message-Id: <20010601090011.023EE444D2@lists.bell-labs.com> Date: Fri, 1 Jun 2001 05:00:11 -0400 (EDT) This is a reminder, sent out once a month, about your lists.bell-labs.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, iptel-request@lists.bell-labs.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@lists.bell-labs.com. Thanks! Passwords for iptel-archive@lists.ietf.org: List Password // URL ---- -------- iptel@lists.bell-labs.com Gfcn http://lists.bell-labs.com/mailman/options/iptel/iptel-archive%40lists.ietf.org From iptel-admin@lists.bell-labs.com Fri Jun 1 20:54:18 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20203 for ; Fri, 1 Jun 2001 20:54:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7B31744418; Fri, 1 Jun 2001 20:54:10 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by lists.bell-labs.com (Postfix) with ESMTP id 9576344336; Fri, 1 Jun 2001 20:53:00 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01600; Fri, 1 Jun 2001 17:52:27 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28786 for corey@hearme.com; Fri, 1 Jun 2001 17:52:26 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12914 for ; Thu, 31 May 2001 10:46:33 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA17387 for ; Thu, 31 May 2001 10:46:32 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F2BC444427; Thu, 31 May 2001 13:43:14 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by lists.bell-labs.com (Postfix) with ESMTP id 0D860443A3; Thu, 31 May 2001 13:42:05 -0400 (EDT) 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 NAA07898; Thu, 31 May 2001 13:41:29 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA14833; Thu, 31 May 2001 13:41:31 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 31 May 2001 13:41:30 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044654D4@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: diffserv@ietf.org, iptel@lists.bell-labs.com, megaco@fore.com, sip@lists.bell-labs.com, tsvwg@ietf.org Cc: gratta@lucent.com, ITU-SG16@mailbag.cps.INTEL.COM MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk Content-Type: text/plain; charset="iso-8859-1" Subject: [IPTEL] [SIP] RE: [Sipping] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL M ECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 31 May 2001 13:41:29 -0400 Folks, this thread may or may not be the start of something good or evil, but it is going out to too many lists! Please, as of now, let's move it to one, and only one list. I nominate tsvwg. If you are replying to any message on this thread, PLEASE edit the to/cc to limit it to tsvwg@ietf.org Brian > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Thursday, May 31, 2001 1:09 PM > To: Roy, Radhika R, ALCTA > Cc: Bob Braden; gratta@lucent.com; sob@harvard.edu; mankin@isi.edu; > diffserv@ietf.org; iptel@lists.bell-labs.com; > issll@mercury.lcs.mit.edu; > megaco@fore.com; sip@lists.bell-labs.com; sipping@ietf.org; > tsvwg@ietf.org; hiramatsu.yukio@lab.ntt.co.jp; rbuhrke@lucent.com; > tsg11q8@ties.itu.ch; tsg11q9@ties.itu.ch; > ITU-SG16@mailbag.cps.INTEL.COM > Subject: [Sipping] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL > MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL > > > At 06:08 AM 5/31/2001, Roy, Radhika R, ALCTA wrote: > >All applications (e.g., H.323, SIP) uses signaling messages > >among its functional entities (e.g., terminal, agents, > >gatekeepers, proxies, gateways) for communications. > > I'm not sure we're on the same planet. Please help me out here. > > I can think of a few applications that have agents, > gatekeepers, proxies, > and gateways, mostly resulting from the imposition of firewalls or > authentication systems, or from legacy applications like > imitating the > telephone system in a data network. The only one that > *requires* any kind > of gateway, to my knowledge, is H.323 teleconferencing, which > represents a > paltry fraction of traffic according to most current > measurements. Anything > else (75% of Internet traffic is http or FTP, most of the > rest is mail, on > private LANs applications like NFS are pretty common, and > even SIP can be > done without a gateway between consenting systems) could be > hooked up in > separate systems on a LAN and made to work without any such > signalling at all. > > Could you be more specific on what QoS signalling is required > by the world > wide web, mail, FTP, common ERP applications like ERP and PeopleSoft, > calendaring, and so on? If not, could you be more specific > about what "all" > applications you have in mind? > > And could you be more specific about what issues this proposal is > addressing that have not already been addressed in de facto > standards and > deployed in operational systems? It would be very nice to > understand what > you are preparing to ask vendors to do, and whether operators are > interested in deploying them. > > > > _______________________________________________ > Sipping mailing list > Sipping@ietf.org > http://www.ietf.org/mailman/listinfo/sipping > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jun 5 11:15:45 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23170 for ; Tue, 5 Jun 2001 11:15:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CB82644353; Tue, 5 Jun 2001 11:16:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by lists.bell-labs.com (Postfix) with ESMTP id CCE0B444A1 for ; Fri, 1 Jun 2001 04:39:42 -0400 (EDT) Received: from imp1-2.free.fr (imp1-2.free.fr [213.228.0.151]) by postfix1-2.free.fr (Postfix) with ESMTP id 1B2F51029D8; Fri, 1 Jun 2001 10:39:37 +0200 (CEST) Received: (from www-data@localhost) by imp1-2.free.fr (8.11.2/8.11.2/Debian 8.11.2-1) id f518daP18958; Fri, 1 Jun 2001 10:39:36 +0200 To: iptel@lists.bell-labs.com Message-ID: <991384776.3b1754c86bf74@imp.free.fr> From: patrick.mourot@online.fr MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.3 X-Originating-IP: 212.208.74.5 Subject: [IPTEL] lightweight TRIP protocol for gateway Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 01 Jun 2001 10:39:36 +0200 (MEST) Content-Transfer-Encoding: 8bit Sir, I would like to know the status of a "lightweight TRIP protocol for gateway". Any pointers ?? Regards, Patrick _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jun 5 11:16:50 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23203 for ; Tue, 5 Jun 2001 11:16:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4FF704439E; Tue, 5 Jun 2001 11:16:07 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by lists.bell-labs.com (Postfix) with ESMTP id 248A044336 for ; Fri, 1 Jun 2001 11:26:24 -0400 (EDT) Received: from imp1-2.free.fr (imp1-2.free.fr [213.228.0.151]) by postfix1-2.free.fr (Postfix) with ESMTP id 9B1D810294A for ; Fri, 1 Jun 2001 17:26:18 +0200 (CEST) Received: (from www-data@localhost) by imp1-2.free.fr (8.11.2/8.11.2/Debian 8.11.2-1) id f51FQIQ19416 for iptel@lists.bell-labs.com; Fri, 1 Jun 2001 17:26:18 +0200 To: iptel@lists.bell-labs.com Message-ID: <991409178.3b17b41a4c575@imp.free.fr> From: patrick.mourot@free.fr MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.3 X-Originating-IP: 212.208.74.5 Subject: [IPTEL] lightweight TRIP protocol for gateway Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 01 Jun 2001 17:26:18 +0200 (MEST) Content-Transfer-Encoding: 8bit Sir, Let me try again to see if it appears in the list: I would like to know the status of a "lightweight TRIP protocol for gateway". Any pointers ?? TIA Regards, Patrick _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jun 5 11:19:25 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23271 for ; Tue, 5 Jun 2001 11:19:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2EC20443AE; Tue, 5 Jun 2001 11:16:13 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by lists.bell-labs.com (Postfix) with ESMTP id 5EF1C44394; Fri, 1 Jun 2001 20:33:44 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01068; Fri, 1 Jun 2001 17:32:34 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28416 for corey@hearme.com; Fri, 1 Jun 2001 17:31:45 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id GAA09027 for ; Thu, 31 May 2001 06:17:31 -0700 (PDT) Received: from optimus.ietf.org ([132.151.1.19]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id GAA12911 for ; Thu, 31 May 2001 06:17:29 -0700 (PDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06115; Thu, 31 May 2001 09:16:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00835 for ; Wed, 30 May 2001 19:39:29 -0400 (EDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27486; Wed, 30 May 2001 19:39:09 -0400 (EDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f4UNdHZ03453; Wed, 30 May 2001 16:39:17 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id XAA13198; Wed, 30 May 2001 23:39:17 GMT Message-Id: <200105302339.XAA13198@gra.isi.edu> To: gratta@lucent.com, sob@harvard.edu, mankin@ISI.EDU, rrroy@att.com Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM X-Sun-Charset: US-ASCII X-Mailman-Version: 1.0 Precedence: bulk X-BeenThere: sipping@ietf.org Content-Type: text Subject: [IPTEL] [Sipping] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 30 May 2001 23:39:17 GMT *> From owner-issll@mercury.lcs.mit.edu Wed May 30 14:59:58 2001 *> From: "Roy, Radhika R, ALCTA" *> To: gratta@lucent.com, sob@harvard.edu, mankin@ISI.EDU *> Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, *> megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, *> Yukio Hiramatsu *> , rbuhrke@lucent.com, *> tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM *> Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E *> ND-TO-END QOS SERVICE CONTROL *> Date: Wed, 30 May 2001 17:21:14 -0400 *> MIME-Version: 1.0 *> *> Hi, Everyone: *> *> Question Q.F/16 of ITU-T SG16 is fully dedicated for developing standards *> for "End-to-End QOS for Multimedia Applications". Contributions are also *> being under discussion in the ITU-T SG16 Brazil May 28 - June 8, 2001 *> meeting. This is very confusing. "End-to-End QOS for Multimedia Applications" is an really important topic, but this topic must be a superset of "End-to-End QOS signaling". There are much harder problems than signaling in providing E2E QoS. Can you explain how signaling relates to the title of this working party? Thanks, Bob Braden *> *> Applications like H.323, SIP, H.324, H.310, and others will also be able to *> use this Q.F/16's QOS signaling protocol. MEGACO/H.248 and BICC will also be *> able to use this when specs are fully developed and, TIPHON's QOS mechanisms *> can also be used as one of the mechanisms for implementations. _______________________________________________ Sipping mailing list Sipping@ietf.org http://www.ietf.org/mailman/listinfo/sipping _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jun 5 11:22:43 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23331 for ; Tue, 5 Jun 2001 11:22:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DB0CC443B9; Tue, 5 Jun 2001 11:16:17 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by lists.bell-labs.com (Postfix) with ESMTP id BBF5044336; Fri, 1 Jun 2001 20:36:34 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01110; Fri, 1 Jun 2001 17:34:44 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28443 for corey@hearme.com; Fri, 1 Jun 2001 17:33:23 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id GAA09035 for ; Thu, 31 May 2001 06:17:37 -0700 (PDT) Received: from optimus.ietf.org ([132.151.1.19]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id GAA12919 for ; Thu, 31 May 2001 06:17:35 -0700 (PDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06076; Thu, 31 May 2001 09:16:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28632 for ; Wed, 30 May 2001 18:31:19 -0400 (EDT) Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26407; Wed, 30 May 2001 18:30:53 -0400 (EDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4UMUBU11655; Wed, 30 May 2001 15:30:11 -0700 (PDT) Message-Id: <5.1.0.14.2.20010530152432.043b8ec0@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: gratta@lucent.com From: Fred Baker Cc: sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, John C Klensin , chair@ietf.org In-Reply-To: <200105302022.QAA03855@hotair.hobl.lucent.com> Mime-Version: 1.0 X-Mailman-Version: 1.0 Precedence: bulk X-BeenThere: sipping@ietf.org Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [IPTEL] [Sipping] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 30 May 2001 15:30:00 -0700 Greg: The URLs in this note were all sent with what the ETSI machine considered to be 'malformed syntax'. Could you resend the correct URLs? Fred _______________________________________________ Sipping mailing list Sipping@ietf.org http://www.ietf.org/mailman/listinfo/sipping _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jun 5 11:25:15 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23368 for ; Tue, 5 Jun 2001 11:25:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D4599443C2; Tue, 5 Jun 2001 11:16:21 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by lists.bell-labs.com (Postfix) with ESMTP id 5873F44336; Fri, 1 Jun 2001 20:42:22 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01264; Fri, 1 Jun 2001 17:40:52 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28567 for corey@hearme.com; Fri, 1 Jun 2001 17:40:03 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id HAA09977 for ; Thu, 31 May 2001 07:44:31 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id HAA14130 for ; Thu, 31 May 2001 07:44:30 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CA5C044440; Thu, 31 May 2001 10:29:33 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by lists.bell-labs.com (Postfix) with ESMTP id B9C0B44336; Wed, 30 May 2001 19:39:31 -0400 (EDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f4UNdHZ03453; Wed, 30 May 2001 16:39:17 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id XAA13198; Wed, 30 May 2001 23:39:17 GMT Message-Id: <200105302339.XAA13198@gra.isi.edu> To: gratta@lucent.com, sob@harvard.edu, mankin@ISI.EDU, rrroy@att.com Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM X-Sun-Charset: US-ASCII X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk Content-Type: text Subject: [IPTEL] [SIP] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 30 May 2001 23:39:17 GMT *> From owner-issll@mercury.lcs.mit.edu Wed May 30 14:59:58 2001 *> From: "Roy, Radhika R, ALCTA" *> To: gratta@lucent.com, sob@harvard.edu, mankin@ISI.EDU *> Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, *> megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, *> Yukio Hiramatsu *> , rbuhrke@lucent.com, *> tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM *> Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E *> ND-TO-END QOS SERVICE CONTROL *> Date: Wed, 30 May 2001 17:21:14 -0400 *> MIME-Version: 1.0 *> *> Hi, Everyone: *> *> Question Q.F/16 of ITU-T SG16 is fully dedicated for developing standards *> for "End-to-End QOS for Multimedia Applications". Contributions are also *> being under discussion in the ITU-T SG16 Brazil May 28 - June 8, 2001 *> meeting. This is very confusing. "End-to-End QOS for Multimedia Applications" is an really important topic, but this topic must be a superset of "End-to-End QOS signaling". There are much harder problems than signaling in providing E2E QoS. Can you explain how signaling relates to the title of this working party? Thanks, Bob Braden *> *> Applications like H.323, SIP, H.324, H.310, and others will also be able to *> use this Q.F/16's QOS signaling protocol. MEGACO/H.248 and BICC will also be *> able to use this when specs are fully developed and, TIPHON's QOS mechanisms *> can also be used as one of the mechanisms for implementations. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jun 5 11:28:49 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23429 for ; Tue, 5 Jun 2001 11:28:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 51E8F443D2; Tue, 5 Jun 2001 11:16:27 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by lists.bell-labs.com (Postfix) with ESMTP id D51DB44336; Fri, 1 Jun 2001 20:46:38 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01400; Fri, 1 Jun 2001 17:45:02 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28652 for corey@hearme.com; Fri, 1 Jun 2001 17:44:03 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id IAA10535 for ; Thu, 31 May 2001 08:19:41 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id IAA14880 for ; Thu, 31 May 2001 08:19:40 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5E55A44437; Thu, 31 May 2001 10:29:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id 6CA7044336; Wed, 30 May 2001 18:31:17 -0400 (EDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4UMUBU11655; Wed, 30 May 2001 15:30:11 -0700 (PDT) Message-Id: <5.1.0.14.2.20010530152432.043b8ec0@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: gratta@lucent.com From: Fred Baker Cc: sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, John C Klensin , chair@ietf.org In-Reply-To: <200105302022.QAA03855@hotair.hobl.lucent.com> Mime-Version: 1.0 X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [IPTEL] [SIP] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 30 May 2001 15:30:00 -0700 Greg: The URLs in this note were all sent with what the ETSI machine considered to be 'malformed syntax'. Could you resend the correct URLs? Fred _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jun 5 11:31:55 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23510 for ; Tue, 5 Jun 2001 11:31:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C45CD443DA; Tue, 5 Jun 2001 11:16:31 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by lists.bell-labs.com (Postfix) with ESMTP id 288AF44336; Fri, 1 Jun 2001 20:50:24 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01477; Fri, 1 Jun 2001 17:49:04 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28692 for corey@hearme.com; Fri, 1 Jun 2001 17:48:05 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12283 for ; Thu, 31 May 2001 10:20:10 -0700 (PDT) Received: from optimus.ietf.org ([132.151.1.19]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA16829 for ; Thu, 31 May 2001 10:20:09 -0700 (PDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24344; Thu, 31 May 2001 13:19:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24030 for ; Thu, 31 May 2001 13:12:24 -0400 (EDT) Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02436; Thu, 31 May 2001 13:12:02 -0400 (EDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4VHBBU27133; Thu, 31 May 2001 10:11:12 -0700 (PDT) Message-Id: <5.1.0.14.2.20010531095817.04c50ea8@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: "Roy, Radhika R, ALCTA" From: Fred Baker Cc: Bob Braden , gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM In-Reply-To: Mime-Version: 1.0 X-Mailman-Version: 1.0 Precedence: bulk X-BeenThere: sipping@ietf.org Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [IPTEL] [Sipping] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 31 May 2001 10:09:10 -0700 At 06:08 AM 5/31/2001, Roy, Radhika R, ALCTA wrote: >All applications (e.g., H.323, SIP) uses signaling messages >among its functional entities (e.g., terminal, agents, >gatekeepers, proxies, gateways) for communications. I'm not sure we're on the same planet. Please help me out here. I can think of a few applications that have agents, gatekeepers, proxies, and gateways, mostly resulting from the imposition of firewalls or authentication systems, or from legacy applications like imitating the telephone system in a data network. The only one that *requires* any kind of gateway, to my knowledge, is H.323 teleconferencing, which represents a paltry fraction of traffic according to most current measurements. Anything else (75% of Internet traffic is http or FTP, most of the rest is mail, on private LANs applications like NFS are pretty common, and even SIP can be done without a gateway between consenting systems) could be hooked up in separate systems on a LAN and made to work without any such signalling at all. Could you be more specific on what QoS signalling is required by the world wide web, mail, FTP, common ERP applications like ERP and PeopleSoft, calendaring, and so on? If not, could you be more specific about what "all" applications you have in mind? And could you be more specific about what issues this proposal is addressing that have not already been addressed in de facto standards and deployed in operational systems? It would be very nice to understand what you are preparing to ask vendors to do, and whether operators are interested in deploying them. _______________________________________________ Sipping mailing list Sipping@ietf.org http://www.ietf.org/mailman/listinfo/sipping _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jun 5 11:35:13 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23592 for ; Tue, 5 Jun 2001 11:35:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 00F12443DF; Tue, 5 Jun 2001 11:16:36 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by lists.bell-labs.com (Postfix) with ESMTP id C3B3444336; Fri, 1 Jun 2001 20:51:59 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01527; Fri, 1 Jun 2001 17:50:42 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28732 for corey@hearme.com; Fri, 1 Jun 2001 17:50:03 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12742 for ; Thu, 31 May 2001 10:40:20 -0700 (PDT) Received: from optimus.ietf.org ([132.151.1.19]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA16681 for ; Thu, 31 May 2001 10:12:15 -0700 (PDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23823; Thu, 31 May 2001 13:08:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18138 for ; Thu, 31 May 2001 11:14:09 -0400 (EDT) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28182; Thu, 31 May 2001 11:13:46 -0400 (EDT) Received: from phaestos.ee.surrey.ac.uk ([131.227.88.14] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 155U91-00045U-00; Thu, 31 May 2001 16:13:51 +0100 From: Lloyd Wood X-Sender: eep1lw@phaestos.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Fred Baker Cc: gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, John C Klensin , chair@ietf.org In-Reply-To: <5.1.0.14.2.20010530152432.043b8ec0@mira-sjcm-2.cisco.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 X-Scanner: exiscan *155U91-00045U-00*ZWgRfZ3Wo52* http://duncanthrax.net/exiscan/ X-Mailman-Version: 1.0 Precedence: bulk X-BeenThere: sipping@ietf.org Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [IPTEL] [Sipping] Re: [Diffserv] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 31 May 2001 16:13:43 +0100 (BST) On Wed, 30 May 2001, Fred Baker wrote: > Greg: > > The URLs in this note were all sent with what the ETSI machine considered > to be 'malformed syntax'. Could you resend the correct URLs? Just put all the parts together, removing unencoded spaces; the reason for the breaks after the hyphens seems obvious enough, but I'm at a loss to explain others. Here we go: http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05009/V1.1.1/ts_101329-2v111p.doc http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05003/DTS05003v096.zip http://webapp.etsi.org/tbhomepage/TBDetails.asp?TB_ID=291&TB_NAME=TIPHON http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/ARCHIVES/2000/05-200012-Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt So http://docbox.etsi.org/ is passworded but docs can be retrieved by advertised public direct url? Bizarre. L. PGP _______________________________________________ Sipping mailing list Sipping@ietf.org http://www.ietf.org/mailman/listinfo/sipping _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jun 5 11:39:32 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23688 for ; Tue, 5 Jun 2001 11:39:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3C0F8443E7; Tue, 5 Jun 2001 11:16:40 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by lists.bell-labs.com (Postfix) with ESMTP id D5FD34442C; Fri, 1 Jun 2001 20:53:21 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01578; Fri, 1 Jun 2001 17:51:36 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28745 for corey@hearme.com; Fri, 1 Jun 2001 17:50:42 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12744 for ; Thu, 31 May 2001 10:40:27 -0700 (PDT) Received: from optimus.ietf.org ([132.151.1.19]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA16683 for ; Thu, 31 May 2001 10:12:15 -0700 (PDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23907; Thu, 31 May 2001 13:08:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21446 for ; Thu, 31 May 2001 12:11:54 -0400 (EDT) Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00447; Thu, 31 May 2001 12:11:31 -0400 (EDT) Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 31 May 2001 17:11:33 +0100 To: Lloyd Wood Cc: Fred Baker , gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, John C Klensin , chair@ietf.org, J.Crowcroft@cs.ucl.ac.uk In-reply-to: Your message of "Thu, 31 May 2001 16:13:43 BST." Message-ID: <922.991325489@cs.ucl.ac.uk> From: Jon Crowcroft X-Mailman-Version: 1.0 Precedence: bulk X-BeenThere: sipping@ietf.org Content-Type: text Subject: [IPTEL] [Sipping] Re: [Diffserv] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 31 May 2001 17:11:29 +0100 so the talk seems to be dated dec 2001, and makes me wonder if the tiphon folks have achieved a breakthru in QOS with e2e delays better than 0ms..... meanwhile, i stuck html versions of the files below at ftp://cs.ucl.ac.uk/darpa/tiphon/ (prob. doesnt help non windoze users since the html is generated by office 2000 apps so unless you have the unix internet explorer, too bad) In message , Lloyd Wood typed: >>On Wed, 30 May 2001, Fred Baker wrote: >> >>> Greg: >>> >>> The URLs in this note were all sent with what the ETSI machine considered >>> to be 'malformed syntax'. Could you resend the correct URLs? >> >>Just put all the parts together, removing unencoded >>spaces; the reason for the breaks after the hyphens seems >>obvious enough, but I'm at a loss to explain others. Here we go: >> >>http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05009/V1.1.1/ts_101329-2v111p.doc >> >>http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05003/DTS05003v096.zip >> >>http://webapp.etsi.org/tbhomepage/TBDetails.asp?TB_ID=291&TB_NAME=TIPHON >> >>http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/ARCHIVES/2000/05-200012-Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt >> >>So http://docbox.etsi.org/ is passworded but docs can be retrieved by >>advertised public direct url? Bizarre. >> >>L. >> >>PGP >> >> >> >> >> >> >> cheers jon _______________________________________________ Sipping mailing list Sipping@ietf.org http://www.ietf.org/mailman/listinfo/sipping _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jun 5 11:43:57 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23831 for ; Tue, 5 Jun 2001 11:43:57 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 413DB443F1; Tue, 5 Jun 2001 11:16:44 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by lists.bell-labs.com (Postfix) with ESMTP id 2C96544412; Fri, 1 Jun 2001 20:53:52 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01598; Fri, 1 Jun 2001 17:52:26 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28774 for corey@hearme.com; Fri, 1 Jun 2001 17:51:37 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12873 for ; Thu, 31 May 2001 10:44:35 -0700 (PDT) Received: from optimus.ietf.org ([132.151.1.19]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA16691 for ; Thu, 31 May 2001 10:12:29 -0700 (PDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23860; Thu, 31 May 2001 13:08:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21135 for ; Thu, 31 May 2001 12:06:43 -0400 (EDT) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00226; Thu, 31 May 2001 12:06:20 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id JAA34990; Thu, 31 May 2001 09:04:55 -0700 Received: from hursley.ibm.com ([9.29.3.174]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id JAA20120; Thu, 31 May 2001 09:04:54 -0700 Message-ID: <3B166AFC.9DF4CD05@hursley.ibm.com> From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: gratta@lucent.com Cc: sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch References: <200105302022.QAA03855@hotair.hobl.lucent.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA21136 X-Mailman-Version: 1.0 Precedence: bulk X-BeenThere: sipping@ietf.org Content-Type: text/plain; charset=iso-8859-1 Subject: [IPTEL] [Sipping] Re: [Diffserv] PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 31 May 2001 11:02:04 -0500 Content-Transfer-Encoding: 8bit Folks, This is *not* a discussion item for the diffserv WG mailing list. This WG is not chartered to discuss signalling issues. Whether the ITU should work on this and if so how it should collaborate with the IETF should be discussed at liaison level, not on a list with a few hundred people. So please everybody drop this discussion on the diffserv list and continue elswhere. Regards Brian Carpenter diffserv co-chair Greg Ratta wrote: > > This message was agreed to at ITU-T Study Group 11 meeting (Geneva, May 2001) and is being transmitted on behalf of Yukio Hiramatsu, Chairman of ITU-T SG 11. For further technical clarification, contact the Rapporteur for Q9/11 (Rolfe Buhrke, Tel: + 1 630 713 7022, { HYPERLINK mailto:rburke@lucent.com }rbuhrke@lucent.com) > > FULL TITLE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL AND SIGNALLING PROTOCOL DEVELOPMENT BASED ON IP TRANSFER CAPABILITIES AND IP QOS CLASSES > > General > > Within ITU-T SG11 work has started on requirements for a generic protocol mechanism for end-to-end QoS service control. It was agreed within SG11 to proceed with this work utilising deliverables of ETSI TIPHON on end- to-end QoS service control as base material. It is the opinion of SG11 that this generic protocol mechanism for BICC intends to apply also to other protocols like SIP/SDP and H.323 next to generic extensions to the H.248/MEGACO protocol. > > It was noted that also QoS related work is in progress in IETF. Please find attached an initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. Please note the rationale for this activity and the framework for end-to-end QoS service control and network QoS control. The framework illustrates the field of application of the QoS handling at different levels and the different protocols involved. > > Proposals on end-to-end QoS service control > > It is proposed to start a joint activity with IETF on a generic protocol mechanism for end- to-end QoS service control. This refers to the potential work in IETF on the following topics: > > - Identification of the signalling requirements based on the ETSI TIPHON defined speech QoS service classes for VoIP and the signalling and control of end-to-end QoS for VoIP. The attachment provides the initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. > > - The definition of a generic call/bearer control mechanism in H.225/H.245, SIP/SDP and BICC CS3 for end-to-end QoS service control in the application plane. > > - The definition of generic extensions to H.248/MEGACO for end-to-end QoS service control between the application plane and the transport plane. > > - The translation between the generic protocol QoS information elements in H.248/MEGACO and the technology specific QoS parameters and QoS mechanisms in IP, ATM, MPLS, etc. > > Proposals on IP QoS classes and IP Transfer Capabilities > > ITU-T SG11 would like to inform IETF that it is investigating signalling requirements for protocol development based on the IP Transfer Capabilities and IP QoS classes, as being defined by ITU-T SG13 in Y.1541 and Y.iptc. The plan is to build upon signalling approaches developed by IETF. We would like to stress that the work on IP QoS classes and IP Transfer Capabilities by ITU-T SG13 is co- ordinated with IETF. > > ATTACHMENT Initial draft text of the BICC CS3 signalling requirements for end-to-end QoS service control. > > The ETSI specifications referenced as base material are available at the following URLs: > > ETSI TS 301 329 part 2, http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05009/V1.1.1/ts_10 1329-2v111p.doc > > - ETSI TS 301 329 part 3 see http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05003/DTS05003v096.zi p > > Further information about the ETSI TIPHON project is available at the following URL: > > - http://webapp.etsi.org/tbhomepage/TBDetails.as p?TB_ID=291&TB_NAME=TIPHON > __________________ > > BICC CS3 signalling requirements for end-to- end QoS service control > > EDITORS’ NOTE: This requirements text for end-to-end QoS service control is a first draft text and requires extensive updating based on liaison activities with other groups > > 1 Rationale > > The rationale of the BICC CS3 requirements for end-to-end service control is based on the analysis made by ETSI TIPHON (see the presentation available at the URL: http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/ARCHIVES/2000/05- 200012- Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt ). It shows the inter-relationship between the different QoS factors that finally determine > the perceived speech quality by the end- users. This perceived speech quality does not only depend on network quality of service (network packet loss, network jitter and network delay) but on the terminal implementation (jitter buffers and codec performance) as well. > > A second rationale is that end-to-end QoS requirements can be regarded as end-to-end quality budgets related to the media flows. To achieve the required end-to-end QoS these quality budgets must be allocated between the domains, including the user equipment (see Figure 7 in ETSI TS 301 329 part 3). The Transport QoS Parameters specify the QoS budgets for each Transport Domain. It is assumed that the performance of each domain is statistically independent from any other. > > Therefore end-to-end QoS service control at the call control level (i.e. application plane) is required based on generic signalling procedures in protocols like BICC, SIP/SDP, H.323 and H.248/MEGACO for end-to- end QoS service control. > > 2 Framework for end-to-end QoS service control and network QoS control. > > A framework for QoS control may be considered at different levels: call control (BICC, SIP/SDP, H.323), vertical control (H.248/MEGACO, CBC), bearer control (IP BCP) and bearer (DiffServ, IntServ/RSVP or MPLS/LDP). > > 1) Call-control > > a) End-to-end QoS service control is negotiated/communicated end-to-end at the call control level. ETSI TIPHON has defined a set of speech QoS classes, and signalling requirements and flows for this purpose. > > The idea is that call control protocols are enhanced with a generic end-to-end QoS service control mechanism to negotiate these speech QoS classes and associated parameters (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size). > > Such a generic end-to-end QoS service control mechanism should be defined independent of the underlying technology (ATM or IP) and operate across network domains and including terminal characteristics to negotiate/communicate the requested listener speech quality that will be perceived by the end-users (i.e. "mouth-to-ear"). > > b) BICC (Q.190x) is one of the call control protocols that may be enhanced this way. Similar enhancements may be applicable to other call-control protocols like SIP/SDP and H.323. > > 2) Vertical control > > a) QoS service control is also negotiated/communicated at the vertical control level. The ETSI TIPHON defined signalling requirements and flows include the vertical interface. The idea is that vertical control protocols are enhanced to negotiate/communicate the QoS settings (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size) in the bearer core network based on generic H.248/MEGACO extensions. > > These QoS settings should be defined independent of the underlying technology (ATM or IP) of the bearer core network. > > b) CBC (Q.1950) is one of the vertical control protocols that may be enhanced this way. > > 3) Bearer control > > a) Network QoS is negotiated/communicated at the bearer control level. ATM signalling does already intrinsically support network QoS. SG13 has recently defined IP QoS classes and IP Transfer Capabilities. > > The idea is that bearer control protocols for IP are enhanced with a mechanism to negotiate the network QoS by using IP QoS classes and IP Transfer Capabilities. > > b) IP BCP (Q.1970) is an IP bearer control protocol that may be enhanced this way. > > 4) Bearer > > a) Network QoS is negotiated/communicated at the bearer level, i.e. as part of the protocols associated with the bearers in the core network. The idea is that IP QoS classes and IP Transfer Capabilties, as defined by SG13, are used to differentiate between different types of IP traffic. > > b) IP QoS classes and IP Transfer Capabilities may be used to enhance existing IP mechanisms like DiffServ, IntServ/RSVP and MPLS/LDP. > > 3 QoS information flows applicable to BICC > > A general model is considered for QoS information flows with BICC when making a translation of the relevant parts in Figure 8 in ETSI TS 301 329 part 3. > > Section 4 details the Q.BICC related QoS primitives and parameters based on the QoS primitives and parameters in the ETSI deliverable. Similarly, section 5 provides the Q.CBC related QoS primitives and parameters. > > 4 Q.BICC related QoS primitives and parameters > > The Q.BICC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. > > 4.1 Q.BICC related QoS primitives > > This information flow (QC2 in ETSI TS 101 329 part 3) communicates the QoS related bearer information between the domains of different service providers. > > Q.BICC QoS request (Qbicc.QoSreq) requests the establishment of a bearer conforming to a particular ETSI TIPHON Class of Service or with defined QoS characteristics. > > NOTE Identical to QoSM request (QC2.QoSMreq) in ETSI TS 101 329 part 3 clause 8.1.1. > > Q.BICC QoS confirm (Qbicc.QoSconf) acknowledges the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. > > NOTE Identical to QoSM confirm (QC2.QoSMconf) in ETSI TS 101 329 part 3 clause 8.1.1. > > Q.BICC QoS reject (Qbicc.QoSrej) rejects the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. > > NOTE Identical to QoSM reject (QC2.QoSMrej) in ETSI TS 101 329 part 3 clause 8.1.1. > > Q.BICC release request (Qbicc.QoSrelreq) requests the release of a bearer. > > NOTE Identical to QoSM release request (QC2.QoSMrelreq) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. > > QoSM release confirm (Qbicc.QoSrelconf) confirms the release of a bearer. > > NOTE Identical to QoSM release confirm (QC2.QoSMrelconf) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. > > 4.2 Q.BICC related QoS parameters > > Table 1 lists the parameters used in the Q.BICC related QoS primitives not yet covered by the Q.BICC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in the Q.1902 series. > > NOTE The contents of Table 1 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.3. > > Table 1: Identification of Q.BICC related parameters for end-to-end QoS service control > Qbicc.QoSreq QoS Service Class Optional > > Codec Type and Packetisation Mandatory > > Transport QoS Parameters Mandatory > > Traffic Descriptor Optional > > Transport Addresses Mandatory > > Application Data Transport Protocol Optional [Default RTP] > > Packet Transport Protocol Optional [Default UDP] > > QoS Mechanism Optional > > Qbicc.QoSconf QoS Service Class Optional > > Codec Type and Packetisation Mandatory > > Transport QoS Parameters Mandatory > > Transport Addresses Mandatory > > Application Data Transport Protocol Optional [Default RTP] > > Packet Transport Protocol Optional [Default UDP] > > Qbicc.QoSrej Reason [TBD] Mandatory > > 5 Q.CBC related QoS primitives and parameters > > The Q.CBC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. > > 5.1 Q.CBC related QoS primitives > > This information flow (QT2 in ETSI TS 101 329 part 3) communicates the QoS related transport flow information between a service domain and an associated transport domain. This information contains the QoS related characteristics required of the transport flows that will carry the media flow and the properties of the media flow. > > Q.CBC QoS request (Qcbc.QoSreq) requests the establishment of a transport flow with defined QoS characteristics across a Transport Domain or the reservation of Transport Domain resource. > > NOTE Identical to TRM QoS request (QT2.TRMQreq) in ETSI TS 101 329 part 3 clause 8.1.3. > > Q.CBC QoS confirm (Qcbc.QoSconf) acknowledges the creation of a requested transport flow or the reservation of Transport Domain resource. > > NOTE Identical to TRM QoS confirm (QT2.TRMQconf) in ETSI TS 101 329 part 3 clause 8.1.3. > > Q.CBC QoS reject (Qcbc.QoSrej) rejects the creation of a requested transport flow or the reservation of Transport Domain resource. > > NOTE Identical to TRM QoS reject (QT2.TRMQrej) in ETSI TS 101 329 part 3 clause 8.1.3. > > Q.CBC QoS release request (Qcbc.QoSrelreq) requests the release of a transport flow. > > NOTE Identical to TRM QoS release request (QT2.TRM QoS relreq) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. > > Q.CBC QoS release confirm (Qcbc.QoSrelconf) confirms the release of a transport flow. > > NOTE Identical to TRM QoS release confirm (QT2.TRM QoS relconf) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. > > Q.CBC QoS performance notification (Qcbc.QoSperfnotif) notifies the Service Domain of the performance of the Transport Domain in meeting the requested QoS levels. This may be a periodic event or an urgent alarm. Note: this primitive is a management primitive and its use is for further study. > > NOTE Identical to TRM QoS performance notification (QT2.TRM QoS perfnotif) in ETSI TS 101 329 part 3 clause 8.1.3. For further study. > > 5.2 Q.CBC related QoS parameters > > Table 2 lists the parameters used in the Q.CBC related QoS primitives not yet covered by the Q.CBC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in Q.1950. > > NOTE The contents of Table 2 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.5. > > Table 2: Identification of Q.CBC related parameters for end-to-end QoS service control > > QT2.TRMQreq Transport QoS Parameters Mandatory > > Traffic Descriptor Mandatory > > Transport Addresses Mandatory > > Packet Transport Protocol Optional [Default UDP] > > QT2.TRMQconf Transport QoS Parameters Mandatory > > Transport Addresses Mandatory > > Packet Transport Protocol Optional [Default UDP] > > QoS Mechanism Optional > > QT2.TRMQrej Reason [TBD] Mandatory > > 6 Parameter contents > > Table 3 specifies the information to be covered by the parameters listed in sections 4.2 and 5.2 based on the QoS parameter groups in ETSI TS 101 329 part 3 clause 8.2.1. > > Table 3: Identification of parameter contents for end-to-end QoS service control > > QoS Service Class Describes the end-to-end ETSI TIPHON Best, High, Medium > class of a bearer or Best Effort > > Transport QoS Specifies the QoS characteristics Maximum Delay > Parameters required of the transport flow > carrying the media flow. Maximum Packet Delay Variation > > Maximum Packet Loss > > Traffic Descriptor Characterises the resource Peak Bit > requirements of an application data > flow (excludes transport flow Maximum Packet Size > resource requirements). > > Parameters specifying the ETSI TIPHON QoS Class as defined in ETSI TS 101 329 Part 2 > > The maximum delay permitted (ms) over either a segment of the transport flow or the remaining part of the transport flow. > > The maximum packet delay variation permitted (ms) over either a segment of the transport flow or the remaining part of the transport flow. > > The maximum packet loss permitted (%) over either a segment of the transport flow or the remaining part of the transport flow. [N.B. This measure assumes randomly distributed packet loss] > Maximum bit rate (bit/s) of the media flow. > > Maximum size of the media packets > > 7 Information flows and signalling procedures for end-to-end QoS service control > > EDITORS’ NOTE The information flows and signalling procedures for end-to-end QoS service control may be considered to follow the same principles as the already existing procedures for end-to-end codec negotiation in BICC CS1 and BICC CS2. Similarly mid-call procedures for end-to-end QoS modification and mid-call QoS modification may be considered because the perceived QoS is highly related to the codec type employed end- to-end as part of the connection. The exact scope and properties of these procedures and protocol message flows needs further discussion. > > Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and protocols > Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org _______________________________________________ Sipping mailing list Sipping@ietf.org http://www.ietf.org/mailman/listinfo/sipping _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jun 5 11:46:50 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23908 for ; Tue, 5 Jun 2001 11:46:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 98FE044404; Tue, 5 Jun 2001 11:16:48 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by lists.bell-labs.com (Postfix) with ESMTP id A06C244336; Fri, 1 Jun 2001 21:01:42 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id SAA01762; Fri, 1 Jun 2001 18:00:15 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28891 for corey@hearme.com; Fri, 1 Jun 2001 17:59:05 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id OAA16321 for ; Thu, 31 May 2001 14:58:11 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id OAA21799 for ; Thu, 31 May 2001 14:58:10 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 538BF44401; Thu, 31 May 2001 17:56:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from prue.eim.surrey.ac.uk (prue.eim.surrey.ac.uk [131.227.76.5]) by lists.bell-labs.com (Postfix) with ESMTP id 16760443FA; Thu, 31 May 2001 11:14:11 -0400 (EDT) Received: from phaestos.ee.surrey.ac.uk ([131.227.88.14] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 155U91-00045U-00; Thu, 31 May 2001 16:13:51 +0100 From: Lloyd Wood X-Sender: eep1lw@phaestos.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Fred Baker Cc: gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, John C Klensin , chair@ietf.org In-Reply-To: <5.1.0.14.2.20010530152432.043b8ec0@mira-sjcm-2.cisco.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 X-Scanner: exiscan *155U91-00045U-00*ZWgRfZ3Wo52* http://duncanthrax.net/exiscan/ X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [IPTEL] [SIP] Re: [Diffserv] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 31 May 2001 16:13:43 +0100 (BST) On Wed, 30 May 2001, Fred Baker wrote: > Greg: > > The URLs in this note were all sent with what the ETSI machine considered > to be 'malformed syntax'. Could you resend the correct URLs? Just put all the parts together, removing unencoded spaces; the reason for the breaks after the hyphens seems obvious enough, but I'm at a loss to explain others. Here we go: http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05009/V1.1.1/ts_101329-2v111p.doc http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05003/DTS05003v096.zip http://webapp.etsi.org/tbhomepage/TBDetails.asp?TB_ID=291&TB_NAME=TIPHON http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/ARCHIVES/2000/05-200012-Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt So http://docbox.etsi.org/ is passworded but docs can be retrieved by advertised public direct url? Bizarre. L. PGP _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jun 5 11:48:49 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23947 for ; Tue, 5 Jun 2001 11:48:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CA8904440C; Tue, 5 Jun 2001 11:16:52 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by lists.bell-labs.com (Postfix) with ESMTP id EA12E4440A; Fri, 1 Jun 2001 21:02:31 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id SAA01796; Fri, 1 Jun 2001 18:01:04 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id SAA28908 for corey@hearme.com; Fri, 1 Jun 2001 18:00:15 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id PAA16432 for ; Thu, 31 May 2001 15:04:51 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id PAA21898 for ; Thu, 31 May 2001 15:04:50 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2B71D44471; Thu, 31 May 2001 17:56:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by lists.bell-labs.com (Postfix) with ESMTP id 47E5B443C5; Thu, 31 May 2001 12:06:44 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id JAA34990; Thu, 31 May 2001 09:04:55 -0700 Received: from hursley.ibm.com ([9.29.3.174]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id JAA20120; Thu, 31 May 2001 09:04:54 -0700 Message-ID: <3B166AFC.9DF4CD05@hursley.ibm.com> From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: gratta@lucent.com Cc: sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch References: <200105302022.QAA03855@hotair.hobl.lucent.com> X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nodserv.hearme.com id PAA16432 Content-Type: text/plain; charset=iso-8859-1 Subject: [IPTEL] [SIP] Re: [Diffserv] PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 31 May 2001 11:02:04 -0500 Content-Transfer-Encoding: 8bit Folks, This is *not* a discussion item for the diffserv WG mailing list. This WG is not chartered to discuss signalling issues. Whether the ITU should work on this and if so how it should collaborate with the IETF should be discussed at liaison level, not on a list with a few hundred people. So please everybody drop this discussion on the diffserv list and continue elswhere. Regards Brian Carpenter diffserv co-chair Greg Ratta wrote: > > This message was agreed to at ITU-T Study Group 11 meeting (Geneva, May 2001) and is being transmitted on behalf of Yukio Hiramatsu, Chairman of ITU-T SG 11. For further technical clarification, contact the Rapporteur for Q9/11 (Rolfe Buhrke, Tel: + 1 630 713 7022, { HYPERLINK mailto:rburke@lucent.com }rbuhrke@lucent.com) > > FULL TITLE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL AND SIGNALLING PROTOCOL DEVELOPMENT BASED ON IP TRANSFER CAPABILITIES AND IP QOS CLASSES > > General > > Within ITU-T SG11 work has started on requirements for a generic protocol mechanism for end-to-end QoS service control. It was agreed within SG11 to proceed with this work utilising deliverables of ETSI TIPHON on end- to-end QoS service control as base material. It is the opinion of SG11 that this generic protocol mechanism for BICC intends to apply also to other protocols like SIP/SDP and H.323 next to generic extensions to the H.248/MEGACO protocol. > > It was noted that also QoS related work is in progress in IETF. Please find attached an initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. Please note the rationale for this activity and the framework for end-to-end QoS service control and network QoS control. The framework illustrates the field of application of the QoS handling at different levels and the different protocols involved. > > Proposals on end-to-end QoS service control > > It is proposed to start a joint activity with IETF on a generic protocol mechanism for end- to-end QoS service control. This refers to the potential work in IETF on the following topics: > > - Identification of the signalling requirements based on the ETSI TIPHON defined speech QoS service classes for VoIP and the signalling and control of end-to-end QoS for VoIP. The attachment provides the initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. > > - The definition of a generic call/bearer control mechanism in H.225/H.245, SIP/SDP and BICC CS3 for end-to-end QoS service control in the application plane. > > - The definition of generic extensions to H.248/MEGACO for end-to-end QoS service control between the application plane and the transport plane. > > - The translation between the generic protocol QoS information elements in H.248/MEGACO and the technology specific QoS parameters and QoS mechanisms in IP, ATM, MPLS, etc. > > Proposals on IP QoS classes and IP Transfer Capabilities > > ITU-T SG11 would like to inform IETF that it is investigating signalling requirements for protocol development based on the IP Transfer Capabilities and IP QoS classes, as being defined by ITU-T SG13 in Y.1541 and Y.iptc. The plan is to build upon signalling approaches developed by IETF. We would like to stress that the work on IP QoS classes and IP Transfer Capabilities by ITU-T SG13 is co- ordinated with IETF. > > ATTACHMENT Initial draft text of the BICC CS3 signalling requirements for end-to-end QoS service control. > > The ETSI specifications referenced as base material are available at the following URLs: > > ETSI TS 301 329 part 2, http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05009/V1.1.1/ts_10 1329-2v111p.doc > > - ETSI TS 301 329 part 3 see http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05003/DTS05003v096.zi p > > Further information about the ETSI TIPHON project is available at the following URL: > > - http://webapp.etsi.org/tbhomepage/TBDetails.as p?TB_ID=291&TB_NAME=TIPHON > __________________ > > BICC CS3 signalling requirements for end-to- end QoS service control > > EDITORS’ NOTE: This requirements text for end-to-end QoS service control is a first draft text and requires extensive updating based on liaison activities with other groups > > 1 Rationale > > The rationale of the BICC CS3 requirements for end-to-end service control is based on the analysis made by ETSI TIPHON (see the presentation available at the URL: http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/ARCHIVES/2000/05- 200012- Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt ). It shows the inter-relationship between the different QoS factors that finally determine > the perceived speech quality by the end- users. This perceived speech quality does not only depend on network quality of service (network packet loss, network jitter and network delay) but on the terminal implementation (jitter buffers and codec performance) as well. > > A second rationale is that end-to-end QoS requirements can be regarded as end-to-end quality budgets related to the media flows. To achieve the required end-to-end QoS these quality budgets must be allocated between the domains, including the user equipment (see Figure 7 in ETSI TS 301 329 part 3). The Transport QoS Parameters specify the QoS budgets for each Transport Domain. It is assumed that the performance of each domain is statistically independent from any other. > > Therefore end-to-end QoS service control at the call control level (i.e. application plane) is required based on generic signalling procedures in protocols like BICC, SIP/SDP, H.323 and H.248/MEGACO for end-to- end QoS service control. > > 2 Framework for end-to-end QoS service control and network QoS control. > > A framework for QoS control may be considered at different levels: call control (BICC, SIP/SDP, H.323), vertical control (H.248/MEGACO, CBC), bearer control (IP BCP) and bearer (DiffServ, IntServ/RSVP or MPLS/LDP). > > 1) Call-control > > a) End-to-end QoS service control is negotiated/communicated end-to-end at the call control level. ETSI TIPHON has defined a set of speech QoS classes, and signalling requirements and flows for this purpose. > > The idea is that call control protocols are enhanced with a generic end-to-end QoS service control mechanism to negotiate these speech QoS classes and associated parameters (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size). > > Such a generic end-to-end QoS service control mechanism should be defined independent of the underlying technology (ATM or IP) and operate across network domains and including terminal characteristics to negotiate/communicate the requested listener speech quality that will be perceived by the end-users (i.e. "mouth-to-ear"). > > b) BICC (Q.190x) is one of the call control protocols that may be enhanced this way. Similar enhancements may be applicable to other call-control protocols like SIP/SDP and H.323. > > 2) Vertical control > > a) QoS service control is also negotiated/communicated at the vertical control level. The ETSI TIPHON defined signalling requirements and flows include the vertical interface. The idea is that vertical control protocols are enhanced to negotiate/communicate the QoS settings (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size) in the bearer core network based on generic H.248/MEGACO extensions. > > These QoS settings should be defined independent of the underlying technology (ATM or IP) of the bearer core network. > > b) CBC (Q.1950) is one of the vertical control protocols that may be enhanced this way. > > 3) Bearer control > > a) Network QoS is negotiated/communicated at the bearer control level. ATM signalling does already intrinsically support network QoS. SG13 has recently defined IP QoS classes and IP Transfer Capabilities. > > The idea is that bearer control protocols for IP are enhanced with a mechanism to negotiate the network QoS by using IP QoS classes and IP Transfer Capabilities. > > b) IP BCP (Q.1970) is an IP bearer control protocol that may be enhanced this way. > > 4) Bearer > > a) Network QoS is negotiated/communicated at the bearer level, i.e. as part of the protocols associated with the bearers in the core network. The idea is that IP QoS classes and IP Transfer Capabilties, as defined by SG13, are used to differentiate between different types of IP traffic. > > b) IP QoS classes and IP Transfer Capabilities may be used to enhance existing IP mechanisms like DiffServ, IntServ/RSVP and MPLS/LDP. > > 3 QoS information flows applicable to BICC > > A general model is considered for QoS information flows with BICC when making a translation of the relevant parts in Figure 8 in ETSI TS 301 329 part 3. > > Section 4 details the Q.BICC related QoS primitives and parameters based on the QoS primitives and parameters in the ETSI deliverable. Similarly, section 5 provides the Q.CBC related QoS primitives and parameters. > > 4 Q.BICC related QoS primitives and parameters > > The Q.BICC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. > > 4.1 Q.BICC related QoS primitives > > This information flow (QC2 in ETSI TS 101 329 part 3) communicates the QoS related bearer information between the domains of different service providers. > > Q.BICC QoS request (Qbicc.QoSreq) requests the establishment of a bearer conforming to a particular ETSI TIPHON Class of Service or with defined QoS characteristics. > > NOTE Identical to QoSM request (QC2.QoSMreq) in ETSI TS 101 329 part 3 clause 8.1.1. > > Q.BICC QoS confirm (Qbicc.QoSconf) acknowledges the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. > > NOTE Identical to QoSM confirm (QC2.QoSMconf) in ETSI TS 101 329 part 3 clause 8.1.1. > > Q.BICC QoS reject (Qbicc.QoSrej) rejects the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. > > NOTE Identical to QoSM reject (QC2.QoSMrej) in ETSI TS 101 329 part 3 clause 8.1.1. > > Q.BICC release request (Qbicc.QoSrelreq) requests the release of a bearer. > > NOTE Identical to QoSM release request (QC2.QoSMrelreq) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. > > QoSM release confirm (Qbicc.QoSrelconf) confirms the release of a bearer. > > NOTE Identical to QoSM release confirm (QC2.QoSMrelconf) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. > > 4.2 Q.BICC related QoS parameters > > Table 1 lists the parameters used in the Q.BICC related QoS primitives not yet covered by the Q.BICC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in the Q.1902 series. > > NOTE The contents of Table 1 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.3. > > Table 1: Identification of Q.BICC related parameters for end-to-end QoS service control > Qbicc.QoSreq QoS Service Class Optional > > Codec Type and Packetisation Mandatory > > Transport QoS Parameters Mandatory > > Traffic Descriptor Optional > > Transport Addresses Mandatory > > Application Data Transport Protocol Optional [Default RTP] > > Packet Transport Protocol Optional [Default UDP] > > QoS Mechanism Optional > > Qbicc.QoSconf QoS Service Class Optional > > Codec Type and Packetisation Mandatory > > Transport QoS Parameters Mandatory > > Transport Addresses Mandatory > > Application Data Transport Protocol Optional [Default RTP] > > Packet Transport Protocol Optional [Default UDP] > > Qbicc.QoSrej Reason [TBD] Mandatory > > 5 Q.CBC related QoS primitives and parameters > > The Q.CBC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. > > 5.1 Q.CBC related QoS primitives > > This information flow (QT2 in ETSI TS 101 329 part 3) communicates the QoS related transport flow information between a service domain and an associated transport domain. This information contains the QoS related characteristics required of the transport flows that will carry the media flow and the properties of the media flow. > > Q.CBC QoS request (Qcbc.QoSreq) requests the establishment of a transport flow with defined QoS characteristics across a Transport Domain or the reservation of Transport Domain resource. > > NOTE Identical to TRM QoS request (QT2.TRMQreq) in ETSI TS 101 329 part 3 clause 8.1.3. > > Q.CBC QoS confirm (Qcbc.QoSconf) acknowledges the creation of a requested transport flow or the reservation of Transport Domain resource. > > NOTE Identical to TRM QoS confirm (QT2.TRMQconf) in ETSI TS 101 329 part 3 clause 8.1.3. > > Q.CBC QoS reject (Qcbc.QoSrej) rejects the creation of a requested transport flow or the reservation of Transport Domain resource. > > NOTE Identical to TRM QoS reject (QT2.TRMQrej) in ETSI TS 101 329 part 3 clause 8.1.3. > > Q.CBC QoS release request (Qcbc.QoSrelreq) requests the release of a transport flow. > > NOTE Identical to TRM QoS release request (QT2.TRM QoS relreq) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. > > Q.CBC QoS release confirm (Qcbc.QoSrelconf) confirms the release of a transport flow. > > NOTE Identical to TRM QoS release confirm (QT2.TRM QoS relconf) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. > > Q.CBC QoS performance notification (Qcbc.QoSperfnotif) notifies the Service Domain of the performance of the Transport Domain in meeting the requested QoS levels. This may be a periodic event or an urgent alarm. Note: this primitive is a management primitive and its use is for further study. > > NOTE Identical to TRM QoS performance notification (QT2.TRM QoS perfnotif) in ETSI TS 101 329 part 3 clause 8.1.3. For further study. > > 5.2 Q.CBC related QoS parameters > > Table 2 lists the parameters used in the Q.CBC related QoS primitives not yet covered by the Q.CBC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in Q.1950. > > NOTE The contents of Table 2 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.5. > > Table 2: Identification of Q.CBC related parameters for end-to-end QoS service control > > QT2.TRMQreq Transport QoS Parameters Mandatory > > Traffic Descriptor Mandatory > > Transport Addresses Mandatory > > Packet Transport Protocol Optional [Default UDP] > > QT2.TRMQconf Transport QoS Parameters Mandatory > > Transport Addresses Mandatory > > Packet Transport Protocol Optional [Default UDP] > > QoS Mechanism Optional > > QT2.TRMQrej Reason [TBD] Mandatory > > 6 Parameter contents > > Table 3 specifies the information to be covered by the parameters listed in sections 4.2 and 5.2 based on the QoS parameter groups in ETSI TS 101 329 part 3 clause 8.2.1. > > Table 3: Identification of parameter contents for end-to-end QoS service control > > QoS Service Class Describes the end-to-end ETSI TIPHON Best, High, Medium > class of a bearer or Best Effort > > Transport QoS Specifies the QoS characteristics Maximum Delay > Parameters required of the transport flow > carrying the media flow. Maximum Packet Delay Variation > > Maximum Packet Loss > > Traffic Descriptor Characterises the resource Peak Bit > requirements of an application data > flow (excludes transport flow Maximum Packet Size > resource requirements). > > Parameters specifying the ETSI TIPHON QoS Class as defined in ETSI TS 101 329 Part 2 > > The maximum delay permitted (ms) over either a segment of the transport flow or the remaining part of the transport flow. > > The maximum packet delay variation permitted (ms) over either a segment of the transport flow or the remaining part of the transport flow. > > The maximum packet loss permitted (%) over either a segment of the transport flow or the remaining part of the transport flow. [N.B. This measure assumes randomly distributed packet loss] > Maximum bit rate (bit/s) of the media flow. > > Maximum size of the media packets > > 7 Information flows and signalling procedures for end-to-end QoS service control > > EDITORS’ NOTE The information flows and signalling procedures for end-to-end QoS service control may be considered to follow the same principles as the already existing procedures for end-to-end codec negotiation in BICC CS1 and BICC CS2. Similarly mid-call procedures for end-to-end QoS modification and mid-call QoS modification may be considered because the perceived QoS is highly related to the codec type employed end- to-end as part of the connection. The exact scope and properties of these procedures and protocol message flows needs further discussion. > > Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and protocols > Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jun 5 11:49:29 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23983 for ; Tue, 5 Jun 2001 11:49:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 82E3D44415; Tue, 5 Jun 2001 11:16:56 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by lists.bell-labs.com (Postfix) with ESMTP id 9773B44336; Fri, 1 Jun 2001 21:04:23 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id SAA01831; Fri, 1 Jun 2001 18:01:53 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id SAA28925 for corey@hearme.com; Fri, 1 Jun 2001 18:01:04 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id PAA16573 for ; Thu, 31 May 2001 15:14:18 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id PAA22048 for ; Thu, 31 May 2001 15:14:17 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9250344493; Thu, 31 May 2001 17:56:31 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by lists.bell-labs.com (Postfix) with SMTP id 55964443C5; Thu, 31 May 2001 12:12:00 -0400 (EDT) Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 31 May 2001 17:11:33 +0100 To: Lloyd Wood Cc: Fred Baker , gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, John C Klensin , chair@ietf.org, J.Crowcroft@cs.ucl.ac.uk In-reply-to: Your message of "Thu, 31 May 2001 16:13:43 BST." Message-ID: <922.991325489@cs.ucl.ac.uk> From: Jon Crowcroft X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk Content-Type: text Subject: [IPTEL] [SIP] Re: [Diffserv] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 31 May 2001 17:11:29 +0100 so the talk seems to be dated dec 2001, and makes me wonder if the tiphon folks have achieved a breakthru in QOS with e2e delays better than 0ms..... meanwhile, i stuck html versions of the files below at ftp://cs.ucl.ac.uk/darpa/tiphon/ (prob. doesnt help non windoze users since the html is generated by office 2000 apps so unless you have the unix internet explorer, too bad) In message , Lloyd Wood typed: >>On Wed, 30 May 2001, Fred Baker wrote: >> >>> Greg: >>> >>> The URLs in this note were all sent with what the ETSI machine considered >>> to be 'malformed syntax'. Could you resend the correct URLs? >> >>Just put all the parts together, removing unencoded >>spaces; the reason for the breaks after the hyphens seems >>obvious enough, but I'm at a loss to explain others. Here we go: >> >>http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05009/V1.1.1/ts_101329-2v111p.doc >> >>http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05003/DTS05003v096.zip >> >>http://webapp.etsi.org/tbhomepage/TBDetails.asp?TB_ID=291&TB_NAME=TIPHON >> >>http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/ARCHIVES/2000/05-200012-Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt >> >>So http://docbox.etsi.org/ is passworded but docs can be retrieved by >>advertised public direct url? Bizarre. >> >>L. >> >>PGP >> >> >> >> >> >> >> cheers jon _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jun 5 11:53:03 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24030 for ; Tue, 5 Jun 2001 11:53:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4D247443A9; Tue, 5 Jun 2001 11:17:00 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by lists.bell-labs.com (Postfix) with ESMTP id BF83B44336; Fri, 1 Jun 2001 21:05:01 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id SAA01881; Fri, 1 Jun 2001 18:03:04 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id SAA28947 for corey@hearme.com; Fri, 1 Jun 2001 18:01:53 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id PAA16766 for ; Thu, 31 May 2001 15:25:22 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id PAA22255 for ; Thu, 31 May 2001 15:25:21 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F0889444AA; Thu, 31 May 2001 17:56:48 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id 21E354434B; Thu, 31 May 2001 13:12:28 -0400 (EDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4VHBBU27133; Thu, 31 May 2001 10:11:12 -0700 (PDT) Message-Id: <5.1.0.14.2.20010531095817.04c50ea8@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: "Roy, Radhika R, ALCTA" From: Fred Baker Cc: Bob Braden , gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM In-Reply-To: Mime-Version: 1.0 X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [IPTEL] [SIP] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 31 May 2001 10:09:10 -0700 At 06:08 AM 5/31/2001, Roy, Radhika R, ALCTA wrote: >All applications (e.g., H.323, SIP) uses signaling messages >among its functional entities (e.g., terminal, agents, >gatekeepers, proxies, gateways) for communications. I'm not sure we're on the same planet. Please help me out here. I can think of a few applications that have agents, gatekeepers, proxies, and gateways, mostly resulting from the imposition of firewalls or authentication systems, or from legacy applications like imitating the telephone system in a data network. The only one that *requires* any kind of gateway, to my knowledge, is H.323 teleconferencing, which represents a paltry fraction of traffic according to most current measurements. Anything else (75% of Internet traffic is http or FTP, most of the rest is mail, on private LANs applications like NFS are pretty common, and even SIP can be done without a gateway between consenting systems) could be hooked up in separate systems on a LAN and made to work without any such signalling at all. Could you be more specific on what QoS signalling is required by the world wide web, mail, FTP, common ERP applications like ERP and PeopleSoft, calendaring, and so on? If not, could you be more specific about what "all" applications you have in mind? And could you be more specific about what issues this proposal is addressing that have not already been addressed in de facto standards and deployed in operational systems? It would be very nice to understand what you are preparing to ask vendors to do, and whether operators are interested in deploying them. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jun 5 12:14:49 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24894 for ; Tue, 5 Jun 2001 12:14:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C02254443C; Tue, 5 Jun 2001 11:17:07 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from web12306.mail.yahoo.com (web12306.mail.yahoo.com [216.136.173.104]) by lists.bell-labs.com (Postfix) with SMTP id C41B244336 for ; Mon, 4 Jun 2001 20:01:22 -0400 (EDT) Message-ID: <20010605000119.5975.qmail@web12306.mail.yahoo.com> Received: from [134.193.111.187] by web12306.mail.yahoo.com; Mon, 04 Jun 2001 17:01:19 PDT From: Karthik To: iptel@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [IPTEL] Query on retrieval of Location Information for an IPTel Call Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 4 Jun 2001 17:01:19 -0700 (PDT) Hi All, I am new to the subject of IP telephony and its related issues but I was wondering if there are any efforts to locate the actual geographic/physical location information of any call that originates from an IP address-based endpoint like an IP Phone or IPTel enabled computer. To my knowlege, any such retrieval currently gives you the IP address of that endpoint and/or the address to which it might have been registered.This information may not always be reliable as it is possible that the endpoint might be registered at one location but might actually connect from another and still have a valid IP address. I would appreciate any comments on this. regards karthik. ===== -- Karthik Venkataraman -- Graduate Assistant, Networking Lab, UMKC (816) 674-9612 (C) (816) 235-2996 (O) __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jun 5 12:18:43 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24981 for ; Tue, 5 Jun 2001 12:18:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5EDDD44433; Tue, 5 Jun 2001 11:17:04 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by lists.bell-labs.com (Postfix) with SMTP id 56A2944336; Sat, 2 Jun 2001 06:42:53 -0400 (EDT) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 2 Jun 2001 11:42:33 +0100 To: rrroy@att.com Cc: gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, iptel@lists.bell-labs.com, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM, J.Crowcroft@cs.ucl.ac.uk In-reply-to: Your message of "Wed, 30 May 2001 23:39:17 GMT." <200105302339.XAA13198@gra.isi.edu> Message-ID: <1723.991478550@cs.ucl.ac.uk> From: Jon Crowcroft Subject: [IPTEL] Re: [SIP] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Sat, 02 Jun 2001 11:42:30 +0100 1/ please stop copying all the lists. most of us are on all of them 2/ this is a layering question and is clearly indpenenant of mapping qos at lower layers (if it isnt its severely broken) - its clear that diffserve and issll sit several layeres BELOW what you want to do and that the signaling mechanisms for both are indpeennsdat and much lower - i notice for example you dont include 802.1p and q - similar layer type stuff... 3/ the docs cited are telpeony specific EXTREMELY and in fact dont relate to results that show that people have broader tolerances than yo umight expect when using different ways to get voice around - while its reasoanble to have a subset of QoS parameters signaled fro mapps that are application specific, a better way to do it is through a profiling mechanisms, which has a code point scheme, that then uses more general means to signal the actual QoS parameters 4/ the IETF has several appropriate signaling protocol efforts and paramerter specification schemes...although i believe its not well architectured across all the layers right now and its not clear we have a profile mechansism/language/syntax/semantics 5/ there's the siglite discussio ngoing on and there was the bof to talk about new signaling protocols at the last IETF _ this seems to be somewhat ignoring that activity - is that intentional? if so why? j. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jun 5 12:20:19 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25052 for ; Tue, 5 Jun 2001 12:20:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E0DC344446; Tue, 5 Jun 2001 11:17:11 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by lists.bell-labs.com (Postfix) with ESMTP id 022A944336; Tue, 5 Jun 2001 01:29:28 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id WAA09672; Mon, 4 Jun 2001 22:27:30 -0700 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id WAA20780; Mon, 4 Jun 2001 22:27:29 -0700 Message-ID: <3B1C6DEA.477A8786@hursley.ibm.com> From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Roy, Radhika R, ALCTA" Cc: gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM Subject: Re: [Diffserv] [IPTEL] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 05 Jun 2001 00:28:10 -0500 Content-Transfer-Encoding: 7bit Hey! I asked people to STOP including diffserv@ietf.org on this thread. Please take notice everybody. Diffserv doesn't want to know. It is not our business. Talk about this somewhere else. Really. Brian Carpenter diffserv co-chair "Roy, Radhika R, ALCTA" wrote: > > Hi, Everyone: > > Question Q.F/16 of ITU-T SG16 is fully dedicated for developing standards > for "End-to-End QOS for Multimedia Applications". Contributions are also > being under discussion in the ITU-T SG16 Brazil May 28 - June 8, 2001 > meeting. > > Applications like H.323, SIP, H.324, H.310, and others will also be able to > use this Q.F/16's QOS signaling protocol. MEGACO/H.248 and BICC will also be > able to use this when specs are fully developed and, TIPHON's QOS mechanisms > can also be used as one of the mechanisms for implementations. > > BICC and MEGCAO/H.248 are only used as the protocol between the gateways, > NOT end-to-end (although SIP/H.323 or other protocols may be used between > the gateways). > > The "End-to-End QOS for Multimedia Applications" of SG16 can also be termed > as "Application Layer QOS." > > Q.F/16's end-to-end application layer QOS can also be implemented over the > network layer QOS like RSVP, DiffServe, and/or MPLS after proper mapping. > Similar is the case for the ATM network. > > Please note that the network layer QOS (e.g., RSVP, DiffServe, and/or MPLS) > may or may not have the end-to-end significance. For example, an IP network > may implement different QOS schemes in different domains (e.g., RVSP in one > domain, DiffServ in another domain). > > However, the application layer QOS is end-to-end that remains the same. For > example, an H.323 or SIP call that can traverse several IP domains where > each domain may implement its own network layer QOS schemes while the > H.323/SIP call carry the signaling messages and QOS parameters end-to-end > independent of the underlying network layer QOS mechanisms. > > Let us work together. > > Best regards, > Radhika R. Roy > AT&T > > -----Original Message----- > From: Greg Ratta [mailto:gratta@lucent.com] > Sent: Wednesday, May 30, 2001 4:22 PM > To: sob@harvard.edu; mankin@isi.edu > Cc: diffserv@ietf.org; iptel@lists.bell-labs.com; issll@mercury.lcs.mit.edu; > megaco@fore.com; sip@lists.bell-labs.com; sipping@ietf.org; tsvwg@ietf.org; > Yukio Hiramatsu; rbuhrke@lucent.com; tsg11q8@ties.itu.ch; > tsg11q9@ties.itu.ch > Subject: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR > END-TO-END QOS SERVICE CONTROL > > This message was agreed to at ITU-T Study Group 11 meeting (Geneva, May > 2001) and is being transmitted on behalf of Yukio Hiramatsu, Chairman of > ITU-T SG 11. For further technical clarification, contact the Rapporteur for > Q9/11 (Rolfe Buhrke, Tel: + 1 630 713 7022, { HYPERLINK > mailto:rburke@lucent.com }rbuhrke@lucent.com) > > FULL TITLE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR > END-TO-END QOS SERVICE CONTROL AND SIGNALLING PROTOCOL DEVELOPMENT BASED ON > IP TRANSFER CAPABILITIES AND IP QOS CLASSES > > General > > Within ITU-T SG11 work has started on requirements for a generic protocol > mechanism for end-to-end QoS service control. It was agreed within SG11 to > proceed with this work utilising deliverables of ETSI TIPHON on end- to-end > QoS service control as base material. It is the opinion of SG11 that this > generic protocol mechanism for BICC intends to apply also to other protocols > like SIP/SDP and H.323 next to generic extensions to the H.248/MEGACO > protocol. > > It was noted that also QoS related work is in progress in IETF. Please find > attached an initial draft of the BICC CS3 signalling requirements for > end-to-end QoS service control. Please note the rationale for this activity > and the framework for end-to-end QoS service control and network QoS > control. The framework illustrates the field of application of the QoS > handling at different levels and the different protocols involved. > > Proposals on end-to-end QoS service control > > It is proposed to start a joint activity with IETF on a generic protocol > mechanism for end- to-end QoS service control. This refers to the potential > work in IETF on the following topics: > > - Identification of the signalling requirements based on the ETSI TIPHON > defined speech QoS service classes for VoIP and the signalling and control > of end-to-end QoS for VoIP. The attachment provides the initial draft of the > BICC CS3 signalling requirements for end-to-end QoS service control. > > - The definition of a generic call/bearer control mechanism in H.225/H.245, > SIP/SDP and BICC CS3 for end-to-end QoS service control in the application > plane. > > - The definition of generic extensions to H.248/MEGACO for end-to-end QoS > service control between the application plane and the transport plane. > > - The translation between the generic protocol QoS information elements in > H.248/MEGACO and the technology specific QoS parameters and QoS mechanisms > in IP, ATM, MPLS, etc. > > Proposals on IP QoS classes and IP Transfer Capabilities > > ITU-T SG11 would like to inform IETF that it is investigating signalling > requirements for protocol development based on the IP Transfer Capabilities > and IP QoS classes, as being defined by ITU-T SG13 in Y.1541 and Y.iptc. The > plan is to build upon signalling approaches developed by IETF. We would like > to stress that the work on IP QoS classes and IP Transfer Capabilities by > ITU-T SG13 is co- ordinated with IETF. > > ATTACHMENT Initial draft text of the BICC CS3 signalling requirements > for end-to-end QoS service control. > > The ETSI specifications referenced as base material are available at the > following URLs: > > ETSI TS 301 329 part 2, http://docbox.etsi.org/tech- > org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05009/V1.1.1/ts_10 > 1329-2v111p.doc > > - ETSI TS 301 329 part 3 see http://docbox.etsi.org/tech- > org/tiphon/Document/tiphon/07- > drafts/wg5/_Published/DTS05003/DTS05003v096.zi p > > Further information about the ETSI TIPHON project is available at the > following URL: > > - http://webapp.etsi.org/tbhomepage/TBDetails.as p?TB_ID=291&TB_NAME=TIPHON > > __________________ > > BICC CS3 signalling requirements for end-to- end QoS service control > > EDITORS' NOTE: This requirements text for end-to-end QoS service control is > a first draft text and requires extensive updating based on liaison > activities with other groups > > 1 Rationale > > The rationale of the BICC CS3 requirements for end-to-end service control is > based on the analysis made by ETSI TIPHON (see the presentation available at > the URL: http://docbox.etsi.org/tech- > org/tiphon/Document/tiphon/ARCHIVES/2000/05- 200012- > Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt ). It shows the > inter-relationship between the different QoS factors that finally determine > > the perceived speech quality by the end- users. This perceived speech > quality does not only depend on network quality of service (network packet > loss, network jitter and network delay) but on the terminal implementation > (jitter buffers and codec performance) as well. > > A second rationale is that end-to-end QoS requirements can be regarded as > end-to-end quality budgets related to the media flows. To achieve the > required end-to-end QoS these quality budgets must be allocated between the > domains, including the user equipment (see Figure 7 in ETSI TS 301 329 part > 3). The Transport QoS Parameters specify the QoS budgets for each Transport > Domain. It is assumed that the performance of each domain is statistically > independent from any other. > > Therefore end-to-end QoS service control at the call control level (i.e. > application plane) is required based on generic signalling procedures in > protocols like BICC, SIP/SDP, H.323 and H.248/MEGACO for end-to- end QoS > service control. > > 2 Framework for end-to-end QoS service control and network QoS control. > > A framework for QoS control may be considered at different levels: call > control (BICC, SIP/SDP, H.323), vertical control (H.248/MEGACO, CBC), bearer > control (IP BCP) and bearer (DiffServ, IntServ/RSVP or MPLS/LDP). > > 1) Call-control > > a) End-to-end QoS service control is negotiated/communicated end-to-end at > the call control level. ETSI TIPHON has defined a set of speech QoS classes, > and signalling requirements and flows for this purpose. > > The idea is that call control protocols are enhanced with a generic > end-to-end QoS service control mechanism to negotiate these speech QoS > classes and associated parameters (Maximum delay, Maximum packet delay > variation, Maximum packet loss, Peak bit rate and Maximum packet size). > > Such a generic end-to-end QoS service control mechanism should be defined > independent of the underlying technology (ATM or IP) and operate across > network domains and including terminal characteristics to > negotiate/communicate the requested listener speech quality that will be > perceived by the end-users (i.e. "mouth-to-ear"). > > b) BICC (Q.190x) is one of the call control protocols that may be enhanced > this way. Similar enhancements may be applicable to other call-control > protocols like SIP/SDP and H.323. > > 2) Vertical control > > a) QoS service control is also negotiated/communicated at the vertical > control level. The ETSI TIPHON defined signalling requirements and flows > include the vertical interface. The idea is that vertical control protocols > are enhanced to negotiate/communicate the QoS settings (Maximum delay, > Maximum packet delay variation, Maximum packet loss, Peak bit rate and > Maximum packet size) in the bearer core network based on generic > H.248/MEGACO extensions. > > These QoS settings should be defined independent of the underlying > technology (ATM or IP) of the bearer core network. > > b) CBC (Q.1950) is one of the vertical control protocols that may be > enhanced this way. > > 3) Bearer control > > a) Network QoS is negotiated/communicated at the bearer control level. ATM > signalling does already intrinsically support network QoS. SG13 has recently > defined IP QoS classes and IP Transfer Capabilities. > > The idea is that bearer control protocols for IP are enhanced with a > mechanism to negotiate the network QoS by using IP QoS classes and IP > Transfer Capabilities. > > b) IP BCP (Q.1970) is an IP bearer control protocol that may be enhanced > this way. > > 4) Bearer > > a) Network QoS is negotiated/communicated at the bearer level, i.e. as part > of the protocols associated with the bearers in the core network. The idea > is that IP QoS classes and IP Transfer Capabilties, as defined by SG13, are > used to differentiate between different types of IP traffic. > > b) IP QoS classes and IP Transfer Capabilities may be used to enhance > existing IP mechanisms like DiffServ, IntServ/RSVP and MPLS/LDP. > > 3 QoS information flows applicable to BICC > > A general model is considered for QoS information flows with BICC when > making a translation of the relevant parts in Figure 8 in ETSI TS 301 329 > part 3. > > Section 4 details the Q.BICC related QoS primitives and parameters based on > the QoS primitives and parameters in the ETSI deliverable. Similarly, > section 5 provides the Q.CBC related QoS primitives and parameters. > > 4 Q.BICC related QoS primitives and parameters > > The Q.BICC related QoS primitives and parameters are extracted from clause > 8.1 and clause 8.2 of ETSI TS 101 329 part 3. > > 4.1 Q.BICC related QoS primitives > > This information flow (QC2 in ETSI TS 101 329 part 3) communicates the QoS > related bearer information between the domains of different service > providers. > > Q.BICC QoS request (Qbicc.QoSreq) requests the establishment of a bearer > conforming to a particular ETSI TIPHON Class of Service or with defined QoS > characteristics. > > NOTE Identical to QoSM request (QC2.QoSMreq) in ETSI TS 101 329 part 3 > clause 8.1.1. > > Q.BICC QoS confirm (Qbicc.QoSconf) acknowledges the creation of a bearer > conforming to a requested ETSI TIPHON QoS Class or with specified QoS > characteristics. > > NOTE Identical to QoSM confirm (QC2.QoSMconf) in ETSI TS 101 329 part 3 > clause 8.1.1. > > Q.BICC QoS reject (Qbicc.QoSrej) rejects the creation of a bearer conforming > to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. > > NOTE Identical to QoSM reject (QC2.QoSMrej) in ETSI TS 101 329 part 3 > clause 8.1.1. > > Q.BICC release request (Qbicc.QoSrelreq) requests the release of a bearer. > > NOTE Identical to QoSM release request (QC2.QoSMrelreq) in ETSI TS 101 > 329 part 3 clause 8.1.1 and the release of a transport flow is already > covered by existing Q.BICC procedures in Q.1902 series. > > QoSM release confirm (Qbicc.QoSrelconf) confirms the release of a bearer. > > NOTE Identical to QoSM release confirm (QC2.QoSMrelconf) in ETSI TS 101 > 329 part 3 clause 8.1.1 and the release of a transport flow is already > covered by existing Q.BICC procedures in Q.1902 series. > > 4.2 Q.BICC related QoS parameters > > Table 1 lists the parameters used in the Q.BICC related QoS primitives not > yet covered by the Q.BICC protocol. The deleted items refer to the > information elements already covered by the BICC CS2 protocol in the Q.1902 > series. > > NOTE The contents of Table 1 is an interpretation of the table in ETSI TS > 101 329 part 3 clause 8.2.3. > > Table 1: Identification of Q.BICC related parameters for end-to-end QoS > service control > > Qbicc.QoSreq QoS Service Class Optional > > Codec Type and Packetisation Mandatory > > Transport QoS Parameters Mandatory > > Traffic Descriptor Optional > > Transport Addresses Mandatory > > Application Data Transport Protocol Optional > [Default RTP] > > Packet Transport Protocol Optional [Default UDP] > > QoS Mechanism Optional > > Qbicc.QoSconf QoS Service Class Optional > > Codec Type and Packetisation Mandatory > > Transport QoS Parameters Mandatory > > Transport Addresses Mandatory > > Application Data Transport Protocol Optional > [Default RTP] > > Packet Transport Protocol Optional [Default UDP] > > Qbicc.QoSrej Reason [TBD] Mandatory > > 5 Q.CBC related QoS primitives and parameters > > The Q.CBC related QoS primitives and parameters are extracted from clause > 8.1 and clause 8.2 of ETSI TS 101 329 part 3. > > 5.1 Q.CBC related QoS primitives > > This information flow (QT2 in ETSI TS 101 329 part 3) communicates the QoS > related transport flow information between a service domain and an > associated transport domain. This information contains the QoS related > characteristics required of the transport flows that will carry the media > flow and the properties of the media flow. > > Q.CBC QoS request (Qcbc.QoSreq) requests the establishment of a transport > flow with defined QoS characteristics across a Transport Domain or the > reservation of Transport Domain resource. > > NOTE Identical to TRM QoS request (QT2.TRMQreq) in ETSI TS 101 329 part 3 > clause 8.1.3. > > Q.CBC QoS confirm (Qcbc.QoSconf) acknowledges the creation of a requested > transport flow or the reservation of Transport Domain resource. > > NOTE Identical to TRM QoS confirm (QT2.TRMQconf) in ETSI TS 101 329 part > 3 clause 8.1.3. > > Q.CBC QoS reject (Qcbc.QoSrej) rejects the creation of a requested transport > flow or the reservation of Transport Domain resource. > > NOTE Identical to TRM QoS reject (QT2.TRMQrej) in ETSI TS 101 329 part 3 > clause 8.1.3. > > Q.CBC QoS release request (Qcbc.QoSrelreq) requests the release of a > transport flow. > > NOTE Identical to TRM QoS release request (QT2.TRM QoS relreq) in ETSI TS > 101 329 part 3 clause 8.1.3. The release of a transport flow is already > covered by the existing Q.CBC procedures in Q.1950. > > Q.CBC QoS release confirm (Qcbc.QoSrelconf) confirms the release of a > transport flow. > > NOTE Identical to TRM QoS release confirm (QT2.TRM QoS relconf) in ETSI > TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already > covered by the existing Q.CBC procedures in Q.1950. > > Q.CBC QoS performance notification (Qcbc.QoSperfnotif) notifies the Service > Domain of the performance of the Transport Domain in meeting the requested > QoS levels. This may be a periodic event or an urgent alarm. Note: this > primitive is a management primitive and its use is for further study. > > NOTE Identical to TRM QoS performance notification (QT2.TRM QoS > perfnotif) in ETSI TS 101 329 part 3 clause 8.1.3. For further study. > > 5.2 Q.CBC related QoS parameters > > Table 2 lists the parameters used in the Q.CBC related QoS primitives not > yet covered by the Q.CBC protocol. The deleted items refer to the > information elements already covered by the BICC CS2 protocol in Q.1950. > > NOTE The contents of Table 2 is an interpretation of the table in ETSI TS > 101 329 part 3 clause 8.2.5. > > Table 2: Identification of Q.CBC related parameters for end-to-end QoS > service control > > QT2.TRMQreq Transport QoS Parameters Mandatory > > Traffic Descriptor Mandatory > > Transport Addresses Mandatory > > Packet Transport Protocol Optional [Default UDP] > > QT2.TRMQconf Transport QoS Parameters Mandatory > > Transport Addresses Mandatory > > Packet Transport Protocol Optional [Default UDP] > > QoS Mechanism Optional > > QT2.TRMQrej Reason [TBD] Mandatory > > 6 Parameter contents > > Table 3 specifies the information to be covered by the parameters listed in > sections 4.2 and 5.2 based on the QoS parameter groups in ETSI TS 101 329 > part 3 clause 8.2.1. > > Table 3: Identification of parameter contents for end-to-end QoS service > control > > QoS Service Class Describes the end-to-end ETSI TIPHON Best, > High, Medium > > class of a beareror Best Effort > > Transport QoS Specifies the QoS characteristics Maximum > Delay > > Parameters required of the transport flow > > carrying the media flow. Maximum Packet > Delay Variation > > Maximum Packet Loss > > Traffic Descriptor Characterises the resource Peak Bit > > requirements of an application data > > flow (excludes transport flow Maximum Packet Size > > resource requirements). > > Parameters specifying the ETSI TIPHON QoS Class as defined in ETSI TS 101 > 329 Part 2 > > The maximum delay permitted (ms) over either a segment of the transport flow > or the remaining part of the transport flow. > > The maximum packet delay variation permitted (ms) over either a segment of > the transport flow or the remaining part of the transport flow. > > The maximum packet loss permitted (%) over either a segment of the transport > flow or the remaining part of the transport flow. [N.B. This measure assumes > randomly distributed packet loss] > > Maximum bit rate (bit/s) of the media flow. > > Maximum size of the media packets > > 7 Information flows and signalling procedures for end-to-end QoS service > control > > EDITORS' NOTE The information flows and signalling procedures for > end-to-end QoS service control may be considered to follow the same > principles as the already existing procedures for end-to-end codec > negotiation in BICC CS1 and BICC CS2. Similarly mid-call procedures for > end-to-end QoS modification and mid-call QoS modification may be considered > because the perceived QoS is highly related to the codec type employed end- > to-end as part of the connection. The exact scope and properties of these > procedures and protocol message flows needs further discussion. > > Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and > protocols > > Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, > gratta@lucent.com > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jun 5 12:21:50 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25126 for ; Tue, 5 Jun 2001 12:21:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F1CF34444F; Tue, 5 Jun 2001 11:17:15 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by lists.bell-labs.com (Postfix) with ESMTP id 4EDB944337 for ; Tue, 5 Jun 2001 05:36:28 -0400 (EDT) Received: from imp1-1.free.fr (imp1-1.free.fr [213.228.0.21]) by postfix2-1.free.fr (Postfix) with ESMTP id 90B2AC117 for ; Tue, 5 Jun 2001 11:36:27 +0200 (CEST) Received: (from www-data@localhost) by imp1-1.free.fr (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0-1) id f559aNQ2005890 for iptel@lists.bell-labs.com; Tue, 5 Jun 2001 11:36:23 +0200 To: iptel@lists.bell-labs.com Message-ID: <991733783.3b1ca81718a72@imp.free.fr> From: patrick.mourot@online.fr MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.3 X-Originating-IP: 212.208.74.5 Subject: [IPTEL] lightweight TRIP protocol for gateway Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 05 Jun 2001 11:36:23 +0200 (MEST) Content-Transfer-Encoding: 8bit Sirs, I would like to know the status of a "lightweight TRIP protocol for gateway". Any pointers ?? TIA, best Regards, Patrick _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Jun 6 03:16:39 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA22946 for ; Wed, 6 Jun 2001 03:16:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A3F944433D; Wed, 6 Jun 2001 03:17:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 352A144337 for ; Wed, 6 Jun 2001 03:16:07 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA29525; Wed, 6 Jun 2001 03:20:03 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Jun 2001 03:16:05 -0400 Message-ID: From: Jonathan Rosenberg To: "'patrick.mourot@online.fr'" , iptel@lists.bell-labs.com Subject: RE: [IPTEL] lightweight TRIP protocol for gateway MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 6 Jun 2001 03:16:03 -0400 > -----Original Message----- > From: patrick.mourot@online.fr [mailto:patrick.mourot@online.fr] > Sent: Friday, June 01, 2001 4:40 AM > To: iptel@lists.bell-labs.com > Subject: [IPTEL] lightweight TRIP protocol for gateway > > > Sir, > > I would like to know the status of a "lightweight TRIP > protocol for gateway". > Any pointers ?? The draft has expired some time ago. You can pick up a copy from: http://www.jdrosen.net/papers/draft-rs-trip-gw-01.txt At IETF 50, we agreed to recharter the iptel working group, and that one of the items on that new charter would be the specification of a protocol from the gayteways to a server for the purposes of routing calls over the last hop. The above work would become the starting point for that activity. I have been delinquint in actually submitting the updated charter and in revising the above draft, but that is the plan. -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 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Jun 6 19:30:41 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10578 for ; Wed, 6 Jun 2001 19:30:41 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 00B9644341; Wed, 6 Jun 2001 19:31:03 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from hotmail.com (f110.law3.hotmail.com [209.185.241.110]) by lists.bell-labs.com (Postfix) with ESMTP id E08144433D for ; Wed, 6 Jun 2001 19:30:54 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 6 Jun 2001 16:30:55 -0700 Received: from 129.107.63.223 by lw3fd.law3.hotmail.msn.com with HTTP; Wed, 06 Jun 2001 23:30:54 GMT X-Originating-IP: [129.107.63.223] From: "kolli satishkumar" To: iptel@lists.bell-labs.com Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 06 Jun 2001 23:30:55.0115 (UTC) FILETIME=[BB702DB0:01C0EEE0] Subject: [IPTEL] thanks Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 07 Jun 2001 05:00:54 +0530




Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

_______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Jun 11 14:34:37 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16467 for ; Mon, 11 Jun 2001 14:34:37 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1CAAE4436B; Mon, 11 Jun 2001 14:35:03 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ss8mail1.ss8ott (mail.ss8.ca [209.87.228.147]) by lists.bell-labs.com (Postfix) with ESMTP id 751E044338 for ; Mon, 11 Jun 2001 14:27:02 -0400 (EDT) Received: from DAVID ([192.168.1.61]) by ss8mail1.ss8ott with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id K0L39VR6; Mon, 11 Jun 2001 14:27:18 -0400 From: "David Zinman" To: "Jonathan Rosenberg" , Cc: "Dave Walker" Subject: RE: [IPTEL] [TRIP-MIB] lightweight TRIP protocol for gateway Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 11 Jun 2001 14:27:01 -0400 Content-Transfer-Encoding: 7bit Regarding the TRIP mib: there are two objects which apply to TRIP for gateways: tripRouteCircuitCapacity and tripRouteDSPCapacity. Are there any objections to leaving these two attributes in the MIB, or should they be moved to another MIB which augments TRIP-MIB? One argument for removing them is that they are not part of the main TRIP draft, but defined in a separate draft which is still in its early stages so they might merit a separate MIB. I'd appreciate any guidance here. Cheers, DZ --- David Zinman SS8 Networks Inc. Phone: (613)592-2100 Ext. 3252 Fax: (613)592-9634 mailto:david@ss8.com http://www.ss8.com -----Original Message----- From: iptel-admin@lists.bell-labs.com [mailto:iptel-admin@lists.bell-labs.com]On Behalf Of Jonathan Rosenberg Sent: Wednesday, June 06, 2001 3:16 AM To: 'patrick.mourot@online.fr'; iptel@lists.bell-labs.com Subject: RE: [IPTEL] lightweight TRIP protocol for gateway > -----Original Message----- > From: patrick.mourot@online.fr [mailto:patrick.mourot@online.fr] > Sent: Friday, June 01, 2001 4:40 AM > To: iptel@lists.bell-labs.com > Subject: [IPTEL] lightweight TRIP protocol for gateway > > > Sir, > > I would like to know the status of a "lightweight TRIP > protocol for gateway". > Any pointers ?? The draft has expired some time ago. You can pick up a copy from: http://www.jdrosen.net/papers/draft-rs-trip-gw-01.txt At IETF 50, we agreed to recharter the iptel working group, and that one of the items on that new charter would be the specification of a protocol from the gayteways to a server for the purposes of routing calls over the last hop. The above work would become the starting point for that activity. I have been delinquint in actually submitting the updated charter and in revising the above draft, but that is the plan. -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 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Jun 11 18:04:35 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19870 for ; Mon, 11 Jun 2001 18:04:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9DA4F44339; Mon, 11 Jun 2001 18:05:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 4AAAA44337 for ; Mon, 11 Jun 2001 18:04:51 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA14788; Mon, 11 Jun 2001 18:08:51 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Jun 2001 18:04:50 -0400 Message-ID: From: Jonathan Rosenberg To: "'David Zinman'" , Jonathan Rosenberg , iptel@lists.bell-labs.com Cc: Dave Walker Subject: RE: [IPTEL] [TRIP-MIB] lightweight TRIP protocol for gateway MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 11 Jun 2001 18:04:45 -0400 I think that they should not be in the TRIP MIB. Rather, the MIB should have a way to handle new attributes defined in extensions, and these would be handled by that. I think we had actually decided that some time back. -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 > -----Original Message----- > From: David Zinman [mailto:david@ss8.com] > Sent: Monday, June 11, 2001 2:27 PM > To: Jonathan Rosenberg; iptel@lists.bell-labs.com > Cc: Dave Walker > Subject: RE: [IPTEL] [TRIP-MIB] lightweight TRIP protocol for gateway > > > Regarding the TRIP mib: there are two objects which apply to > TRIP for gateways: tripRouteCircuitCapacity and tripRouteDSPCapacity. > > Are there any objections to leaving these two attributes in the MIB, > or should they be moved to another MIB which augments TRIP-MIB? > > One argument for removing them is that they are not part of the main > TRIP draft, but defined in a separate draft which is still in > its early > stages so they might merit a separate MIB. > > I'd appreciate any guidance here. > > Cheers, > DZ > > --- > David Zinman > SS8 Networks Inc. > Phone: (613)592-2100 Ext. 3252 > Fax: (613)592-9634 > mailto:david@ss8.com http://www.ss8.com > > > -----Original Message----- > From: iptel-admin@lists.bell-labs.com > [mailto:iptel-admin@lists.bell-labs.com]On Behalf Of Jonathan > Rosenberg > Sent: Wednesday, June 06, 2001 3:16 AM > To: 'patrick.mourot@online.fr'; iptel@lists.bell-labs.com > Subject: RE: [IPTEL] lightweight TRIP protocol for gateway > > > > > > > > -----Original Message----- > > From: patrick.mourot@online.fr [mailto:patrick.mourot@online.fr] > > Sent: Friday, June 01, 2001 4:40 AM > > To: iptel@lists.bell-labs.com > > Subject: [IPTEL] lightweight TRIP protocol for gateway > > > > > > Sir, > > > > I would like to know the status of a "lightweight TRIP > > protocol for gateway". > > Any pointers ?? > > The draft has expired some time ago. You can pick up a copy from: > > http://www.jdrosen.net/papers/draft-rs-trip-gw-01.txt > > At IETF 50, we agreed to recharter the iptel working group, > and that one of > the items on that new charter would be the specification of a > protocol from > the gayteways to a server for the purposes of routing calls > over the last > hop. The above work would become the starting point for that > activity. I > have been delinquint in actually submitting the updated charter and in > revising the above draft, but that is the plan. > > -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 > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Jun 12 10:52:05 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17039 for ; Tue, 12 Jun 2001 10:52:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 832644438D; Tue, 12 Jun 2001 10:52:03 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 8166F44336 for ; Tue, 12 Jun 2001 08:05:36 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12234; Tue, 12 Jun 2001 08:05:06 -0400 (EDT) Message-Id: <200106121205.IAA12234@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: iptel@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-07.txt Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 12 Jun 2001 08:05:06 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Telephony Working Group of the IETF. Title : Telephony Routing over IP (TRIP) Author(s) : J. Rosenberg, H. Salama, M. Squire Filename : draft-ietf-iptel-trip-07.txt Pages : 80 Date : 11-Jun-01 This document presents the Telephony Routing over IP (TRIP). TRIP is a policy driven inter-administrative domain protocol for advertising the reachability of telephony destinations between location servers, and for advertising attributes of the routes to those destinations. TRIPÆs operation is independent of any signaling protocol, hence TRIP can serve as the telephony routing protocol for any signaling protocol. The Border Gateway Protocol (BGP-4) is used to distribute routing information between administrative domains. TRIP is used to distribute telephony routing information between telephony administrative domains. The similarity between the two protocols is obvious, and hence TRIP is modeled after BGP-4. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-07.txt 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-iptel-trip-07.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-iptel-trip-07.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: <20010611074615.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-iptel-trip-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-iptel-trip-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010611074615.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Jun 13 10:18:34 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23646 for ; Wed, 13 Jun 2001 10:18:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4A76544337; Wed, 13 Jun 2001 10:19:03 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 79DBB44336 for ; Wed, 13 Jun 2001 10:18:01 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f5DEHvO10338 for ; Wed, 13 Jun 2001 16:18:01 +0200 (MEST) Received: from ericsson.com (E0080C7779971.lmf.ericsson.se [131.160.30.82]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f5DEHvE08987 for ; Wed, 13 Jun 2001 17:17:57 +0300 (EET DST) Message-ID: <3B277612.23C76E4E@ericsson.com> From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: es,en MIME-Version: 1.0 To: iptel@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [IPTEL] KEEPALIVE in draft-ietf-iptel-trip-07.txt Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 13 Jun 2001 17:17:54 +0300 Content-Transfer-Encoding: 7bit Hi: I am trying to understand the TRIP FSM (Appendix 1) in the TRIP draft. Particularly, I have a doubt concerning the Established state (6). It is clear to me that when the KeepAlive timer expires (action 9), a KeepAlive message is sent the KeepAlive timer is restarted. Fine. However, the FSM says that when a KeepAlive message is received (action 11), the Hold Timer is restarted and a KeepAlive message is sent. Therefore, I understand that the reception of a KeepAlive will generate another KeepAlive as a response. At the other end, the reception of that KeepAlive will generate a new one, and so on. And we will have to TRIP implementations in a loop of infinite KeepAlive messages. On the contrary, the corresponding text in section 9 doesn't make any reference to send another KeepAlive message (just restart the Hold Timer). Am I missing something or is there an error in the spec? Regards, Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Jun 13 15:17:34 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29774 for ; Wed, 13 Jun 2001 15:17:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EC54444339; Wed, 13 Jun 2001 15:18:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by lists.bell-labs.com (Postfix) with ESMTP id C433644337 for ; Wed, 13 Jun 2001 15:17:52 -0400 (EDT) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5DJHwU04733; Wed, 13 Jun 2001 12:17:58 -0700 (PDT) Received: from cisco.com (manjax-ultra5.cisco.com [128.107.138.93]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AFC08769 (AUTH manjax); Wed, 13 Jun 2001 12:17:44 -0700 (PDT) Message-ID: <3B27BC57.B8E80B47@cisco.com> From: Manjunath Bangalore Organization: Cisco Systems Inc., San Jose, CA X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Miguel A. Garcia" Cc: iptel@lists.bell-labs.com Subject: Re: [IPTEL] KEEPALIVE in draft-ietf-iptel-trip-07.txt References: <3B277612.23C76E4E@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 13 Jun 2001 12:17:43 -0700 Content-Transfer-Encoding: 7bit Miguel, I think this is an error in the spec. In the FSM table, the "Message Sent" column for action "Receive KEEPALIVE MESSAGE (11)" in Established state (6) should be changed to "none". regards, -Manjax "Miguel A. Garcia" wrote: > Hi: > > I am trying to understand the TRIP FSM (Appendix 1) in the TRIP draft. > > Particularly, I have a doubt concerning the Established state (6). > > It is clear to me that when the KeepAlive timer expires (action 9), a > KeepAlive message is sent the KeepAlive timer is restarted. Fine. > > However, the FSM says that when a KeepAlive message is received (action 11), > the Hold Timer is restarted and a KeepAlive message is sent. > > Therefore, I understand that the reception of a KeepAlive will generate > another KeepAlive as a response. At the other end, the reception of that > KeepAlive will generate a new one, and so on. And we will have to TRIP > implementations in a loop of infinite KeepAlive messages. > > On the contrary, the corresponding text in section 9 doesn't make any reference > to send another KeepAlive message (just restart the Hold Timer). > > Am I missing something or is there an error in the spec? > > Regards, > > Miguel > > -- > Miguel-Angel Garcia Oy LM Ericsson AB > Jorvas, Finland > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Jun 14 21:57:33 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13735 for ; Thu, 14 Jun 2001 21:57:33 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CBFDF44337; Thu, 14 Jun 2001 21:58:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id D3DC044336 for ; Thu, 14 Jun 2001 21:57:14 -0400 (EDT) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5F1vE925004; Thu, 14 Jun 2001 18:57:14 -0700 (PDT) Received: from cisco.com (dhcp-128-107-142-43.cisco.com [128.107.142.43]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AFK00277 (AUTH hsalama); Thu, 14 Jun 2001 18:57:13 -0700 (PDT) Message-ID: <3B296B72.327ACBB@cisco.com> From: "Hussein F. Salama" X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Miguel A. Garcia" Cc: iptel@lists.bell-labs.com Subject: Re: [IPTEL] KEEPALIVE in draft-ietf-iptel-trip-07.txt References: <3B277612.23C76E4E@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 14 Jun 2001 18:57:06 -0700 Content-Transfer-Encoding: 7bit "Miguel A. Garcia" wrote: > Hi: > > I am trying to understand the TRIP FSM (Appendix 1) in the TRIP draft. > > Particularly, I have a doubt concerning the Established state (6). > > It is clear to me that when the KeepAlive timer expires (action 9), a > KeepAlive message is sent the KeepAlive timer is restarted. Fine. > > However, the FSM says that when a KeepAlive message is received (action 11), > the Hold Timer is restarted and a KeepAlive message is sent. > > Therefore, I understand that the reception of a KeepAlive will generate > another KeepAlive as a response. At the other end, the reception of that > KeepAlive will generate a new one, and so on. And we will have to TRIP > implementations in a loop of infinite KeepAlive messages. > > On the contrary, the corresponding text in section 9 doesn't make any reference > to send another KeepAlive message (just restart the Hold Timer). > > Am I missing something or is there an error in the spec? It's an error in the appendix. The correct table entry should be: 11 Restart Hold Timer none 6 Thanks. Hussein > > Regards, > > Miguel > > -- > Miguel-Angel Garcia Oy LM Ericsson AB > Jorvas, Finland > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel -- Hussein F. Salama Cisco Systems Mail Stop SJC-21/3, 170 W. Tasman Drive, San Jose, CA 95134 Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Jun 18 13:44:34 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14597 for ; Mon, 18 Jun 2001 13:44:33 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 594CB44337; Mon, 18 Jun 2001 13:45:03 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from web13905.mail.yahoo.com (web13905.mail.yahoo.com [216.136.175.68]) by lists.bell-labs.com (Postfix) with SMTP id A3C6A44336 for ; Mon, 18 Jun 2001 13:44:17 -0400 (EDT) Message-ID: <20010618174414.84112.qmail@web13905.mail.yahoo.com> Received: from [63.84.167.14] by web13905.mail.yahoo.com; Mon, 18 Jun 2001 10:44:14 PDT From: Gustaf Lawson To: iptel@lists.bell-labs.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1681692777-992886254=:83362" Subject: [IPTEL] Status of CPL draft (draft-ietf-iptel-cpl) Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 18 Jun 2001 10:44:14 -0700 (PDT) --0-1681692777-992886254=:83362 Content-Type: text/plain; charset=us-ascii The CPL draft currently on the IETF site expired May, 2001 (http://www.ietf.org/internet-drafts/draft-ietf-iptel-cpl-04.txt). What is the future of CPL? Gustaf Lawson --------------------------------- Do You Yahoo!? Yahoo! Buzz Index - Spot the hottest trends in music, movies,and more. --0-1681692777-992886254=:83362 Content-Type: text/html; charset=us-ascii The CPL draft currently on the IETF site expired May, 2001 (http://www.ietf.org/internet-drafts/draft-ietf-iptel-cpl-04.txt). What is the future of CPL?

Gustaf Lawson


Do You Yahoo!?
Yahoo! Buzz Index - Spot the hottest trends in music, movies, and more. --0-1681692777-992886254=:83362-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Jun 18 13:55:32 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14868 for ; Mon, 18 Jun 2001 13:55:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0DBCD4434A; Mon, 18 Jun 2001 13:56:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 1590344336 for ; Mon, 18 Jun 2001 13:55:16 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA10709; Mon, 18 Jun 2001 13:59:15 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Jun 2001 13:55:11 -0400 Message-ID: From: Jonathan Rosenberg To: "'Gustaf Lawson'" , iptel@lists.bell-labs.com Subject: RE: [IPTEL] Status of CPL draft (draft-ietf-iptel-cpl) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 18 Jun 2001 13:55:05 -0400 CPL was submitted for IESG review some time back. The IESG had concerns about use of a subset of the iCalendar specification, and asked that the iptel and calsch groups get together and hammer it out. That has been happening, with active debates right now on the calsch list. Once its sorted out, the resulting decision will be reflected in a new version of the draft, which will then be considered further by IESG for RFC status. -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 -----Original Message----- From: Gustaf Lawson [mailto:guslawson@yahoo.com] Sent: Monday, June 18, 2001 1:44 PM To: iptel@lists.bell-labs.com Subject: [IPTEL] Status of CPL draft (draft-ietf-iptel-cpl) The CPL draft currently on the IETF site expired May, 2001 (http://www.ietf.org/internet-drafts/draft-ietf-iptel-cpl-04.txt). What is the future of CPL? Gustaf Lawson Do You Yahoo!? Yahoo! Buzz Index - Spot the hottest trends in music, movies, and more. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Jun 25 15:34:27 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25036 for ; Mon, 25 Jun 2001 15:34:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3864D44349; Mon, 25 Jun 2001 15:35:03 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by lists.bell-labs.com (Postfix) with ESMTP id AB6D944341 for ; Mon, 25 Jun 2001 15:34:16 -0400 (EDT) Received: from fokus.gmd.de (fesarius [193.175.132.142]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id VAA06498 for ; Mon, 25 Jun 2001 21:34:16 +0200 (MET DST) Message-ID: <3B3791FC.B9681C0D@fokus.gmd.de> From: Bogdan - Andrei IANCU X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: iptel@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [IPTEL] Multiple nodes in CPL Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 25 Jun 2001 21:33:16 +0200 Content-Transfer-Encoding: 7bit Is it allowed for a node (excepting the switches, proxy and lookup) to have more than one child nodes? For example, in a sub-action tag can you put a mail and reject (in this order) node on the same row? . . I raise this problem because in the CPL draft, for some nodes it is not specified anything about the output or the following node. For other nodes, like reject, mail, log there is said that they have no output, but other nodes can follow. From this I can conclude that is possible to have more than one node in a row, but the question remains: for which nodes is it allowed (there are in the draft nodes without any comment about)? _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Jun 25 23:30:25 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA05791 for ; Mon, 25 Jun 2001 23:30:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1195244355; Mon, 25 Jun 2001 23:31:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 01CE744353 for ; Mon, 25 Jun 2001 23:30:30 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA28603; Mon, 25 Jun 2001 23:34:36 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 23:30:29 -0400 Message-ID: From: Jonathan Rosenberg To: "'Bogdan - Andrei IANCU'" , iptel@lists.bell-labs.com Subject: RE: [IPTEL] Multiple nodes in CPL MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 25 Jun 2001 23:30:26 -0400 > -----Original Message----- > From: Bogdan - Andrei IANCU [mailto:iancu@fokus.gmd.de] > Sent: Monday, June 25, 2001 3:33 PM > To: iptel@lists.bell-labs.com > Subject: [IPTEL] Multiple nodes in CPL > > > Is it allowed for a node (excepting the switches, proxy and lookup) to > have more than one child nodes? No. > For example, in a sub-action tag can you put a mail and > reject (in this > order) node on the same row? > . > . > > > > No. It would be like: > > I raise this problem because in the CPL draft, for some nodes > it is not > specified anything about the output or the following node. For other > nodes, like reject, mail, log there is said that they have no output, > but other nodes can follow. From this I can conclude that is > possible to > have more than one node in a row, but the question remains: for which > nodes is it allowed (there are in the draft nodes without any comment > about)? No; "follow" here means a subtag relationship. -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 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel