From owner-iptel-outgoing@lists.research.bell-labs.com Tue Jun 1 11:31:48 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01237 for ; Tue, 1 Jun 1999 11:31:48 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 7A89952D5; Tue, 1 Jun 1999 11:27:19 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C99AA52DF; Tue, 1 Jun 1999 11:27:18 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com From: Pat.Calhoun@Eng.Sun.COM (Patrice Calhoun) Message-Id: <199906011526.IAA09246@hsmpka.eng.sun.com> Date: Tue, 1 Jun 1999 08:18:02 -0700 To: "Jonathan Rosenberg" , "Pascal Merle" Cc: "Scott Bradner" , Reply-To: Subject: Re: iptel trademark X-Mailer: Sun NetMail 2.2.5 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit If this is true, the AAA WG is in for a world of trouble :) PatC >Pascal Merle wrote: >> >> Hi! >> >> Did anybody register "iptel" as a trademark for the standards >> developed by the working group? > >I have not. To my knowledge, IETF is not in the business of registering >trademarks on its working group names. I'm not sure what would happen if >some other group claims that a working group name violates their >trademark. I'm not sure it matters - since the working group names don't >appear on the final RFC's, but I'm not at all sure. > >-Jonathan R. > >-- >Jonathan D. Rosenberg Lucent Technologies >Member of Technical Staff 101 Crawfords Corner Rd. >High Speed Networks Research Holmdel, NJ 07733 >FAX: (732) 834-5379 Rm. 4C-526 >EMAIL: jdrosen@bell-labs.com >URL: http://www.cs.columbia.edu/~jdrosen > >--------- >This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Jun 1 11:42:38 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01440 for ; Tue, 1 Jun 1999 11:42:38 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 33E4D52BB; Tue, 1 Jun 1999 10:36:52 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 990B052D5; Tue, 1 Jun 1999 10:36:51 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <3753ECAA.BF3A130B@dnrc.bell-labs.com> Date: Tue, 01 Jun 1999 10:22:34 -0400 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Pascal Merle Cc: iptel@lists.research.bell-labs.com, Scott Bradner Subject: Re: iptel trademark References: <37531225.6DD9@iptel.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Pascal Merle wrote: > > Hi! > > Did anybody register "iptel" as a trademark for the standards > developed by the working group? I have not. To my knowledge, IETF is not in the business of registering trademarks on its working group names. I'm not sure what would happen if some other group claims that a working group name violates their trademark. I'm not sure it matters - since the working group names don't appear on the final RFC's, but I'm not at all sure. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Jun 1 23:33:26 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11290 for ; Tue, 1 Jun 1999 23:33:26 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 146CB52BB; Tue, 1 Jun 1999 23:27:18 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 76CF052D5; Tue, 1 Jun 1999 23:27:17 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <3.0.6.32.19990604101615.0082c1e0@pop3.access.net.id> X-Sender: teddyap@pop3.access.net.id X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Fri, 04 Jun 1999 10:16:15 +0700 To: , "Jonathan Rosenberg" , "Pascal Merle" From: "Teddy A. Purwadi" Subject: Re: iptel trademark Cc: "Scott Bradner" , In-Reply-To: <199906011526.IAA09246@hsmpka.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Gee, all is on going commrecially debut outside. -teddy At 08:18 01/06/99 -0700, Patrice Calhoun wrote: >If this is true, the AAA WG is in for a world of trouble :) > >PatC >>Pascal Merle wrote: >>> >>> Hi! >>> >>> Did anybody register "iptel" as a trademark for the standards >>> developed by the working group? >> >>I have not. To my knowledge, IETF is not in the business of registering >>trademarks on its working group names. I'm not sure what would happen if >>some other group claims that a working group name violates their >>trademark. I'm not sure it matters - since the working group names don't >>appear on the final RFC's, but I'm not at all sure. >> >>-Jonathan R. >> >>-- >>Jonathan D. Rosenberg Lucent Technologies >>Member of Technical Staff 101 Crawfords Corner Rd. >>High Speed Networks Research Holmdel, NJ 07733 >>FAX: (732) 834-5379 Rm. 4C-526 >>EMAIL: jdrosen@bell-labs.com >>URL: http://www.cs.columbia.edu/~jdrosen >> >>--------- >>This message came from the IETF IPTEL Working Group Mailing List. > > > >--------- >This message came from the IETF IPTEL Working Group Mailing List. > > PT MAHATEL-APJII [JOO] Grha Citra Caraka, Mezzanine Fl., Jln Gatot Subroto 52, Jakarta 12710 - INDONESIA V:+62-21 526 8777 F:+62-21 526 8789 E:policy@iix.net.id I:http://www.iix.net.id --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Jun 2 18:03:01 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11559 for ; Wed, 2 Jun 1999 18:03:00 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id A8E8452B6; Wed, 2 Jun 1999 17:57:19 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 19D6052DD; Wed, 2 Jun 1999 17:57:19 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <3755A84D.50A06FC6@warpspeed.net> Date: Wed, 02 Jun 1999 14:55:25 -0700 From: Rick Cobb Reply-To: rec@warpspeed.net X-Mailer: Mozilla 4.07 [en] (Win95; U) MIME-Version: 1.0 To: "u059640@site.uottawa.ca" Cc: "'Colin Perkins'" , Venkata Narasimha Murthy Nanduri , "iptel@lists.research.bell-labs.com" Subject: Re: Reg. Real time Transport Protocol References: <01BEAD1B.E0A3B560.u059640@site.uottawa.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Sure. As I recall, that's the case for all the video formats, particularly H.261, since an encoded macro block can be variable length and a packet must start and end on macro-block boundaries. -- ReC Stanley Feng wrote: > > I have a question: > For each payload type in RTP, there is a static mapping to a payload > format, is it possible the payload size is variable for some payload > format? > > Thank you in advance. > > Stanley Feng > > --------- > This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Jun 2 18:23:31 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11774 for ; Wed, 2 Jun 1999 18:23:31 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 66F0E52DD; Wed, 2 Jun 1999 18:17:18 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D12B452E0; Wed, 2 Jun 1999 18:17:17 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com To: rec@warpspeed.net Cc: "u059640@site.uottawa.ca" , Venkata Narasimha Murthy Nanduri , "iptel@lists.research.bell-labs.com" Subject: Re: Reg. Real time Transport Protocol In-reply-to: Your message of "Wed, 02 Jun 1999 14:55:25 PDT." <3755A84D.50A06FC6@warpspeed.net> Date: Wed, 02 Jun 1999 23:15:35 +0100 Message-ID: <11031.928361735@cs.ucl.ac.uk> From: Colin Perkins Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk --> Rick Cobb writes: >Sure. As I recall, that's the case for all the video formats, >particularly H.261, since an encoded macro block can be variable >length and a packet must start and end on macro-block boundaries. And for some audio formats too, such as VDVI and all the sample based codecs. >Stanley Feng wrote: >> >> I have a question: >> For each payload type in RTP, there is a static mapping to a payload >> format, is it possible the payload size is variable for some payload >> format? Remember also that the mapping is not always static, with control protocols such as SIP signalling dynamic mappings. Colin --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Jun 2 18:32:19 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11887 for ; Wed, 2 Jun 1999 18:32:19 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 9913F52E3; Wed, 2 Jun 1999 18:25:02 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 61B3552E4; Wed, 2 Jun 1999 18:25:01 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <3755AF71.C85A86E5@cs.columbia.edu> Date: Wed, 02 Jun 1999 18:25:53 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: Colin Perkins Cc: rec@warpspeed.net, "u059640@site.uottawa.ca" , Venkata Narasimha Murthy Nanduri , "iptel@lists.research.bell-labs.com" Subject: Re: Reg. Real time Transport Protocol References: <11031.928361735@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Colin Perkins wrote: > > --> Rick Cobb writes: > >Sure. As I recall, that's the case for all the video formats, > >particularly H.261, since an encoded macro block can be variable > >length and a packet must start and end on macro-block boundaries. > > And for some audio formats too, such as VDVI and all the sample based > codecs. > > >Stanley Feng wrote: > >> > >> I have a question: > >> For each payload type in RTP, there is a static mapping to a payload > >> format, is it possible the payload size is variable for some payload > >> format? > > Remember also that the mapping is not always static, with control protocols > such as SIP signalling dynamic mappings. Plus, for frame-based codecs, the number of frames per packet may vary from call to call and within a call, unless it is declared via ptime in SDP, This discussion, however, belongs on the rem-conf list, not here. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Jun 2 21:18:52 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13019 for ; Wed, 2 Jun 1999 21:18:51 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 8DDF352BB; Wed, 2 Jun 1999 17:15:19 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id EAE8452D5; Wed, 2 Jun 1999 17:15:18 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <01BEAD1B.E0A3B560.u059640@site.uottawa.ca> From: Stanley Feng Reply-To: "u059640@site.uottawa.ca" To: "'Colin Perkins'" , Venkata Narasimha Murthy Nanduri Cc: "iptel@lists.research.bell-labs.com" Subject: Reg. Real time Transport Protocol Date: Wed, 2 Jun 1999 17:18:04 -0400 Organization: SITE X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit I have a question: For each payload type in RTP, there is a static mapping to a payload format, is it possible the payload size is variable for some payload format? Thank you in advance. Stanley Feng --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Jun 4 08:12:14 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04164 for ; Fri, 4 Jun 1999 08:12:13 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 9394D52D5; Fri, 4 Jun 1999 08:05:21 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id DC06152DD; Fri, 4 Jun 1999 08:05:20 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <19990604121045.6477.rocketmail@web121.yahoomail.com> Date: Fri, 4 Jun 1999 05:10:45 -0700 (PDT) From: Tom Gray Subject: Re: iptel trademark To: iptel@lists.research.bell-labs.com, tom_gray_intp@yahoo.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk There was the example of the dispute between Carl Sagan and Apple over the use of his name as an internal project name. Sagan was able to force Apple to rename the project. --- "Teddy A. Purwadi" wrote: > Gee, all is on going commrecially debut outside. > > -teddy > > At 08:18 01/06/99 -0700, Patrice Calhoun wrote: > >If this is true, the AAA WG is in for a world of > trouble :) > > > >PatC > >>Pascal Merle wrote: > >>> > >>> Hi! > >>> > >>> Did anybody register "iptel" as a trademark for > the standards > >>> developed by the working group? > >> > >>I have not. To my knowledge, IETF is not in the > business of registering > >>trademarks on its working group names. I'm not > sure what would happen if > >>some other group claims that a working group name > violates their > >>trademark. I'm not sure it matters - since the > working group names don't > >>appear on the final RFC's, but I'm not at all > sure. > >> > >>-Jonathan R. > >> > >>-- > >>Jonathan D. Rosenberg Lucent > Technologies > >>Member of Technical Staff 101 > Crawfords Corner Rd. > >>High Speed Networks Research > Holmdel, NJ 07733 > >>FAX: (732) 834-5379 Rm. > 4C-526 > >>EMAIL: jdrosen@bell-labs.com > >>URL: http://www.cs.columbia.edu/~jdrosen > >> > >>--------- > >>This message came from the IETF IPTEL Working > Group Mailing List. > > > > > > > >--------- > >This message came from the IETF IPTEL Working Group > Mailing List. > > > > > PT MAHATEL-APJII [JOO] > Grha Citra Caraka, Mezzanine Fl., > Jln Gatot Subroto 52, > Jakarta 12710 - INDONESIA > V:+62-21 526 8777 > F:+62-21 526 8789 > E:policy@iix.net.id > I:http://www.iix.net.id > > > > --------- > This message came from the IETF IPTEL Working Group > Mailing List. > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Jun 4 09:10:12 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04878 for ; Fri, 4 Jun 1999 09:10:12 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 447FB52BB; Fri, 4 Jun 1999 07:55:18 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9966052D5; Fri, 4 Jun 1999 07:55:17 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <19990604120049.5550.rocketmail@web121.yahoomail.com> Date: Fri, 4 Jun 1999 05:00:49 -0700 (PDT) From: Tom Gray Subject: Re: CPL Features To: iptel@lists.research.bell-labs.com, Jonathan Rosenberg Cc: Tom_gray_grc@yahoo.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk --- Jonathan Rosenberg wrote: > Tom Gray wrote: > > > > --- Jonathan Rosenberg > > > > > > It would also be helpful if you could point out > > > particular features you > > > feel are useful yet not supported by CPL. > > > > > > > The CPL documents describe features like Call > Forward Busy, Call > > Forward No Answer and the refusal of anonymous > calls. These certainly > > are features that have meaning only if the user is > present. > > Call forward no answer only takes place when the > user is *not* present. I was thinking of the case when the user is present but is preoccupied by more important business such as a visitor. He can glance at the call display and know that it is a colleague who he can contact later and so lets the call go to voice mail. It still looks to me as if CPL is being used when the user is present. > > > Additionally a useful feature to have is the > ability to set an > > automatic call back on a user who is not > registered or present and > > another is to camp on to a busy line (ie queue > till the user becomes > > free. > > The first one (callback) is not one I think CPL is > good at doing. The > problem is that in the callback case, the called > party calls back the > calling party when available. This is easily done in > a user agent > (assuming it has access to call logs when it logs > in), but harder in a > SIP server since the SIP server doesn't usually > initiate calls or > maintain call state. None of the features we're > targeting for CPLv1 > require call state or having the server initiate > calls, bridge calls, > etc. > > The second service is not something I think that we > would do in the > first version (it requires call state in the SIP > server), but possibly a > later one. In that case, the CPL might look > something like: > > > > > > > > > > > > and for forwarding: > > > > url="sip:forwarded-location@company.com"> > > > > > > So, if the called party specifies the service ala > CPL, there would be no > feature interaction between forwarding and camp-on > since they CANNOT > represent both at the same time in the same place in > CPL. > > Interactions do arise if the called party specifies > one of them (say > camp-on on busy) and the calling party tries to > specify a different one > (forward on busy). This is not strictly a CPL issue, > since somehow there > is here a way for the caller to ask for this feature > for this call (the > caller preferences document is the general mechanism > for this). In that > document, we mention that there is this generally > hard interaction > problem. I don't have an easy answer for how its > done, nor do I think > there is one right way. > I will try to emphasize a point that I see as fundamental. Feature Interaction is a **good** thing. Advanced services are created by the judicious interworking of existing services. The feature interaction problem is not about preventing interactions but creating systems in which features can interact without, among other things, creating indeterministic behavior and user confusion. Feature interaction management is therefore central to any form of call processing and is not something that can be handled casually. Indeed one of the main advantages of an Internet based telephony system is that it provides us with new and practical means of handling feature interaction so that the operation of features can be managed in much more subtle and useful ways than were possible in the old PSTN systems. To this point, it is a good thing that call back, camp on and call forwardings interact. This is an example of interaction that provides the basis for creating systems which can function to the best interests of the callers at the time of the call. To put it rather grandly, the features can adapt to the users' interests. having a system which simply prevents them from interacting is creating a system that by this fact is much less useful to the users. The example of the interaction between Call Back, Camp On (queuing) and CF Busy is apposite here. It is something that has to be resolved at run time given the knowledge of how the system is operating. Preference tables, at least as I see them operating, cannot do this. Every call is different. Feature interaction management is the central feature of any call processing system. It must be given the central place in the architecture of the system. If this is not done the system created will not be able to provide enough feature management to be useful to a real user and/or not be able to evolve with the addition of new features. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Sat Jun 5 12:33:49 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03178 for ; Sat, 5 Jun 1999 12:33:49 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 852B852D5; Sat, 5 Jun 1999 12:27:35 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id DD1F852DB; Sat, 5 Jun 1999 12:27:34 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <37595009.375AFBE9@dnrc.bell-labs.com> Date: Sat, 05 Jun 1999 12:27:53 -0400 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: list iptel Subject: iptel meeting time Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Folks, > IPTEL is tentatively scheduled as follows: > > Thursday, July 15 at 1300-1500 > other groups scheduled at that time: ldapext, saag, mobileip > > If people have specific agenda items, let me know. Otherwise, I'll be sending out a note in the next few days summarizing where I think we are, and where we need to be going, in preparation for the meeting. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Sat Jun 5 18:41:14 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05860 for ; Sat, 5 Jun 1999 18:41:14 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 413D552DC; Sat, 5 Jun 1999 18:35:27 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 95B9752DB; Sat, 5 Jun 1999 18:35:26 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com From: "Russo S.A" To: Lista de destinatarios oculta Date: Sat, 05 Jun 1999 19:06:13 -0300 Subject: De su interes . Bajar costos X-Mailer: MultiMailer MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <22064404412479@houseware.com.ar> Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 8bit 1-Ahora vas a poder navegar por Internet y seguir comunicado por teléfono si estas en el area de telefónica. El precio es super $ 50 más I.V.A y si te conectas a través del 0610, el costo de navegación esde solo $ 0,36 más I.V.A LA HORA. 2-Si querés optimizar tus recursos para navegar en Internet, tenemos de acuerdo a tú necesidad distintos planes de tú utilidad. 3-Nuestra empresa te brinda las soluciones para tú companía abaratando tus costos, llamanos sin ningún compromiso, que estamos a tú disposición. 4-Somos una empresa de distribución en telefonia célular más grande del país.Con una experiencia de casi 30 años en nuestra actividad. 5-Nuestra firma es consultora homologada por teléfonica de argentina y representamos a empresas de primer nivel en el rubro telecomunicaciones. 6-Consultenos...por accesorios y teléfonos celulares, centrales telefonicas, redes de voz y datos. Nuestros telefonos sin cargo televenta 0800-999-8-999 Nuestros locales en www.russo-sa.com.ar email info@russo-sa.com.ar --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Jun 8 03:58:55 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21546 for ; Tue, 8 Jun 1999 03:58:55 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id DD82552D5; Tue, 8 Jun 1999 02:45:19 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 5068952DB; Tue, 8 Jun 1999 02:45:18 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <375CBBA6.661709C0@divnet.telkom.co.id> Date: Tue, 08 Jun 1999 13:43:50 +0700 From: den_BAGUSE X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: iptel@lists.research.bell-labs.com Subject: (no subject) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Jun 8 05:13:15 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22266 for ; Tue, 8 Jun 1999 05:13:15 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 2595252DE; Tue, 8 Jun 1999 04:57:32 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D3EB352DB; Tue, 8 Jun 1999 04:57:26 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Date: Tue, 08 Jun 1999 11:53:20 +0300 From: Khaled Elsayed Subject: IEEE Communications Magazine: Call for Papers To: khaled@ieee.org, Laurent.Toutain@enst-bretagne.fr Message-id: <375CDA00.2987C112@ie-eg.com> MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en] (Win95; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Call for Papers IEEE Communications Magazine Internet Technology Series Series Editors Laurent Toutain (ENST Bretagne) and Khaled Elsayed (Cairo University) The IEEE Communications Magazine invites contributions from authors with academic and industrial affiliation for the Internet Technology Series. The Focus of the Internet Technology Series is to bring the latest advances in state of the art techniques in the Internet to the large readers group of the Communications Magazine. Preference will be given to papers addressing technical issues that are encountered in implementing current or future Internet products or solutions. We are currently looking for articles in the following areas: - Web Caching (centralized and distributed) - Internet Telephony, VoIP, SS7 Gateways - DiffServ Model and Implementations - MPLS Deadline for submission: August 1, 1999. ======================= The coming issue of the Internet Technology Series is scheduled for January 2000 (an extremely attractive date, isn't it?). In order for us and the editorial office to process the review process and afterwards the accepted papers, you must submit your paper by the above deadline. However, we will continue to process papers all year round for forthcoming issues. Article Style Information ========================= Articles should be tutorial in nature and should be written in a style comprehensible to readers outside the specialty of the article. Articles may be edited for content, and will be copyedited for compliance with the magazine's style guidelines. Page proofs will be sent to the contact author for final review prior to publication. Mathematical equations should not be used unless they are vital to the presentation. Even then, they should be kept to a minimum. If the article has numerous equations, please contact the editor handling the manuscript. References should be included only to guide readers to more information on the topic; the reference list should not include every available source (a limit of ten references is recommended). Use footnotes only where necessary. Articles should not exceed 4500 words. Figures and tables should be limited to a combined total of six. If the article exceeds these recommended limits, please contact the editor handling the manuscript. Also check: http://207.127.135.8/ci1 (author guidelines) and http://207.127.135.8/ci1/public/1998/may/cimess.html Since this is an Internet related series, we would like to handle all the submissions and the reviewing process via the Internet. Please send your submission in postscript or PDF (acrobat) format to the series editors. Khaled Elsayed: Khaled@ieee.org Laurent Toutain: Laurent.Toutain@enst-bretagne.fr --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Jun 8 10:13:45 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25945 for ; Tue, 8 Jun 1999 10:13:45 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 42CFD52BB; Tue, 8 Jun 1999 10:07:21 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id ADDEA52DD; Tue, 8 Jun 1999 10:07:20 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <375D245A.109BD831@site.uottawa.ca> Date: Tue, 08 Jun 1999 10:10:34 -0400 From: Stanley Feng X-Mailer: Mozilla 4.05 [en] (WinNT; I) MIME-Version: 1.0 To: Colin Perkins Cc: Venkata Narasimha Murthy Nanduri , iptel@lists.research.bell-labs.com Subject: Re: Reg. Real time Transport Protocol References: <798.927713830@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Forgive me if my questions are silly. Colin Perkins wrote: > --> Venkata Narasimha Murthy Nanduri writes: > >1) How can we know whether an RTP packet is encapsulated in the UDP data > >field? > > The RTP spec contains code to validate a packet, to ensure that it is RTP > data. > So if I want to do some special operation on all the RTP packets, do I have to check the payload of every UDP packet? i.e., even if only 1% of the UDP packets contain RTP packets, I will have to do the checking for all the UDP packets? > >2) If it is based on the UDP port numbers, then are there any standard > >UDP port numbers that will be used for RTP? > > The ports used for RTP traffic are signalled out of band using your > favourite control protocol (SIP, SAP, RTSP, H.whatever, etc...). There > are no standard UDP ports for RTP traffic. > Since we can use control protocol to agree on some port for RTP traffic, I guess we are ok. > Colin > > --------- > This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Jun 8 11:06:24 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27293 for ; Tue, 8 Jun 1999 11:06:24 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 0792052DB; Tue, 8 Jun 1999 11:01:20 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6F14552DF; Tue, 8 Jun 1999 11:01:19 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com To: Stanley Feng Cc: Venkata Narasimha Murthy Nanduri , iptel@lists.research.bell-labs.com Subject: Re: Reg. Real time Transport Protocol In-reply-to: Your message of "Tue, 08 Jun 1999 10:10:34 EDT." <375D245A.109BD831@site.uottawa.ca> Date: Tue, 08 Jun 1999 15:57:01 +0100 Message-ID: <2435.928853821@cs.ucl.ac.uk> From: Colin Perkins Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk --> Stanley Feng writes: >Colin Perkins wrote: >> --> Venkata Narasimha Murthy Nanduri writes: >> >1) How can we know whether an RTP packet is encapsulated in the UDP data >> >field? >> >> The RTP spec contains code to validate a packet, to ensure that it is RTP >> data. > >So if I want to do some special operation on all the RTP packets, do I have >to check the payload of every UDP packet? i.e., even if only 1% of the UDP >packets contain RTP packets, I will have to do the checking for all the UDP >packets? Yes, unless you have used a signalling protocol to decide which ports are used for RTP traffic. >> >2) If it is based on the UDP port numbers, then are there any standard >> >UDP port numbers that will be used for RTP? >> >> The ports used for RTP traffic are signalled out of band using your >> favourite control protocol (SIP, SAP, RTSP, H.whatever, etc...). There >> are no standard UDP ports for RTP traffic. > >Since we can use control protocol to agree on some port for RTP traffic, I >guess we are ok. Right; this is how things normally work. Colin --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Jun 10 03:48:22 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24578 for ; Thu, 10 Jun 1999 03:48:22 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id E74EF52BB; Thu, 10 Jun 1999 03:41:19 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 5AF9252D5; Thu, 10 Jun 1999 03:41:18 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <19990610074037.26848.rocketmail@web108.yahoomail.com> Date: Thu, 10 Jun 1999 00:40:37 -0700 (PDT) From: Tom Gray Subject: Why SS7? To: iptel@lists.research.bell-labs.com, tom_gray_intp@yahoo.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk I see much written in the IP telephony world about SS7 gateways but I have seen little written about the basis of this interest. So I will ask the question. What is the basis of the interest in SS7 as opposed to any the many other signaling schemes (R1, R2, No 5, DPNSS ...)? What advantages does it bring and what are its disadvantages. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Jun 10 03:56:44 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24606 for ; Thu, 10 Jun 1999 03:56:44 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id D29B452DC; Thu, 10 Jun 1999 03:51:19 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3BDC352D5; Thu, 10 Jun 1999 03:51:19 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <009101beb315$bc8572e0$829fc3d0@svnl.com> Reply-To: "Steve Bell" From: "Steve Bell" To: "Tom Gray" , References: <19990610074037.26848.rocketmail@web108.yahoomail.com> Subject: Re: Why SS7? Date: Thu, 10 Jun 1999 00:49:14 -0700 Organization: SVNL MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit > What is the basis of the interest in SS7 as opposed to any the many > other signaling schemes (R1, R2, No 5, DPNSS ...)? Installed base. Steve Bell Pres. & CEO The Silicon Valley Networking Lab, Inc. 2681-A Zanker Road San Jose, CA 95134 Tel: (408) 432-3840 x111 www.svnl.com Sample SVNL test reports at http://www.svnl.com/test_lab_reports.htm Now sponsoring "The ATM Digest" Daily! Visit www.atmdigest.com S V N L T H E I N D U S T R Y ' S T E S T C E N T E R ----- Original Message ----- From: Tom Gray To: ; Sent: Thursday, June 10, 1999 12:40 AM Subject: Why SS7? > > I see much written in the IP telephony world about SS7 gateways but I > have seen little written about the basis of this interest. So I will > ask the question. > > What is the basis of the interest in SS7 as opposed to any the many > other signaling schemes (R1, R2, No 5, DPNSS ...)? > > What advantages does it bring and what are its disadvantages. > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > --------- > This message came from the IETF IPTEL Working Group Mailing List. > > --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Jun 10 05:59:38 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25146 for ; Thu, 10 Jun 1999 05:59:37 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 2114252D5; Thu, 10 Jun 1999 05:53:19 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 88A5852DB; Thu, 10 Jun 1999 05:53:18 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <19990610095449.13179.rocketmail@web120.yahoomail.com> Date: Thu, 10 Jun 1999 02:54:49 -0700 (PDT) From: Tom Gray Subject: Re: Why SS7? To: Steve Bell , iptel@lists.research.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk --- Steve Bell wrote: > > What is the basis of the interest in SS7 as > opposed to any the many > > other signaling schemes (R1, R2, No 5, DPNSS ...)? > > Installed base. > Very little CPE equipment is supplied with SS7. Other protocols are used. I guess my eal question is why calls for papaers include suggestions of SS7 gateways. There must be more to the idea than the connection to the PSTN for conventional services. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Jun 10 06:19:12 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25257 for ; Thu, 10 Jun 1999 06:19:12 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 2DDAC52DD; Thu, 10 Jun 1999 06:13:22 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 956E352DE; Thu, 10 Jun 1999 06:13:21 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <010001beb328$b95a01e0$829fc3d0@svnl.com> Reply-To: "Steve Bell" From: "Steve Bell" To: "Tom Gray" , References: <19990610095449.13179.rocketmail@web120.yahoomail.com> Subject: Re: Why SS7? Date: Thu, 10 Jun 1999 03:05:08 -0700 Organization: SVNL MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Tom, I'm sure what you say about SS7 in CPE is true. It is, however predominant as the signaling protocol between carrier-class TDM voice switches, such at #5ESS - a defacto industry standard. That is what I was referring to, and explains why gateways are needed for VOIP products. Regards, -Steve ----- Original Message ----- From: Tom Gray To: Steve Bell ; Sent: Thursday, June 10, 1999 2:54 AM Subject: Re: Why SS7? > > > --- Steve Bell wrote: > > > What is the basis of the interest in SS7 as > > opposed to any the many > > > other signaling schemes (R1, R2, No 5, DPNSS ...)? > > > > Installed base. > > > > Very little CPE equipment is supplied with SS7. Other protocols are > used. I guess my eal question is why calls for papaers include > suggestions of SS7 gateways. There must be more to the idea than the > connection to the PSTN for conventional services. > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > --------- > This message came from the IETF IPTEL Working Group Mailing List. > > --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Jun 10 07:38:14 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26158 for ; Thu, 10 Jun 1999 07:38:13 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id E7E6852DB; Thu, 10 Jun 1999 07:33:19 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6360952DF; Thu, 10 Jun 1999 07:33:19 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Date: Thu, 10 Jun 1999 06:31:54 -0500 From: Henry Sinnreich Subject: RE: Why SS7? In-reply-to: <19990610095449.13179.rocketmail@web120.yahoomail.com> To: Tom Gray , Steve Bell , iptel@lists.research.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit It is useful to make the distinction between enterprise gateways for PBX's and network gateways for CO switches. The latter require SS7. Thanks, Henry > -----Original Message----- > From: owner-iptel@lists.research.bell-labs.com > [mailto:owner-iptel@lists.research.bell-labs.com]On Behalf Of Tom Gray > Sent: Thursday, June 10, 1999 4:55 AM > To: Steve Bell; iptel@lists.research.bell-labs.com > Subject: Re: Why SS7? > > > > > --- Steve Bell wrote: > > > What is the basis of the interest in SS7 as > > opposed to any the many > > > other signaling schemes (R1, R2, No 5, DPNSS ...)? > > > > Installed base. > > > > Very little CPE equipment is supplied with SS7. Other protocols are > used. I guess my eal question is why calls for papaers include > suggestions of SS7 gateways. There must be more to the idea than the > connection to the PSTN for conventional services. > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > --------- > This message came from the IETF IPTEL Working Group Mailing List. > --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Jun 10 09:13:13 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27552 for ; Thu, 10 Jun 1999 09:13:12 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 1F25452DF; Thu, 10 Jun 1999 09:07:29 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 941BF52E0; Thu, 10 Jun 1999 09:07:28 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com X-Lotus-FromDomain: 3COM From: Mike_S_McCormack@ne.3com.com To: iptel@lists.research.bell-labs.com Message-ID: <8525678C.00456E41.00@usboxmta.ne.3com.com> Date: Thu, 10 Jun 1999 09:06:31 -0400 Subject: IEEE Ethernet Power interest Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk The IEEE is having a call for interest on standardizing a method of powering devices over the same CAT 5 cable that provides data. If anyone is interested, look at: http://grouper.ieee.org/groups/802/3/power_study/public/index.html I am helping to collect information regarding interested parties before the July IEEE meeting, if anyone out there is interested, please contact me directly at mike_s_mccormack@3com.com. Thanks --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Jun 10 09:22:35 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27636 for ; Thu, 10 Jun 1999 09:22:35 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id CB1DB52E6; Thu, 10 Jun 1999 09:13:29 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 4EFF052E4; Thu, 10 Jun 1999 09:13:28 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com X-Lotus-FromDomain: ICN From: Steve.Carr@icn.siemens.com To: Tom Gray Cc: iptel@lists.research.bell-labs.com Message-ID: <8525678C.0048BE22.00@li01.lm.ssc.siemens.com> Date: Thu, 10 Jun 1999 09:11:59 -0400 Subject: Re: Why SS7? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Here is a very quick list: Versus CAS (R1,R2 etc) signaling, SS7 provides the following advantages: a) Much faster call setup time b) supports a greater amount of information transfer between switches (such as calling line id), which enables supplementary services to be supported across the network. c) greater installed base - I have heard that the US trunk network is 90-95% SS7.(dont know the figures for the rest of the world) but has the following disadvantages a) more expensive. In the US, to connect into the RBOC STP can be quite expensive b) the SS7 network operators are very cautious when allowing new service providers to connect to their networks. They require long periods of approval testing. The SS7 network could be susceptible to implementation bugs that could bring the whole network down (such as happened to the ATT SS7 network in the late eighties) Versus ISDN signaling (PRI, DPNSS etc) SS7 has the following advantages: a) Scales better, therefore less expensive. A redundant pair of SS7 links can support the signaling for thousands of trunk circuits. Most PRI implementations are facility associated (I'm not sure how wide is the support for NFAS and how may T1s can be grouped together using NFAS) b) Since PRI is a UNI, it is likely that in most networks, toll switches (Class 4) do not support PRIs, whereas all PSTN switches would support SS7. c) SS7 supports single stage dialing, whereas most switches force PRI into a multi-stage dialing pattern. d) Better routing capabilities. Switches often support more than one trunk route to reach each destination. When routing to a PRI, the switch thinks it is trying to reach a subscriber on a PBX. If all the PRI circuits are busy, then it isn't likely to have an alternate route to get to that subscriber. e) SS7 has better congestion control procedures than PRI. Steve Carr Unisphere Solutions Inc. Tom Gray on 06/10/99 03:40:37 AM To: iptel@lists.research.bell-labs.com, tom_gray_intp@yahoo.com cc: (bcc: Steve Carr/Internet/ICN) Subject: Why SS7? I see much written in the IP telephony world about SS7 gateways but I have seen little written about the basis of this interest. So I will ask the question. What is the basis of the interest in SS7 as opposed to any the many other signaling schemes (R1, R2, No 5, DPNSS ...)? What advantages does it bring and what are its disadvantages. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com --------- This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Jun 10 13:14:27 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01856 for ; Thu, 10 Jun 1999 13:14:26 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 2C6E752E0; Thu, 10 Jun 1999 13:09:18 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 913E552E2; Thu, 10 Jun 1999 13:09:17 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <3.0.6.32.19990611000858.0081c730@pop3.access.net.id> X-Sender: teddyap@pop3.access.net.id X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Fri, 11 Jun 1999 00:08:58 +0700 To: Jonathan Rosenberg , list iptel From: "Teddy A. Purwadi" Subject: Re: Framework Document In-Reply-To: <375FE12C.D54F0190@dnrc.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk At 12:00 10/06/99 -0400, Jonathan Rosenberg wrote: >Folks, > >I have just submitted an updated version of the GLP framework document >to the archives. Until it appears, you can find a copy at: > >http://www.bell-labs.com/mailing-lists/iptel/draft-ietf-iptel-gwloc-framewo rk-03.txt > >The main changes are: > >* lots more explanatory text on the problem definition and motivation >* discussion of 800 number translation and how it relates to GLP >* comparison with BGP expanded >* applications section that gives example configurations >* some new terminology (like GIB for Gateway Information Base) > >The architecture itself is unchanged, but I think this version is much >clearer. This is informative; I think I should check ITMC-ITU progress related to GLP FW discussion. >As such, I also believe we are ready for a working group last call on >this document. Once the document appears in the archives, we will enter >a two week last call period. Feel free to send comments to either the >authors or to the list. Any comments will be folded in to one more rev, >and then this will go to IESG if the comments are not substantial enough >to warrant another working group last call. If there are no comments at >all, version -03 will go to IESG. > >Note that the framework document will be an informational RFC. > >So, take this is a warning: send comments NOW or forever hold your >peace. Yes, I have to compare this draft with others ref. brgds, -teddy >Thanks, >Jonathan R. > >-- >Jonathan D. Rosenberg Lucent Technologies >Member of Technical Staff 101 Crawfords Corner Rd. >High Speed Networks Research Holmdel, NJ 07733 >FAX: (732) 834-5379 Rm. 4C-526 >EMAIL: jdrosen@bell-labs.com >URL: http://www.cs.columbia.edu/~jdrosen > >--------- >This message came from the IETF IPTEL Working Group Mailing List. > > PT MAHATEL - APJII [JOO] Grha Citra Caraka, M. Fl., Gatot Subroto 52, Jakarta 12710-INDONESIA I:http://www.iix.net.id V:+62-21 526 8777 F:+62-21 526 8789 --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Jun 10 13:26:22 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02031 for ; Thu, 10 Jun 1999 13:26:22 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 6369852E9; Thu, 10 Jun 1999 13:15:33 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A56C552E8; Thu, 10 Jun 1999 13:15:32 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <973A27B9A872D211B64D0000C041FDED0165B857@njd580po01.bns.att.com> From: "Butz, John J, NTCOM" To: "'Steve.Carr@icn.siemens.com'" Cc: iptel@lists.research.bell-labs.com Subject: RE: Why SS7? Date: Thu, 10 Jun 1999 12:11:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk > -----Original Message----- > From: Steve.Carr@icn.siemens.com [mailto:Steve.Carr@icn.siemens.com] > Sent: Thursday, June 10, 1999 9:12 AM > To: Tom Gray > Cc: iptel@lists.research.bell-labs.com > Subject: Re: Why SS7? > > > Here is a very quick list: > > Versus CAS (R1,R2 etc) signaling, SS7 provides the following > advantages: > a) Much faster call setup time > b) supports a greater amount of information transfer between > switches (such as calling line id), which enables supplementary services to be > supported across the network. > c) greater installed base - I have heard that the US trunk > network is 90-95% SS7.(dont know the figures for the rest of the world) > > but has the following disadvantages > a) more expensive. In the US, to connect into the RBOC STP > can be quite expensive [JButz] Yes ...More expensive per port and more expensive to interconnect... but because of the volume of calls that an SS7 enabled VoIP system can handle, the net unit cost per call for a service provider drops.... your mileage may vary, traffic engineering required to find cross over points.... > b) the SS7 network operators are very cautious when allowing > new service > providers to connect to their networks. They require long > periods of approval > testing. The SS7 network could be susceptible to > implementation bugs that could > bring the whole network down (such as happened to the ATT SS7 > network in the > late eighties) > > Versus ISDN signaling (PRI, DPNSS etc) SS7 has the following > advantages: > a) Scales better, therefore less expensive. A redundant pair > of SS7 links can > support the signaling for thousands of trunk circuits. Most > PRI implementations > are facility associated (I'm not sure how wide is the support > for NFAS and how > may T1s can be grouped together using NFAS) > b) Since PRI is a UNI, it is likely that in most networks, > toll switches (Class > 4) do not support PRIs, whereas all PSTN switches would support SS7. > c) SS7 supports single stage dialing, whereas most switches > force PRI into a > multi-stage dialing pattern. > d) Better routing capabilities. Switches often support more > than one trunk route > to reach each destination. When routing to a PRI, the switch > thinks it is trying > to reach a subscriber on a PBX. If all the PRI circuits are > busy, then it isn't > likely to have an alternate route to get to that subscriber. > e) SS7 has better congestion control procedures than PRI. > > > > Steve Carr > Unisphere Solutions Inc. > > > > > > Tom Gray on 06/10/99 03:40:37 AM > > To: iptel@lists.research.bell-labs.com, tom_gray_intp@yahoo.com > cc: (bcc: Steve Carr/Internet/ICN) > Subject: Why SS7? > > > > > > I see much written in the IP telephony world about SS7 gateways but I > have seen little written about the basis of this interest. So I will > ask the question. > > What is the basis of the interest in SS7 as opposed to any the many > other signaling schemes (R1, R2, No 5, DPNSS ...)? > > What advantages does it bring and what are its disadvantages. > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > --------- > This message came from the IETF IPTEL Working Group Mailing List. > > > > > > --------- > This message came from the IETF IPTEL Working Group Mailing List. > --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Jun 10 13:30:46 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02070 for ; Thu, 10 Jun 1999 13:30:46 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 2EEB952DE; Thu, 10 Jun 1999 12:14:33 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9BD8952E1; Thu, 10 Jun 1999 12:14:32 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <375FE12C.D54F0190@dnrc.bell-labs.com> Date: Thu, 10 Jun 1999 12:00:44 -0400 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: list iptel Subject: Framework Document Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Folks, I have just submitted an updated version of the GLP framework document to the archives. Until it appears, you can find a copy at: http://www.bell-labs.com/mailing-lists/iptel/draft-ietf-iptel-gwloc-framework-03.txt The main changes are: * lots more explanatory text on the problem definition and motivation * discussion of 800 number translation and how it relates to GLP * comparison with BGP expanded * applications section that gives example configurations * some new terminology (like GIB for Gateway Information Base) The architecture itself is unchanged, but I think this version is much clearer. As such, I also believe we are ready for a working group last call on this document. Once the document appears in the archives, we will enter a two week last call period. Feel free to send comments to either the authors or to the list. Any comments will be folded in to one more rev, and then this will go to IESG if the comments are not substantial enough to warrant another working group last call. If there are no comments at all, version -03 will go to IESG. Note that the framework document will be an informational RFC. So, take this is a warning: send comments NOW or forever hold your peace. Thanks, Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Jun 10 14:08:52 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02642 for ; Thu, 10 Jun 1999 14:08:52 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 766DF52B6; Thu, 10 Jun 1999 14:03:19 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id EBC3F52E4; Thu, 10 Jun 1999 14:03:18 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: From: "Slutsman, Lev A, ALSVC" To: "'Steve.Carr@icn.siemens.com'" Cc: iptel@lists.research.bell-labs.com Subject: Why SS7? Date: Thu, 10 Jun 1999 13:51:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Gents, Just a few comments: 1) SS7 and CAS compliment each other, thus for an advanced 800-calls we must use both! 2) About 15% LECs still use MF signaling; 3) Many customers, such as banks, prefer MF to interconnect to IP-backbone due to security issues with SS7. Regards, Lev. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Jun 10 14:22:06 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02848 for ; Thu, 10 Jun 1999 14:22:05 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id EEF5752E5; Thu, 10 Jun 1999 14:15:22 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6FDF252E4; Thu, 10 Jun 1999 14:15:21 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com X-Lotus-FromDomain: ICN From: Steve.Carr@icn.siemens.com To: "Slutsman, Lev A, ALSVC" Cc: iptel@lists.research.bell-labs.com Message-ID: <8525678C.006473AD.00@li01.lm.ssc.siemens.com> Date: Thu, 10 Jun 1999 14:14:39 -0400 Subject: Re: Why SS7? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk I'd be interested to hear more detail - why do we need both SS7 amd CAS for 800 calls? What are the security issues with SS7? Steve. "Slutsman, Lev A, ALSVC" on 06/10/99 01:51:15 PM To: Steve Carr/Internet/ICN cc: iptel@lists.research.bell-labs.com Subject: Why SS7? Gents, Just a few comments: 1) SS7 and CAS compliment each other, thus for an advanced 800-calls we must use both! 2) About 15% LECs still use MF signaling; 3) Many customers, such as banks, prefer MF to interconnect to IP-backbone due to security issues with SS7. Regards, Lev. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Jun 10 16:02:00 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04265 for ; Thu, 10 Jun 1999 16:02:00 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 7AC7E52E4; Thu, 10 Jun 1999 15:57:20 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id EFD6852E7; Thu, 10 Jun 1999 15:57:19 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <19990610195617.14723.rocketmail@web109.yahoomail.com> Date: Thu, 10 Jun 1999 12:56:17 -0700 (PDT) From: Chris James Subject: how to if a frame is RTP To: iptel@lists.research.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk First, appologies for the newbee question. Given a hex dump of a UDP frame, how is it possible to know if the next layer is RTP? There is no assigned port to it. Is there something in the frame data that distinguishes it? Any help/pointers are appreciated. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Jun 10 16:18:33 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04599 for ; Thu, 10 Jun 1999 16:18:33 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id A7FFC52E7; Thu, 10 Jun 1999 16:10:57 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 2125F52E8; Thu, 10 Jun 1999 16:10:56 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <37601897.B2A3B7DD@dnrc.bell-labs.com> Date: Thu, 10 Jun 1999 15:57:11 -0400 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Chris James Cc: iptel@lists.research.bell-labs.com Subject: Re: how to if a frame is RTP References: <19990610195617.14723.rocketmail@web109.yahoomail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit From the dump of a single packet, there is no way to be certain. RTP is not on a well known port, nor are there magic cookies anywhere. Certain fields in the header generally have a fixed value; in particular, the version number is 2. So, you could tell that a packet is NOT RTP if the version number weren't 2. With 2 packets, you have a better shot. The SSRC stays the same, and other fields, like SN and timestamp, increase by fixed amounts. In this fashion, a stateful process could detect, with increasing probability of success, that the packet was RTP. But it could never be 100%. -Jonathan R. Chris James wrote: > > First, appologies for the newbee question. > > Given a hex dump of a UDP frame, how is it > possible to know if the next layer is RTP? > There is no assigned port to it. Is there > something in the frame data that distinguishes > it? > > Any help/pointers are appreciated. > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > --------- > This message came from the IETF IPTEL Working Group Mailing List. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Jun 10 17:39:17 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05805 for ; Thu, 10 Jun 1999 17:39:17 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 2D4B652EA; Thu, 10 Jun 1999 16:11:47 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 7C94152EB; Thu, 10 Jun 1999 16:11:46 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <3C369333FC7BD21193A60000F8FE891F013AA7E3@dlee02.itg.ti.com> From: "Khayami, Mohsen" To: "'Chris James'" , iptel@lists.research.bell-labs.com Subject: RE: how to if a frame is RTP Date: Thu, 10 Jun 1999 15:10:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk --> Stanley Feng writes: >Colin Perkins wrote: >> --> Venkata Narasimha Murthy Nanduri writes: >> >1) How can we know whether an RTP packet is encapsulated in the UDP data >> >field? >> >> The RTP spec contains code to validate a packet, to ensure that it is RTP >> data. > >So if I want to do some special operation on all the RTP packets, do I have >to check the payload of every UDP packet? i.e., even if only 1% of the UDP >packets contain RTP packets, I will have to do the checking for all the UDP >packets? Yes, unless you have used a signalling protocol to decide which ports are used for RTP traffic. >> >2) If it is based on the UDP port numbers, then are there any standard >> >UDP port numbers that will be used for RTP? >> >> The ports used for RTP traffic are signalled out of band using your >> favourite control protocol (SIP, SAP, RTSP, H.whatever, etc...). There >> are no standard UDP ports for RTP traffic. > >Since we can use control protocol to agree on some port for RTP traffic, I >guess we are ok. Right; this is how things normally work. Colin --------- This message came from the IETF IPTEL Working Group Mailing List. Regards Mohsen Khayami Email: m-khayami@ti.com Phone: 781-895-9110 > -----Original Message----- > From: Chris James [mailto:fab4_fan@yahoo.com] > Sent: Thursday, June 10, 1999 3:56 PM > To: iptel@lists.research.bell-labs.com > Subject: how to if a frame is RTP > > > First, appologies for the newbee question. > > Given a hex dump of a UDP frame, how is it > possible to know if the next layer is RTP? > There is no assigned port to it. Is there > something in the frame data that distinguishes > it? > > Any help/pointers are appreciated. > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > --------- > This message came from the IETF IPTEL Working Group Mailing List. > --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Jun 10 18:05:56 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06376 for ; Thu, 10 Jun 1999 18:05:55 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id D767552E8; Thu, 10 Jun 1999 18:01:21 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 2EFE452EB; Thu, 10 Jun 1999 18:01:21 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com From: "Bob Wise" To: "Slutsman, Lev A, ALSVC" , Cc: Subject: RE: Why SS7? Date: Thu, 10 Jun 1999 16:00:57 -0600 Message-ID: <000a01beb38c$b8148b20$594797d1@vsys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 In-Reply-To: Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit From a call signalling perspective, SS7 and CAS are not both needed for 800 calls, and are not really complimentary so much as they are just alternatives. An 800 call can be delivered using CAS alone, or using SS7 alone, or with a combination. As has been pointed out by other postings, SS7 will generally give greater speed, reliability, and additional information transfer. Note that I am ignoring the national 800 portability issue, for which you would probably end up using SS7 TCAP, but that has nothing to do with the actual call setup. What security issues with SS7? MF isn't inherently more secure than SS7. I would argue the reverse, although it is true that some SS7 networks are administered as if they were physically secure, and thus security is not very much considered. Banks prefer MF because they don't understand SS7, or because the CPE equipment vendors they are using don't support it and have thus sold them away from it. -Bob Wise Chief Architect Vsys > -----Original Message----- > From: owner-iptel@lists.research.bell-labs.com > [mailto:owner-iptel@lists.research.bell-labs.com]On Behalf Of Slutsman, > Lev A, ALSVC > Sent: Thursday, June 10, 1999 11:51 AM > To: 'Steve.Carr@icn.siemens.com' > Cc: iptel@lists.research.bell-labs.com > Subject: Why SS7? > > > Gents, > Just a few comments: > 1) SS7 and CAS compliment each other, thus for an advanced 800-calls we > must use both! > 2) About 15% LECs still use MF signaling; > 3) Many customers, such as banks, prefer MF to interconnect to > IP-backbone due to security issues with SS7. > Regards, > Lev. > > > --------- > This message came from the IETF IPTEL Working Group Mailing List. > --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu Jun 10 19:52:30 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07243 for ; Thu, 10 Jun 1999 19:52:30 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 506CE52E3; Thu, 10 Jun 1999 18:43:20 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9A37052EC; Thu, 10 Jun 1999 18:43:19 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com From: To: Subject: Ayude a que internet crezca! Date: Thu, 10 Jun 1999 08:07:56 -0300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: <02c815707110a69MAURO@mauro.ba.technisys.com.ar> Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk AYUDE A QUE INTERNET CREZCA Responda esta encuesta antes de las próximas 72 horas y P A R T I C I P E D E U N S O R T E O P O R U N A P C P A L M T O P Hp300lx Marque con una x su opción. Si su opción es "otro"; por favor especifique. ______________________________________________________ ¿Tiene acceso a Internet? Si No ______________________________________________________ ¿Desde donde accede a Internet? Oficina Hogar Otro...................... ______________________________________________________ ¿ Comparte su cuenta de Internet? Si No ¿Con cuantas personas? 1 2 3 Más de 3 ______________________________________________________ ¿ Realizó alguna compra en Internet? Si No ______________________________________________________ ¿Qué producto, compró en Internet? - Productos de computación - Libros - Música - Videos/Películas - Viajes - Comidas - Regalos - Ropa - Electrodomésticos - Otros................ _______________________________________________________ ¿Con qué frecuencia compra por Internet? Una vez al año Una vez cada 6 meses Una vez cada 3 meses Una vez al mes Más de una vez al mes _______________________________________________________ ¿Qué valores tienen los productos que compra por Internet? Entre $0 y $20 Entre $20 y $50 Más de $50 Más de $100 Más de $ 1000 ________________________________________________________ ¿Qué productos le gustaría comprar? - Productos de computación - Libros - Música - Videos/ Películas - Viajes - Comidas - Regalos - Ropa - Electrodomésticos - Otro......................... ________________________________________________________ ¿Visita sitios de información financiera? Si No ¿Cuáles? Bloomberg Reuters Quote Patagon Financity Otro................ ________________________________________________________ ¿Realiza operaciones financieras por Internet? Si No ¿Cuáles? Compra/venta de títulos y acciones Compra/venta de fondos de inversión Compra/venta de divisas Operaciones bancarias tradicionales (consulta de cuentas, tarjetas, etc.) Otros.................. _________________________________________________________ ¿Realizaría operaciones financieras por Internet? Si No ¿Cuáles? Compra/venta de títulos y acciones Compra/venta de fondos de inversión Compra/venta de divisas Operaciones bancarias tradicionales (consultas de cuentas, tarjetas) Otros........................................ __________________________________________________________ ¿Cuál es su opinión acerca de las transacciones comerciales y/o financieras en Internet? Son muy seguras Son seguras Son inseguras NS/NC __________________________________________________________ ¿ Cree que el comercio por Internet impactará en el desarrollo de su negocio? Impactará favorablemente Impactará desfavorablemente No impactará GRACIAS! Para mayor información por favor diríjase a nuestra WEB. http://www.esurvey.com.ar --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Jun 11 04:04:47 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26213 for ; Fri, 11 Jun 1999 04:04:46 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 02E3852EC; Fri, 11 Jun 1999 03:59:20 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 62FCE52ED; Fri, 11 Jun 1999 03:59:19 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <3.0.32.19990613154400.00699b0c@public.bta.net.cn> X-Sender: lgao@public.bta.net.cn X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sun, 13 Jun 1999 15:44:03 +0800 To: iptel@lists.research.bell-labs.com From: gao Lan Subject: document about testing Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Dear all: I have a question: Is there any document or RFC about IP phone gateway testing, or IP phone network testing? Best Regard Gao Lan Dupety Director Department of Broadband Network & Multimedia Telecommunication Research Insitute of telecommunication Transmission,MII --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Jun 11 04:14:50 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26323 for ; Fri, 11 Jun 1999 04:14:50 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 1AED752ED; Fri, 11 Jun 1999 04:09:19 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 74EDD52EF; Fri, 11 Jun 1999 04:09:18 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: From: To: , Subject: RE: document about testing Date: Fri, 11 Jun 1999 10:07:13 +0200 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit I have been proof of concept and constraints testing recently, I have used the ETSI TIPHON guidelines (albeit incomplete) which has been OK on a small scale and ok if your european based. Trying to benchmark MOS is a complete waste of time. I have yet to find a volume test simulator (i.e. a 1000 call hit on a device) so if you find one let me know. Paul Buchanan Office: 0031 (0) 23 569 7561 Fax: 0031 (0) 23 569 7959 Mobile: 0044 (0) 411 414 071 Network Architect - Voice over IP paul.buchanan@att-unisource.com http://www.att-unisource.net/ "There will be a day when every call is essentially a local one and IP-telephony comes closer to fulfilling that vision than any other technology." Arthur C. Clarke >---------- >From: gao Lan[SMTP:lgao@public.bta.net.cn] >Sent: 13 June 1999 08:44 >To: iptel@lists.research.bell-labs.com >Subject: document about testing > >Dear all: >I have a question: >Is there any document or RFC about IP phone gateway testing, or IP phone >network testing? > >Best Regard > >Gao Lan >Dupety Director >Department of Broadband Network & Multimedia Telecommunication >Research Insitute of telecommunication Transmission,MII > > > > >--------- >This message came from the IETF IPTEL Working Group Mailing List. > --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Jun 11 07:31:55 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27700 for ; Fri, 11 Jun 1999 07:31:55 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 87A2552EE; Fri, 11 Jun 1999 07:27:21 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id DC2B652F1; Fri, 11 Jun 1999 07:27:20 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <199906111125.HAA27584@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: iptel@lists.research.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-iptel-gwloc-framework-03.txt Date: Fri, 11 Jun 1999 07:25:52 -0400 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk --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 : A Framework for a Gateway Location Protocol Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-iptel-gwloc-framework-03.txt Pages : 24 Date : 10-Jun-99 This document serves as a framework for a protocol for locating an IP telephony gateway. It defines terminology, specifies the various architectural elements and their functions, overviews the services provided by the protocol, and discusses how it fits into the broader context of Internet telephony. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-iptel-gwloc-framework-03.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-gwloc-framework-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-iptel-gwloc-framework-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990611065208.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-iptel-gwloc-framework-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-iptel-gwloc-framework-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990611065208.I-D@ietf.org> --OtherAccess-- --NextPart-- --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Jun 11 11:33:48 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01982 for ; Fri, 11 Jun 1999 11:33:48 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 2805B52F1; Fri, 11 Jun 1999 11:27:20 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9233B52F2; Fri, 11 Jun 1999 11:27:19 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <37612B6D.145E9E46@site.uottawa.ca> Date: Fri, 11 Jun 1999 11:29:49 -0400 From: Stanley Pinjiang Feng X-Mailer: Mozilla 4.05 [en] (WinNT; I) MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Chris James , iptel@lists.research.bell-labs.com Subject: Re: how to if a frame is RTP References: <19990610195617.14723.rocketmail@web109.yahoomail.com> <37601897.B2A3B7DD@dnrc.bell-labs.com> Content-Type: multipart/alternative; boundary="------------B0978D17E97C18EE322B4DE2" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk --------------B0978D17E97C18EE322B4DE2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This may be of interest. The following is from the newest version of RFC1890: RTP Profile for Audio and Vedio Conferences with Minimal Control section 8: Port numbers 5004 and 5005 have been registered for use with this profile for those applications that choose to use them as the default pair. Applications that operate multiple profiles may use this port pair as an indication to select this profile if they are not subject to the constraint of the previous paragraph. I would very much prefer to have these default UDP ports for RTP. Again, we can use this default pair to agree on some other pair of ports so that mutiple RTP sessions can be carried simultaneously between two IP addresses. Thank you Stanley Feng Jonathan Rosenberg wrote: > >From the dump of a single packet, there is no way to be certain. RTP is > not on a well known port, nor are there magic cookies anywhere. Certain > fields in the header generally have a fixed value; in particular, the > version number is 2. So, you could tell that a packet is NOT RTP if the > version number weren't 2. With 2 packets, you have a better shot. The > SSRC stays the same, and other fields, like SN and timestamp, increase > by fixed amounts. In this fashion, a stateful process could detect, with > increasing probability of success, that the packet was RTP. But it could > never be 100%. > > -Jonathan R. > > Chris James wrote: > > > > First, appologies for the newbee question. > > > > Given a hex dump of a UDP frame, how is it > > possible to know if the next layer is RTP? > > There is no assigned port to it. Is there > > something in the frame data that distinguishes > > it? > > > > Any help/pointers are appreciated. > > _________________________________________________________ > > Do You Yahoo!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > --------- > > This message came from the IETF IPTEL Working Group Mailing List. > > -- > Jonathan D. Rosenberg Lucent Technologies > Member of Technical Staff 101 Crawfords Corner Rd. > High Speed Networks Research Holmdel, NJ 07733 > FAX: (732) 834-5379 Rm. 4C-526 > EMAIL: jdrosen@bell-labs.com > URL: http://www.cs.columbia.edu/~jdrosen > > --------- > This message came from the IETF IPTEL Working Group Mailing List. --------------B0978D17E97C18EE322B4DE2 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit This may be of interest. The following is from the newest version of RFC1890: RTP Profile for Audio and Vedio Conferences with Minimal Control section 8:
Port numbers 5004 and 5005 have been registered for use with this profile for those applications that choose to use them as the default pair.  Applications that operate multiple profiles may use this port pair as an indication to select this profile if they are not subject to the constraint of the previous paragraph.
I would very much prefer to have these default UDP ports for RTP.  Again, we can use this default pair to agree on some other pair of ports so that mutiple RTP sessions can be carried simultaneously between two IP addresses.

Thank you

Stanley Feng

Jonathan Rosenberg wrote:

>From the dump of a single packet, there is no way to be certain. RTP is
not on a well known port, nor are there magic cookies anywhere. Certain
fields in the header generally have a fixed value; in particular, the
version number is 2. So, you could tell that a packet is NOT RTP if the
version number weren't 2. With 2 packets, you have a better shot. The
SSRC stays the same, and other fields, like SN and timestamp, increase
by fixed amounts. In this fashion, a stateful process could detect, with
increasing probability of success, that the packet was RTP. But it could
never be 100%.

-Jonathan R.

Chris James wrote:
>
> First, appologies for the newbee question.
>
> Given a hex dump of a UDP frame, how is it
> possible to know if the next layer is RTP?
> There is no assigned port to it.  Is there
> something in the frame data that distinguishes
> it?
>
> Any help/pointers are appreciated.
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
> ---------
> This message came from the IETF IPTEL Working Group Mailing List.

--
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: jdrosen@bell-labs.com
URL: http://www.cs.columbia.edu/~jdrosen

---------
This message came from the IETF IPTEL Working Group Mailing List.

  --------------B0978D17E97C18EE322B4DE2-- --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Jun 11 12:03:54 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02441 for ; Fri, 11 Jun 1999 12:03:54 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 0D53252F0; Fri, 11 Jun 1999 11:59:19 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6FC7652F2; Fri, 11 Jun 1999 11:59:18 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <011101beb422$c0221760$759f47ab@glock.cisco.com> From: "Stephen Sprunk" To: "Stanley Pinjiang Feng" Cc: Subject: Re: how to if a frame is RTP Date: Fri, 11 Jun 1999 10:53:40 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit It is common practice to start with 5004/5005 and work upwards from there (eg. second stream on 5006/5007, third on 5008/5009, etc.) However, not all applications follow this practice; the VoIP implementation on Cisco IOS starts at 16384 for example. The only way you're going to reliably find RTP streams is examine your signalling protocol. H.323's signalling is painful to decode, but SIP/SDP is relatively simple. S | | Stephen Sprunk, K5SSS, CCIE #3723 :|: :|: NSA, Network Consulting Engineer :|||: :|||: 14875 Landmark Blvd #400; Dallas, TX .:|||||||:..:|||||||:. Pager: 800-365-4578 / 800-901-6078 C I S C O S Y S T E M S Email: ssprunk@cisco.com -----Original Message----- From: Stanley Pinjiang Feng To: Jonathan Rosenberg Cc: Chris James ; iptel@lists.research.bell-labs.com Date: Friday, June 11, 1999 10:30 Subject: Re: how to if a frame is RTP This may be of interest. The following is from the newest version of RFC1890: RTP Profile for Audio and Vedio Conferences with Minimal Control section 8: Port numbers 5004 and 5005 have been registered for use with this profile for those applications that choose to use them as the default pair. Applications that operate multiple profiles may use this port pair as an indication to select this profile if they are not subject to the constraint of the previous paragraph. I would very much prefer to have these default UDP ports for RTP. Again, we can use this default pair to agree on some other pair of ports so that mutiple RTP sessions can be carried simultaneously between two IP addresses. Thank you Stanley Feng --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Jun 11 19:59:19 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08937 for ; Fri, 11 Jun 1999 19:59:19 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 9E83D52F2; Fri, 11 Jun 1999 19:53:21 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 0F25D52F5; Fri, 11 Jun 1999 19:53:20 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com From: crk@research.att.com (Chuck Kalmanek) Message-Id: <9906111950.ZM4464113@corona.research.att.com> Date: Fri, 11 Jun 1999 19:50:34 -0400 X-Mailer: Z-Mail (3.2.1 10oct95) To: iptel@lists.research.bell-labs.com Subject: NOSSDAV99 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Folks, We would like to close registration for NOSSDAV on Tuesday, June 15. http://weblab.research.att.com/edas/nossdav99.html chuck -- Chuck Kalmanek Email: crk@research.att.com AT&T Labs - Research Phone: 973-360-8720 Shannon Laboratory, Room A113 Fax: 973-360-8871 180 Park Avenue, Florham Park, N.J. 07932 --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Sat Jun 12 04:52:42 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26659 for ; Sat, 12 Jun 1999 04:52:41 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 788DE52E2; Sat, 12 Jun 1999 04:45:18 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D28AB52EF; Sat, 12 Jun 1999 04:45:17 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com From: Claudia Paladino To: Lista de destinatarios oculta Date: Sat, 12 Jun 1999 05:24:26 -0300 Subject: Festival Aereo X-Mailer: MultiMailer MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <08314798815822@houseware.com.ar> Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 8bit FESTIVAL AEREO DE OSH KOSH 1999 EN UNA SEMANA SE CONGREGAN MAS DE 12.000 AVIONES ENTRE CONVENCIONALES, ACROBATICOS, DE COMBATE, DE TRANSPORTE, ULTRALIVIANOS,EXPERIMENTALES,HELICOPTEROS, ETC EN 1998 NOS VISITARON 850.000 PERSONAS. ADEMAS DE LOS ESPECTACULOS AERONAUTICOS DIURNOS Y NOCTURNOS, PODRA ADQUIRIR TODO TIPO DE SOUVENIRS Y ELEMENTOS AERONAUTICOS. HAY UN MUSEO Y UNA BASE DE HIDROAVIONES PARA VISITAR. Salida .28 de Julio-Regreso 03 de Agosto (con opción a quedarse días adicionales en Miami) El Paquete incluye: Pasaje aéreo de United Bue/Chicago/Appleton/Chicago/Bue 5 Noches de alojamiento con desayuno continental. Hotel Days Inn, a 30 km de Osh Kosh, exelente ubicación Inscripción a la EAA por un año Entradas por 5 días Opción:Aquiler de auto Total U$D 1590.- Forma de pago: Seña: $ 275 al momento de la reserva Saldo:$ 110 corresponden a inscripción y entradas se abonan con tarjeta de crédito $ 1205 se pueden abonar cash o con tarjeta en pagos con revargo IMPORTANTE: CONFIRMAR A LA BREVEDAD YA QUE LA DEMANDA ES MUY GRANDE Y LA DISPONONIBILIDAD AL DIA DE LA FECHA ES ESCASA. CONSULTAS: Sudamcar Viajes yTturism Licencia823/72 Parana 1213 3pso.74 4373-0394/4374-8363/15-4946-4075 www.sudamcar.com.ar --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Sat Jun 12 10:01:07 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28492 for ; Sat, 12 Jun 1999 10:01:06 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id A863152EB; Sat, 12 Jun 1999 09:53:17 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 1922A52F4; Sat, 12 Jun 1999 09:53:17 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <01BEB4F3.B37E3D00.amir@radvision.rad.co.il> From: Amir Ami To: "'gao Lan'" , "iptel@lists.research.bell-labs.com" Subject: RE: document about testing Date: Sat, 12 Jun 1999 16:29:42 +0200 Organization: RADVision X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk The IMTC has a whole set of inetroperability/testing documents (in the relevant AGs). See the IMTC.COM site Ami -----Original Message----- From: gao Lan [SMTP:lgao@public.bta.net.cn] Sent: Sunday, June 13, 1999 9:44 AM To: iptel@lists.research.bell-labs.com Subject: document about testing Dear all: I have a question: Is there any document or RFC about IP phone gateway testing, or IP phone network testing? Best Regard Gao Lan Dupety Director Department of Broadband Network & Multimedia Telecommunication Research Insitute of telecommunication Transmission,MII --------- This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Jun 15 10:24:04 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18583 for ; Tue, 15 Jun 1999 10:24:02 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id C128B52D5; Tue, 15 Jun 1999 10:14:30 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 2178752DC; Tue, 15 Jun 1999 10:14:30 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <37665C4F.B6AEBF54@dnrc.bell-labs.com> Date: Tue, 15 Jun 1999 09:59:43 -0400 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: confctrl@isi.edu, list iptel Cc: Aleta Lapone Subject: Siphone SIP client now available! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Folks, Bell Labs is pleased to announce that our SIP graphical user agent, siphone, is now available for download for free (for research and non-commercial usage) from the web. Our client is a fully functional UAS and UAC. It supports: * call initiation, termination, rejection, redirection, cancellation * registration * tcp and udp * integration with web browser * do-not-disturb * automatic call forwarding features * support for local proxies * transfer and multi-party conferencing (experimental only - based on a preliminary call control specification) Siphone does not support media directly; it makes use of separate media tools for this purpose. It uses PMM (Pattern Matching Multicast) to interface with the media tool. We have used nevot for the media tool; you can obtain a statically linked version of nevot from our download site for your convenience. Siphone runs on WinNT, Linux, and Solaris. To download, visit our siphone project site at: http://www.bell-labs.com/project/sip/ Thanks, Jonathan Rosenberg Igor Slepchin -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Jun 15 11:27:54 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21043 for ; Tue, 15 Jun 1999 11:27:53 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 83F1752DD; Tue, 15 Jun 1999 11:19:18 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id EB29452DF; Tue, 15 Jun 1999 11:19:17 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <4.2.0.56.19990615110618.00a37100@hermes.usherb.ca> X-Sender: 94298898@hermes.usherb.ca X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta) Date: Tue, 15 Jun 1999 11:18:48 -0400 To: iptel@lists.research.bell-labs.com From: Hans Viens Subject: RTP security Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hi Folks! I read that security in RTP protocol SHOULD use DES (CBC). Since DES is a symetric algorithm I would like to know how the key is exchange between the parties ? More explicitly, how should it be exchange to be full secure ? Best regards, Hans... --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Jun 15 14:36:13 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26107 for ; Tue, 15 Jun 1999 14:36:12 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id A0F6F52DE; Tue, 15 Jun 1999 13:17:35 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 144F152DF; Tue, 15 Jun 1999 13:17:35 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com To: Hans Viens Cc: iptel@lists.research.bell-labs.com Subject: Re: RTP security In-reply-to: Your message of "Tue, 15 Jun 1999 11:18:48 EDT." <4.2.0.56.19990615110618.00a37100@hermes.usherb.ca> Date: Tue, 15 Jun 1999 18:16:11 +0100 Message-ID: <4231.929466971@cs.ucl.ac.uk> From: Colin Perkins Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk --> Hans Viens writes: >I read that security in RTP protocol SHOULD use DES (CBC). Since DES is a >symetric algorithm I would like to know how the key is exchange between the >parties ? Using a higher-level control protocol such as H.323 or SIP. The RTP protocol itself doesn't specify key exchange. Colin --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Jun 15 15:25:41 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27494 for ; Tue, 15 Jun 1999 15:25:40 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 5C31452DB; Tue, 15 Jun 1999 15:17:21 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C673952DF; Tue, 15 Jun 1999 15:17:20 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com From: "David Oran" To: Subject: Comments (mostly editorial) on GWLOC Framework Document for last call Date: Tue, 15 Jun 1999 15:15:29 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hope you find these useful. They're not technical for the most part, rather editorial. p.2, "location policy server", change "...information it receives via GLP" to "...information it sends and receives via GLP" P.2, "Peers", and numerous other places. I wonder if we should use the term "association" rather than "connection" for the state which represents an active peering over which GLP mesages are transmitted. The word "connection" often implies TCP or other specifically connection-oriented transport protocol. I don't feel strongly about this, however. In all the places I checked, the word "association" seems to imly the right semantics, without the overloading that the word "connection" usually has. p. 3, first line, you talk about a gateway as a "routing" point for application layer signaling. This is a really subtle distinction, but I have a preference for the word "relaying" in this context, because "routing" tends to imply all the complexity we are now associating with the LS's. p. 4, under functions, I think some mention of loops and loop prevention is warranted since we don't really address this elsewhere. How about: "o prevention of stable forwarding loops for IP telephony signaling protocols." p. 6, second bullett, missing word: "BGP runs between rounters *that* are usually adjacent" p. 15, 9.2.1, 3rd line, where you say "an IP address which is the next hop" I think it would eliminate a lot of potential confusion is we said "IP address which is the next *layer 7* hop". --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Jun 15 16:05:30 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28771 for ; Tue, 15 Jun 1999 16:05:29 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 61BCE52DF; Tue, 15 Jun 1999 15:57:19 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id CCA1252E0; Tue, 15 Jun 1999 15:57:18 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Date: Wed, 16 Jun 1999 13:45:16 -0600 From: "Ralph S. Hoefelmeyer" Subject: RE: RTP security In-reply-to: <4.2.0.56.19990615110618.00a37100@hermes.usherb.ca> To: "'Hans Viens'" , iptel@lists.research.bell-labs.com Message-id: <000001beb830$c3247540$aa9222a6@loviatar.NIP_Platform> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hans, Be aware that DES only provides privacy, NOT security. Ralph -----Original Message----- From: owner-iptel@lists.research.bell-labs.com [mailto:owner-iptel@lists.research.bell-labs.com]On Behalf Of Hans Viens Sent: Tuesday, June 15, 1999 9:19 AM To: iptel@lists.research.bell-labs.com Subject: RTP security Hi Folks! I read that security in RTP protocol SHOULD use DES (CBC). Since DES is a symetric algorithm I would like to know how the key is exchange between the parties ? More explicitly, how should it be exchange to be full secure ? Best regards, Hans... --------- This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Jun 15 23:41:44 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07638 for ; Tue, 15 Jun 1999 23:41:44 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 9517D52E1; Tue, 15 Jun 1999 23:33:26 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 159F752BB; Tue, 15 Jun 1999 23:33:26 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com X-Mailer: Aureate Group Mail Free Edition From: Hit The Cellular To: Motorola Date: Thu, 17 Jun 1999 03:34:00 -0300 Subject: CELULAR STARTAC V3620(EL MAS CHICO) OFERTA !!! Reply-To: ventas@hitthe.net Organization: Hit The Cellular MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Priority: 3 X-Infomail-Id: 929481922.3F8701AC1E039F.21922 Message-Id: <19990616033307.B83E152E1@lists.research.bell-labs.com> Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit este mensaje se envia por unica vez. HIT THE CELLULAR ARGENTINA, IMPORTADOR DIRECTO DE CELULARES MOTOROLA, LANZA AL MERCADO LA OFERTA MAS ESPERADA: MOTOROLA V3620 EL MAS PEQUEÑO DEL MUNDO A SOLO $ 549.- (INCLUYE IVA) ENVIE AHORA MISMO UN E-MAIL A: ventas@hitthe.net INCLUYE: VibraCall(TM) discreet alert; VoiceNote(TM) recorder and integrated digital answering machine; y mucho mas.... Oferta por tiempo limitado ---------------------------------------------------------------------- This Message sent with Aureate Group Mail Free Edition http://groupmail.aureate.com --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Jun 16 01:09:16 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08767 for ; Wed, 16 Jun 1999 01:09:15 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 06E1C52E3; Wed, 16 Jun 1999 01:01:28 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6B72F52BB; Wed, 16 Jun 1999 01:01:27 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com X-Mailer: Aureate Group Mail Free Edition From: DJ Remix To: personalizado Date: Wed, 16 Jun 1999 01:53:12 -0300 Subject: DeeJay Remix "EL SOFT MAS VENDIDO EN EE.UU" Reply-To: remix@11mail.com Organization: DJ Remix MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Priority: 3 X-Infomail-Id: 929487230.4A7E01AC1E03A0.27230 Message-Id: <19990616050107.C83F952E3@lists.research.bell-labs.com> Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit este mensaje se envia por unica vez DJ REMIX ES EL SOFT MUSICAL POR EXCELENCIA. Con DJ Remix podes: Crear tu musica. Hacer tus remix. Realizar scraching y mas... Incluye: Mas de 1300 Sampleos. Sequencer 8 canales Video tutorial Facil uso. OFERTA CONTADO A SOLO $39.- PEDILO AHORA ENVIANDO UN E-MAIL A: remix@11mail.com Envios en Capital sin cargo. Para mas info visite: http://orbita.starmedia.com/~remix11 ---------------------------------------------------------------------- This Message sent with Aureate Group Mail Free Edition http://groupmail.aureate.com --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Jun 16 21:17:33 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05636 for ; Wed, 16 Jun 1999 21:17:33 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 7BE5652B6; Wed, 16 Jun 1999 21:10:30 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id DDEF152DC; Wed, 16 Jun 1999 21:10:29 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <37684B1C.E49D0F59@dnrc.bell-labs.com> Date: Wed, 16 Jun 1999 21:10:52 -0400 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: David Oran Cc: iptel@lists.research.bell-labs.com Subject: Re: Comments (mostly editorial) on GWLOC Framework Document for last call References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit David Oran wrote: > > Hope you find these useful. They're not technical for the most part, rather > editorial. > > p.2, "location policy server", change "...information it receives via GLP" > to "...information it sends and receives via GLP" Done. > > P.2, "Peers", and numerous other places. I wonder if we should use the term > "association" rather than "connection" for the state which represents an > active peering over which GLP mesages are transmitted. The word "connection" > often implies TCP or other specifically connection-oriented transport > protocol. I don't feel strongly about this, however. In all the places I > checked, the word "association" seems to imly the right semantics, without > the overloading that the word "connection" usually has. Fine. > > p. 3, first line, you talk about a gateway as a "routing" point for > application layer signaling. This is a really subtle distinction, but I have > a preference for the word "relaying" in this context, because "routing" > tends to imply all the complexity we are now associating with the LS's. Good point. Changed. > > p. 4, under functions, I think some mention of loops and loop prevention is > warranted since we don't really address this elsewhere. How about: > "o prevention of stable forwarding loops for IP telephony signaling > protocols." Added. > > p. 6, second bullett, missing word: "BGP runs between rounters *that* are > usually adjacent" Fixed. > > p. 15, 9.2.1, 3rd line, where you say "an IP address which is the next hop" > I think it would eliminate a lot of potential confusion is we said "IP > address which is the next *layer 7* hop". Good point; changed. Thanks for your comments. They'll appear in the -04 draft. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Jun 18 08:21:50 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22021 for ; Fri, 18 Jun 1999 08:21:49 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 5A9FD52BB; Fri, 18 Jun 1999 08:15:19 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A84BB52E0; Fri, 18 Jun 1999 08:15:18 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <19990618121446.5945.rocketmail@web125.yahoomail.com> Date: Fri, 18 Jun 1999 05:14:46 -0700 (PDT) From: Beatles Fan Subject: RTP G.723 payload To: iptel@lists.research.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hi, I am trying to decode RTP frames. I can get as far as the RTP layer. The payload type is G.723 Audio. I am interested in these data bits. Is there a spec that describes the bit contents? Is it ALL simply voice raw data? I have ITU subscriptions so if there is a document on that site that I need, please let me know. Thanks in advance for any help. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Jun 18 08:36:27 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22203 for ; Fri, 18 Jun 1999 08:36:27 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 0E9F952E0; Fri, 18 Jun 1999 08:31:20 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 7364052E2; Fri, 18 Jun 1999 08:31:19 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Beatles Fan Cc: iptel@lists.research.bell-labs.com Message-ID: <65256794.00449CF2.00@sampark.hss.hns.com> Date: Fri, 18 Jun 1999 18:01:43 +0530 Subject: Re: RTP G.723 payload Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hi, if you want to know the format of G.723 packets, then you can download the source from ITU for the G.723 codec (available in C) and check it out. Since you are using a codec, the payload is the compressed data specific to the 723 format and is surely not RAW voice data. Regds Arjun Beatles Fan on 06/18/99 05:44:46 PM To: iptel@lists.research.bell-labs.com cc: Subject: RTP G.723 payload Hi, I am trying to decode RTP frames. I can get as far as the RTP layer. The payload type is G.723 Audio. I am interested in these data bits. Is there a spec that describes the bit contents? Is it ALL simply voice raw data? I have ITU subscriptions so if there is a document on that site that I need, please let me know. Thanks in advance for any help. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com --------- This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Jun 18 10:05:11 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23566 for ; Fri, 18 Jun 1999 10:05:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 36B2B52E2; Fri, 18 Jun 1999 09:59:42 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 5455852E4; Fri, 18 Jun 1999 09:59:41 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <376A4D69.17156D04@dnrc.bell-labs.com> Date: Fri, 18 Jun 1999 09:45:13 -0400 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Beatles Fan Cc: iptel@lists.research.bell-labs.com, rem-conf@es.net Subject: Re: RTP G.723 payload References: <19990618121446.5945.rocketmail@web125.yahoomail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit The AVT rem-conf@es.net list is the more appropriate venue for this question. See http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-new-05.txt for a description of g.721.1 packetization in RTP. -Jonathan R. Beatles Fan wrote: > > Hi, > > I am trying to decode RTP frames. I can get as far as > the RTP layer. The payload type is G.723 Audio. > I am interested in these data bits. Is there a spec that > describes the bit contents? Is it ALL simply voice raw > data? I have ITU subscriptions so if there is a document > on that site that I need, please let me know. Thanks > in advance for any help. > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > --------- > This message came from the IETF IPTEL Working Group Mailing List. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Jun 18 10:17:28 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23707 for ; Fri, 18 Jun 1999 10:17:28 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 90F6452E5; Fri, 18 Jun 1999 10:09:23 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id EADB252E4; Fri, 18 Jun 1999 10:09:22 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: From: Scott Cadzow To: "'Amir Ami'" , "'gao Lan'" , iptel@lists.research.bell-labs.com Subject: RE: document about testing Date: Fri, 18 Jun 1999 16:11:48 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk see also ETSI TIPHON WG6 documents for IP to SCN phone testing. There will be an ETSI hosted Interop event for this next week. http://www.etsi.org/tiphon S. -----Original Message----- From: Amir Ami [mailto:amir@radvision.rad.co.il] Sent: 12 June 1999 16:30 To: 'gao Lan'; iptel@lists.research.bell-labs.com Subject: RE: document about testing The IMTC has a whole set of inetroperability/testing documents (in the relevant AGs). See the IMTC.COM site Ami -----Original Message----- From: gao Lan [SMTP:lgao@public.bta.net.cn] Sent: Sunday, June 13, 1999 9:44 AM To: iptel@lists.research.bell-labs.com Subject: document about testing Dear all: I have a question: Is there any document or RFC about IP phone gateway testing, or IP phone network testing? Best Regard Gao Lan Dupety Director Department of Broadband Network & Multimedia Telecommunication Research Insitute of telecommunication Transmission,MII --------- This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Jun 18 10:28:33 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23820 for ; Fri, 18 Jun 1999 10:28:32 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 017ED52E4; Fri, 18 Jun 1999 10:23:18 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 73E1152E6; Fri, 18 Jun 1999 10:23:17 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <376A55E5.31C@mitel.com> Date: Fri, 18 Jun 1999 10:21:25 -0400 From: Robert Wood Organization: Mitel Corporation X-Mailer: Mozilla 3.01 (X11; I; HP-UX B.10.20 9000/715) MIME-Version: 1.0 To: iptel@lists.research.bell-labs.com, rem-conf@es.net Subject: RTP multiplexing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi, has any motion occured on the issue of RTP multiplexing? [\] Robert Wood The St. Lawrence river - fresh, warm, visible diving. mailto:robert_wood@mitel.com http://www.magma.ca/~rgwood/ --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Jun 18 11:36:31 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24932 for ; Fri, 18 Jun 1999 11:36:31 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id C2C2352DC; Fri, 18 Jun 1999 11:31:19 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3B95552E7; Fri, 18 Jun 1999 11:31:19 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: From: "Monling Liao" To: sigtran@standards.nortelnetworks.com Cc: "'iptel@lists.research.bell-labs.com'" Subject: RE: Adaptation modules Date: Fri, 18 Jun 1999 11:28:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA24932 The exchange of TCAP messages between SS7/IN/wireless and IP domains for services interworking requires proper SCCP-like addressing and routing functions in SG and IP entities. The following two drafts describe addressing/routing functions, protocols and services interworking scenarios. http://www.ietf.org/internet-drafts/draft-liao-ss7-tcap-ip-00.txt http://www.ietf.org/internet-drafts/draft-liao-stipp-00.txt Regards, Monling Monling Liao Carrier Packet Solutions 919-991-2704 (ESN 351-2704) monling@nortelnetworks.com > -----Original Message----- > From: Schwarzbauer Hanns Juergen > [SMTP:HannsJuergen.Schwarzbauer@ICN.SIEMENS.DE] > Sent: Friday, June 18, 1999 8:17 AM > To: sigtran@standards.nortelnetworks.com > Subject: AW: Adaptation modules & IETF agenda > > John, > > I'm a bit uncertain about what you mean when talking about "SCCP > services". > > However, if you intend to transport SCCP messages over an IP network, you > can it do the same way as ISUP messages are to be transported. > Please keep in mind that both SCCP and ISUP are user parts on top of MTP > L3 > and therefore the interface requirements for both protocols (towards the > lower layer) are identical. > > As long as no global title translation is required I would expect no need > for a special adaptation module to support SCCP over MDTP. However, if you > want to perform a global title translation, you have to include the > relevant > SCCP functions in another "adaptation module" and doing this I would > prefer > to state that you are transporting TCAP/TC-Application over the IP network > using an appropriate adaptation module. > > There have been a number of drafts for the Minneapolis meeting in march > (e.g. Ericsson, Siemens-Atea). > > > > HannsJuergen Schwarzbauer > > SIEMENS AG > Information and Communication Networks > Wireline Network Communication > Carrier Switching Networks > ICN WN CS SE 51 > > Tel: +49 89 722 24236 > Fax: +49 89 722 48212 > E-mail HannsJuergen.Schwarzbauer@icn.siemens.de > > > -----Ursprüngliche Nachricht----- > > Von: John Loughney [SMTP:john.loughney@NOKIA.COM] > > Gesendet am: Freitag, 18. Juni 1999 12:38 > > An: SIGTRAN@STANDARDS.NORTELNETWORKS.COM > > Betreff: Adaptation modules & IETF agenda > > > > Greetings, > > > > I have been following the mail list for some time, but have yet had a > > chance > > to comment towards anything. I essentially only have a few questions. > > > > I have seen that the following adaptation modules are being consided at > > the > > moment: > > > > Signaling Backhaul document > > SS7 Gateway module > > SG-MGC for cable > > > > We are currently studying what would be needed to carry SCCP services > over > > MDTP. Has there been any work done on this already? If not, we would > be > > interested in collaborating with interested parties on a possible draft > > document. > > > > Secondly, as the agenda for the Oslo IETF meeting been announced for > > SIGTRAN? I know that we are in the middle of quite a large discussion > of > > MDTP. > > > > best regards, > > John Loughney > > Nokia Research Center --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Jun 18 15:22:29 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28908 for ; Fri, 18 Jun 1999 15:22:28 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 5588652E6; Fri, 18 Jun 1999 14:09:19 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id AA6DA52E8; Fri, 18 Jun 1999 14:09:18 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Date: Fri, 18 Jun 1999 11:07:54 -0700 (PDT) From: Dan Wing To: Robert Wood Cc: iptel@lists.research.bell-labs.com, rem-conf@es.net Subject: Re: RTP multiplexing In-Reply-To: <376A55E5.31C@mitel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk On Fri, 18 Jun 1999 10:21 -0400, Robert Wood wrote: We have a new proposal I have been editing which will be submitted as an I-D shortly. I will also publish it on our FTP site as I expect the I-D publishing delay is getting large as we approach the I-D submission cutoff date. -Dan Wing > Hi, has any motion occured on the issue > of RTP multiplexing? > > [\] Robert Wood > > The St. Lawrence river - fresh, warm, visible diving. > > mailto:robert_wood@mitel.com http://www.magma.ca/~rgwood/ > --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Jun 18 21:29:21 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03012 for ; Fri, 18 Jun 1999 21:29:20 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id BFC5352E8; Fri, 18 Jun 1999 20:31:19 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3B4AA52E9; Fri, 18 Jun 1999 20:31:19 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: From: "El-Gebaly, Hani" To: Hans Viens Cc: iptel@lists.research.bell-labs.com Subject: RE: RTP security Date: Fri, 18 Jun 1999 17:29:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk In the H.323 context, the key exchange is done in the openlogicalchannel and openlogicalchannelAck messages. Further in order to encrypt those session keys, you need to come up with a shared secret using for example Diffie-Helman algorithm in the call establishment messages (Q.931 Setup, alerting and Connect). You can then extract a meta key out of the shared secret and use it for encrypting your media session keys before sending them across in the logical channels. The procedure is defined in the H.323 security profile SP1. cheers, Hani > -----Original Message----- > From: Hans Viens > Sent: Tuesday, June 15, 1999 8:19 AM > To: iptel@lists.research.bell-labs.com > Subject: RTP security > > Hi Folks! > > I read that security in RTP protocol SHOULD use DES (CBC). Since DES is a > > symetric algorithm I would like to know how the key is exchange between > the > parties ? > > More explicitly, how should it be exchange to be full secure ? > > Best regards, > > Hans... > > > --------- > This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Jun 25 11:49:20 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24927 for ; Fri, 25 Jun 1999 11:49:20 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 6FD6752D5; Fri, 25 Jun 1999 10:40:05 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 038C052BB; Fri, 25 Jun 1999 10:40:04 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <37739183.22921A4F@dnrc.bell-labs.com> Date: Fri, 25 Jun 1999 10:26:11 -0400 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: list iptel Subject: GLP attributes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Folks, Although things have been quiet on the list, there has been much activity over the past weeks on GLP. Matt Squire, Hussein Salama, and myself have gotten together and achieved consensus among the three of us on the set of attributes for GLP. We've produced and Internet Draft which specifies these attributes, including aggregation and dissemination rules, attribute flags, and basic syntax. We've also included a list of the attributes we ruled out, and a discussion of why. Our decisions are not final. They only represent consensus among the three of us. It is now time to see if these choices represent consensus among the entire working group. Of course, numerous open issues also remain. These are mentioned throughout the draft, and in a section at the end. I would like for us to focus discussion on the list, and discussion during the meeting, and these open issues. I'd also like for people to speak up if they disagree with the choices we've made. The draft was submitted to the archives this morning, and should appear shortly. In the mean time, you can pick up a copy from the iptel home page at: http://www.bell-labs.com/mailing-lists/iptel/draft-ietf-iptel-glp-attribs-00.txt This draft is an important milestone in our development of GLP. I'd like to especially thank Matt Squire, who took the active lead in pushing this work and editing the document. Thanks, Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Jun 25 15:29:59 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02127 for ; Fri, 25 Jun 1999 15:29:58 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 4D6DD52BB; Fri, 25 Jun 1999 15:23:20 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C2D9152DB; Fri, 25 Jun 1999 15:23:19 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <19990625192206.8910.rocketmail@web118.yahoomail.com> Date: Fri, 25 Jun 1999 12:22:06 -0700 (PDT) From: Beatles Fan Subject: H.245 frames To: Jonathan Rosenberg Cc: iptel@lists.research.bell-labs.com, rem-conf@es.net MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hi, I am looking at the raw data in VoIP frames. I am trying to figure out how H.245 relates to these. In particular, what protocol calls it (is it a well known port; as say H.225, 1720 in TCP) and what are the frame contents? If anybody can give me pointers to specs and/or web pages it would be appreciated. I do have ITU document access so if it is a particular ITU document, please let me know. Thanks in advance. Chris _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri Jun 25 18:31:25 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07107 for ; Fri, 25 Jun 1999 18:31:25 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 78CF452DB; Fri, 25 Jun 1999 17:14:03 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id EDC0352DD; Fri, 25 Jun 1999 17:14:02 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <3773EDDA.93ED1369@dnrc.bell-labs.com> Date: Fri, 25 Jun 1999 17:00:10 -0400 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Beatles Fan Cc: iptel@lists.research.bell-labs.com, rem-conf@es.net Subject: Re: H.245 frames References: <19990625192206.8910.rocketmail@web118.yahoomail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit I think you're talking about RTP: rfc1889 and rfc1890 define the encapsulation. The codec bits depend on the codec - g.711, g.723, dvi, whatever. Beatles Fan wrote: > > Hi, > > I am looking at the raw data in VoIP frames. I am > trying to figure out how H.245 relates to these. > In particular, what protocol calls it (is it a > well known port; as say H.225, 1720 in TCP) and what are > the frame contents? If anybody can give me pointers > to specs and/or web pages it would be appreciated. > I do have ITU document access so if it is a particular > ITU document, please let me know. Thanks in > advance. > > Chris > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Sun Jun 27 06:25:01 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28187 for ; Sun, 27 Jun 1999 06:25:00 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 8814B52E2; Sun, 27 Jun 1999 06:19:28 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id DF19252B6; Sun, 27 Jun 1999 06:19:27 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com X-Mailer: Aureate Group Mail Free Edition From: "N.H" To: mail Date: Sun, 27 Jun 1999 07:21:55 -0300 Subject: BASE DE DATOS / GRAN NEGOCIO Reply-To: info2@nhmail.com Organization: N.H MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Priority: 3 X-Infomail-Id: 930478558.66D201AC1E039E.58558 Message-Id: <19990627101908.C1D1752E2@lists.research.bell-labs.com> Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit si este mail no es de su interes no se tiene que dar de baja ya que se envia por unica vez... disculpe. "NH" Argentina, le ofrece la mejor informacion para su negocio o emprendimiento, bases de datos con direcciones y telefonos, bases de fax, bases de negocios con nombre y las mejores bases de E-mail. OFERTA DEL MES: 37000 E-MAIL ARGENTINOS POR SOLO $75.- 73000 E-MAIL ARGENTINOS POR SOLO $125.- AHORA O NUNCA, NO DEJE PASAR LA OPRTUNIDAD. ENVIE YA UN E-MAIL A: compras@nhmail.com con su telefono y nos contactaremos. ---------------------------------------------------------------------- This Message sent with Aureate Group Mail Free Edition http://groupmail.aureate.com --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Jun 29 07:34:44 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08725 for ; Tue, 29 Jun 1999 07:34:43 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id D63B452DE; Tue, 29 Jun 1999 07:29:27 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 565CD52DD; Tue, 29 Jun 1999 07:29:26 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <199906291127.HAA08473@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: iptel@lists.research.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-iptel-glp-tbgp-01.txt Date: Tue, 29 Jun 1999 07:27:01 -0400 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk --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 : The IP Telephony Border Gateway Protocol(TBGP) Author(s) : D. Hampton, D. Oran, H. Salama, D. Shah Filename : draft-ietf-iptel-glp-tbgp-01.txt Pages : 14 Date : 28-Jun-99 This document presents the architecture of the IP Telephony Border Gateway Protocol (TBGP). TBGP is an inter-domain protocol, for routing voice calls through the IP network towards their destinations, which may be inside the IP network, IP destinations, or outside it, PSTN destinations. TBGP's operation is independent of any VoIP call signaling protocols (H.323, SIP, MGCP, ...), but it can serve as the call routing protocol for any of these signaling protocols. TBGP is based on the Border Gateway Protocol 4 (BGP-4). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-iptel-glp-tbgp-01.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-glp-tbgp-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-iptel-glp-tbgp-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990628150758.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-iptel-glp-tbgp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-iptel-glp-tbgp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990628150758.I-D@ietf.org> --OtherAccess-- --NextPart-- --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Jun 29 08:52:19 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10079 for ; Tue, 29 Jun 1999 08:52:19 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id BB7A752BB; Tue, 29 Jun 1999 07:25:20 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 348D252D5; Tue, 29 Jun 1999 07:25:20 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <199906291123.HAA08428@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: iptel@lists.research.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-iptel-glp-attribs-00.txt Date: Tue, 29 Jun 1999 07:23:08 -0400 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk --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 : Attributes for a Gateway Location Protocol Author(s) : J. Rosenberg, H. Salama, M. Squire Filename : draft-ietf-iptel-glp-attribs-00.txt Pages : 43 Date : 28-Jun-99 The Gateway Location Protocol (GLP) provides a mechanism for distributing and maintaining call routing tables between multiple internet telephony providers. GLP is currently under development by the iptel WG. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-iptel-glp-attribs-00.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-glp-attribs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-iptel-glp-attribs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990628150745.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-iptel-glp-attribs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-iptel-glp-attribs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990628150745.I-D@ietf.org> --OtherAccess-- --NextPart-- --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue Jun 29 11:55:58 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14065 for ; Tue, 29 Jun 1999 11:55:57 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 397B752D5; Tue, 29 Jun 1999 10:44:15 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id AF00A52DB; Tue, 29 Jun 1999 10:44:14 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <3778D86D.5D62D1EE@dnrc.bell-labs.com> Date: Tue, 29 Jun 1999 10:30:05 -0400 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: list iptel Subject: agenda and preparation for Oslo Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Folks, The following is the current agenda for the Oslo meeting: iptel Agenda 45th IETF Thursday, July 15 1300-1500 1. Agenda Bashing [Rosenberg] 5 mins 2. CPL Framework [Rosenberg] 5 mins 3. GLP Framework [Rosenberg] 5 mins 4. IN for SIP [Gurbani] 10 mins 5. GLP Attributes [Salama, Squire, Rosenberg] 1 hr 6. GLP Transport/Sync [Salama] 35 mins As you can see, we will be spending most of our time trying to make progress on the GLP issues. We will be briefly discussing the updating CPL framework and the GLP framework, mostly to see if there are any questions or comments. The GLP framework document is in last call, so this meeting will be your last chance for comments. An updated version will be submitted after the meeting, and IESG last call issued at that point, pending no major issues. We will also have a brief presentation from Vijay Gurbani on using IN to control SIP services. Its related to CPL, and I think may be of interest to the group. In preparation for this meeting, I expect attendees to have read the following drafts. All can be found on the iptel homepage http://www.bell-labs.com/mailing-lists/iptel/ or from the drafts archives: J. Rosenberg, H. Salama, M. Squire, "Attributes for a Gateway Location Protocol", draft-ietf-iptel-glp-attribs-00.txt Dave Hampton, Dave Oran, Hussein Salama, and Dhaval Shah, "The IP Telephony Border Gateway Protocol Architecture" (draft 1), draft-ietf-iptel-glp-tbgp-01.txt J. Rosenberg, H. Schulzrinne, "A Framework for a Gateway Location Protocol", (draft 3), draft-ietf-iptel-gwloc-framework-03.txt, J. Lennox, H. Schulzrinne, "Call Processing Language Framework and Requirements", draft-ietf-iptel-cpl-framework-00.{txt,ps,pdf} V. Gurbani, "Accessing IN services from SIP networks", draft-gurbani-iptel-sip-to-in-00.txt Thanks, Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Jun 30 04:29:31 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12382 for ; Wed, 30 Jun 1999 04:29:30 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id C6AB552E2; Wed, 30 Jun 1999 04:16:51 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 7F52B52E4; Wed, 30 Jun 1999 04:16:48 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <000701bec207$78775a40$05646464@hana.www.kornet.net> From: "=?euc-kr?B?yK3AzMau?=" To: Subject: SUBSCRIBE Date: Tue, 29 Jun 1999 17:14:53 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01BEC252.E79597C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0004_01BEC252.E79597C0 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 DQo= ------=_NextPart_000_0004_01BEC252.E79597C0 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBXMyBIVE1MLy9FTiI+DQo8SFRNTD4N CjxIRUFEPg0KDQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9a3NfY181NjAxLTE5 ODciIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgY29udGVudD0nIk1TSFRNTCA0Ljcy LjMxMTAuNyInIG5hbWU9R0VORVJBVE9SPg0KPC9IRUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZm Pg0KPERJVj4mbmJzcDs8L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0004_01BEC252.E79597C0-- --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Jun 30 11:20:06 1999 Received: from lists.research.bell-labs.com (H-135-180-161-172.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18609 for ; Wed, 30 Jun 1999 11:20:05 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 98F3B52DF; Wed, 30 Jun 1999 11:14:32 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 0C59852E3; Wed, 30 Jun 1999 11:14:31 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <377A347A.7F5B43A@dnrc.bell-labs.com> Date: Wed, 30 Jun 1999 11:15:06 -0400 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: list iptel Subject: Open Issue in GLP: Scope Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Folks, One of the major open issues of the GLP attributes document is scope. To date, we have two slightly different definitions of scope: 1. For 800 numbers, or other numbers which have global signficance (i.e., you can call them from anywhere), but are not unique, the scope is an attribute which almost extends the original number to make it unique. This scope could be a unique ID which has no real signficance other than being unique. But, in this case, if an LS receives two routes, both to the same numbers but with different scopes, which one should it use for routing calls? Perhaps some kind of semantic is required for the scope beyond uniqueness? 2. There is an enterprise customer with several locations. They use a private numbering plan, with some numbers in each location, and gateways in each location to reach those numbers. The enterprise customer would like to purchase IP telephony VPN service from a provider, so that the provider can route calls between the customers' locations. So, for this to work, the customer has an LS in each location which advertises the private prefixes in that location. These are then propagated through the provider's LS's (the provider itself may be a collection of ITAD's that have formed some kind of federation or something). So, this introduces a need for a scope to indicate that these private numbers are not callable from everywhere, but just from within the domains of the customer. The scope would also indicate that an LS in the provider domains should not advertise these prefixes into other customer domains. In this case, having the scope be some kind of customer identifier seems appropriate. So, the questions are: 1. do we see a need for cases 1 and/or 2? 2. If so, what should be the semantics of the scope in each case? -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Jun 30 12:29:54 1999 Received: from lists.research.bell-labs.com (H-135-180-161-172.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20388 for ; Wed, 30 Jun 1999 12:29:54 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id B50F352DB; Wed, 30 Jun 1999 12:25:22 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 287A252E0; Wed, 30 Jun 1999 12:25:22 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <19990630162400.15571.rocketmail@web123.yahoomail.com> Date: Wed, 30 Jun 1999 09:24:00 -0700 (PDT) From: Tom Gray Subject: Re: Open Issue in GLP: Scope To: Jonathan Rosenberg , list iptel MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk --- Jonathan Rosenberg wrote: > Folks, > > One of the major open issues of the GLP attributes > document is scope. To > date, we have two slightly different definitions of > scope: > ... > 1. do we see a need for cases 1 and/or 2? > 2. If so, what should be the semantics of the scope > in each case? > Case 1 and Case 2 may overlap in the case where a provider is providing multiple private networks each with its own private numbering plan which may contain overlapping numbers. Also, a customer may wish that home-based teleworkers be allowed to dial into its private network. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Jun 30 16:18:15 1999 Received: from lists.research.bell-labs.com (H-135-180-161-172.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26958 for ; Wed, 30 Jun 1999 16:18:14 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 1575752E4; Wed, 30 Jun 1999 16:12:52 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 69EA152E5; Wed, 30 Jun 1999 16:12:51 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <377A76E4.EB8FC9A@dnrc.bell-labs.com> Date: Wed, 30 Jun 1999 15:58:28 -0400 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Beatles Fan Cc: iptel@lists.research.bell-labs.com, rem-conf@es.net Subject: Re: H.225 Alerting Frames References: <19990630195216.19176.rocketmail@web116.yahoomail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit This question is probably best addressed by the h.323 implementors list (if someone can please provide it). -Jonathan R. Beatles Fan wrote: > > Hi, > > I am looking at the raw data in VoIP frames. In > particular H.225 frames. One particular frame > has Message Type set to Alerting. After the User > Info in the frame there are still 256 bytes that > have relevance. This is evident from the contents > of some of this raw data. It looks as if it is > setting something up on an Intel video phone. > > I have enclosed a decode of the frame below and > have marked off where my decoding of the H.225 > starts and ends. I am interested in the bytes > after the 02 00 (beginning with 03 00 01 00 08 02 etc.) > The ITUT H.225 spec says that Alerting frames > are defined as follows: > > Alerting-UUIE ::= SEQUENCE > { > protocolIdentifier ProtocolIdentifier, > destinationInfo EndpointType, > h245Address TransportAddress OPTIONAL, > ..., > callIdentifier CallIdentifier, > h245SecurityMode H245Security OPTIONAL, > tokens SEQUENCE OF ClearToken OPTIONAL, > cryptoTokens SEQUENCE OF CryptoH323Token OPTIONAL, > fastStart SEQUENCE OF OCTET STRING OPTIONAL, > } > > Here is where I lose it (thanks for bearing with me, it's > almost over). Taking the protocolIdentifier, the H.225 > spec defines it as follows: > > [skip some H.225] > ProtocolIdentifier ::= OBJECT IDENTIFIER > -- shall be set to > -- {itu-t (0) recommendation (0) h (8) 2250 -- > version (0) 2} > > So does this mean that there should be a 00 00 08 02 > following? I don't see a pattern like this anywhere > (although I see something close with 03 00 01 00 08 02). > > Am I missing something? Does PER come into play? > > ANY help is gratefully appreciated. Thank you - > > Chris > > Here's the frame data with the start of H.225 marked out > > 4B 95 FB C4 08 00 45 00 K.....E. > 01 3C 08 95 40 00 74 06 .<..@.t. > BE DC 86 86 F6 10 C0 A8 ........ > 01 0B 06 B8 04 13 00 63 .......c > 4C E6 00 02 50 B1 50 18 L...P.P. > 21 43 DD 50 00 00 08 02 !C.P.... <- H.225 starts w/ 08 02 > E8 C2 01 7E 00 0C 05 03 ...~.... > 00 06 00 08 91 4A 00 01 .....J.. > 02 00 03 00 01 00 08 02 ........ <- H.225 ends with 02 00 > E8 C2 07 04 04 88 18 80 ........ > A5 28 12 54 65 73 74 20 .(.Test > 43 61 6C 6C 20 49 6E 74 Call Int > 65 72 6E 65 74 7E 00 DA ernet~.. > 05 12 40 06 00 08 91 4A ..@....J > 00 01 00 86 86 F6 10 08 ........ > 08 22 C0 B5 00 80 80 11 ."...... > 49 6E 74 65 6C 20 56 69 Intel Vi > 64 65 6F 20 50 68 6F 6E deo Phon > 65 00 0E 32 2E 31 31 2E e..2.11. > 31 2E 37 2E 36 2E 31 2E 1.7.6.1. > 31 00 00 21 56 D8 B1 13 1..!V... > 12 D3 11 A3 B2 00 A0 C9 ........ > 27 5D 69 40 B5 00 80 80 ']i@.... > 80 88 76 69 64 62 6F 78 ..vidbox > 31 40 69 6E 74 65 6C 2E 1@intel. > 63 6F 6D 00 00 00 00 00 com..... > 00 00 00 00 00 00 00 00 ........ > 00 00 00 00 00 00 00 00 ........ > 00 00 00 00 00 00 00 00 ........ > 00 00 00 00 00 00 00 00 ........ > 00 00 00 00 00 00 00 00 ........ > 00 00 6C 64 61 70 2E 64 ..ldap.d > 69 72 65 63 74 2E 63 6F irect.co > 6E 6E 65 63 74 65 64 70 nnectedp > 63 2E 63 6F 6D 00 00 00 c.com... > 00 00 00 00 00 00 00 00 ........ > 00 00 00 00 00 00 00 00 ........ > 00 00 00 00 00 00 00 00 ........ > 00 00 00 00 00 00 00 00 ........ > 00 00 43 41 4C 4C 00 00 ..CALL.. > 00 00 .. > > TCP (Transmission Control Protocol) > Source Port = H225 (1720) > Dest Port = 1043 > Sequence Number = 6507750 > Acknowledgement = 151729 > Data Offset = 20 Octets > Control Flags = PSH,ACK > Window Size = 8515 > Checksum = DD50H > Urgent Pointer = 0 > No TCP Options > > H.225 Call Signalling > Discriminator = 8 > Call Ref Length = 2 > Message Sent = To Originator > Call Ref Value = 26818 > Message Type = Alerting > Info Element = User-User > User-User Length = 12 > Protocol Discrim = X.208 and X.209 > User Info = 0x0300060008914A00010200 > > Data Length = 256 Bytes > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > --------- > This message came from the IETF IPTEL Working Group Mailing List. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Jun 30 16:55:16 1999 Received: from lists.research.bell-labs.com (H-135-180-161-172.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28264 for ; Wed, 30 Jun 1999 16:55:15 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 003AA52E1; Wed, 30 Jun 1999 16:49:18 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6504752E6; Wed, 30 Jun 1999 16:49:17 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <19990630204905.16477.rocketmail@web112.yahoomail.com> Date: Wed, 30 Jun 1999 13:49:05 -0700 (PDT) From: Beatles Fan Subject: Re: H.225 Alerting Frames To: iptel@lists.research.bell-labs.com Cc: rem-conf@es.net MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Anybody have a name or URL? --- Jonathan Rosenberg wrote: > This question is probably best addressed by the h.323 > implementors list > (if someone can please provide it). > > -Jonathan R. > > Beatles Fan wrote: > > > > Hi, > > > > I am looking at the raw data in VoIP frames. In > > particular H.225 frames. One particular frame > > has Message Type set to Alerting. After the User > > Info in the frame there are still 256 bytes that > > have relevance. This is evident from the contents > > of some of this raw data. It looks as if it is > > setting something up on an Intel video phone. > > > > I have enclosed a decode of the frame below and > > have marked off where my decoding of the H.225 > > starts and ends. I am interested in the bytes > > after the 02 00 (beginning with 03 00 01 00 08 02 etc.) > > The ITUT H.225 spec says that Alerting frames > > are defined as follows: > > > > Alerting-UUIE ::= SEQUENCE > > { > > protocolIdentifier ProtocolIdentifier, > > destinationInfo EndpointType, > > h245Address TransportAddress OPTIONAL, > > ..., > > callIdentifier CallIdentifier, > > h245SecurityMode H245Security OPTIONAL, > > tokens SEQUENCE OF ClearToken OPTIONAL, > > cryptoTokens SEQUENCE OF CryptoH323Token OPTIONAL, > > fastStart SEQUENCE OF OCTET STRING OPTIONAL, > > } > > > > Here is where I lose it (thanks for bearing with me, it's > > almost over). Taking the protocolIdentifier, the H.225 > > spec defines it as follows: > > > > [skip some H.225] > > ProtocolIdentifier ::= OBJECT IDENTIFIER > > > -- shall be set to > > > -- {itu-t (0) recommendation (0) h (8) 2250 > > -- > > version (0) 2} > > > > So does this mean that there should be a 00 00 08 02 > > following? I don't see a pattern like this anywhere > > (although I see something close with 03 00 01 00 08 02). > > > > Am I missing something? Does PER come into play? > > > > ANY help is gratefully appreciated. Thank you - > > > > Chris > > > > Here's the frame data with the start of H.225 marked out > > > > 4B 95 FB C4 08 00 45 00 K.....E. > > 01 3C 08 95 40 00 74 06 .<..@.t. > > BE DC 86 86 F6 10 C0 A8 ........ > > 01 0B 06 B8 04 13 00 63 .......c > > 4C E6 00 02 50 B1 50 18 L...P.P. > > 21 43 DD 50 00 00 08 02 !C.P.... <- H.225 starts w/ 08 02 > > E8 C2 01 7E 00 0C 05 03 ...~.... > > 00 06 00 08 91 4A 00 01 .....J.. > > 02 00 03 00 01 00 08 02 ........ <- H.225 ends with 02 00 > > E8 C2 07 04 04 88 18 80 ........ > > A5 28 12 54 65 73 74 20 .(.Test > > 43 61 6C 6C 20 49 6E 74 Call Int > > 65 72 6E 65 74 7E 00 DA ernet~.. > > 05 12 40 06 00 08 91 4A ..@....J > > 00 01 00 86 86 F6 10 08 ........ > > 08 22 C0 B5 00 80 80 11 ."...... > > 49 6E 74 65 6C 20 56 69 Intel Vi > > 64 65 6F 20 50 68 6F 6E deo Phon > > 65 00 0E 32 2E 31 31 2E e..2.11. > > 31 2E 37 2E 36 2E 31 2E 1.7.6.1. > > 31 00 00 21 56 D8 B1 13 1..!V... > > 12 D3 11 A3 B2 00 A0 C9 ........ > > 27 5D 69 40 B5 00 80 80 ']i@.... > > 80 88 76 69 64 62 6F 78 ..vidbox > > 31 40 69 6E 74 65 6C 2E 1@intel. > > 63 6F 6D 00 00 00 00 00 com..... > > 00 00 00 00 00 00 00 00 ........ > > 00 00 00 00 00 00 00 00 ........ > > 00 00 00 00 00 00 00 00 ........ > > 00 00 00 00 00 00 00 00 ........ > > 00 00 00 00 00 00 00 00 ........ > > 00 00 6C 64 61 70 2E 64 ..ldap.d > > 69 72 65 63 74 2E 63 6F irect.co > > 6E 6E 65 63 74 65 64 70 nnectedp > > 63 2E 63 6F 6D 00 00 00 c.com... > > 00 00 00 00 00 00 00 00 ........ > > 00 00 00 00 00 00 00 00 ........ > > 00 00 00 00 00 00 00 00 ........ > > 00 00 00 00 00 00 00 00 ........ > > 00 00 43 41 4C 4C 00 00 ..CALL.. > > 00 00 .. > > > > TCP (Transmission Control Protocol) > > Source Port = H225 (1720) > > Dest Port = 1043 > > Sequence Number = 6507750 > > Acknowledgement = 151729 > > Data Offset = 20 Octets > > Control Flags = PSH,ACK > > Window Size = 8515 > > Checksum = DD50H > > Urgent Pointer = 0 > > No TCP Options > > > > H.225 Call Signalling > > Discriminator = 8 > > Call Ref Length = 2 > > Message Sent = To Originator > > Call Ref Value = 26818 > > Message Type = Alerting > > Info Element = User-User > > User-User Length = 12 > > Protocol Discrim = X.208 and X.209 > > User Info = 0x0300060008914A00010200 > > > > Data Length = 256 Bytes > > > > _________________________________________________________ > > Do You Yahoo!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > --------- > > This message came from the IETF IPTEL Working Group Mailing > List. > > -- > Jonathan D. Rosenberg Lucent Technologies > Member of Technical Staff 101 Crawfords Corner > Rd. > High Speed Networks Research Holmdel, NJ 07733 > FAX: (732) 834-5379 Rm. 4C-526 > EMAIL: jdrosen@bell-labs.com > URL: http://www.cs.columbia.edu/~jdrosen > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Jun 30 17:15:05 1999 Received: from lists.research.bell-labs.com (H-135-180-161-172.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28973 for ; Wed, 30 Jun 1999 17:15:04 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 22FB252E6; Wed, 30 Jun 1999 17:09:21 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 7A41E52E8; Wed, 30 Jun 1999 17:09:20 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: From: "Nancy-M Greene" To: iptel@lists.research.bell-labs.com, "'Beatles Fan'" Cc: rem-conf@es.net Subject: RE: H.225 Alerting Frames Date: Wed, 30 Jun 1999 17:04:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk The url for the archives is http://www.imtc.org/mail/h323implementors/1999/ and for list subscription instructions, send email to h323implementors-request@imtc.org with text "info" Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > ---------- > From: Beatles Fan[SMTP:fab4_fan@yahoo.com] > Sent: Wednesday, June 30, 1999 4:49 PM > To: iptel@lists.research.bell-labs.com > Cc: rem-conf@es.net > Subject: Re: H.225 Alerting Frames > > Anybody have a name or URL? > > --- Jonathan Rosenberg wrote: > > This question is probably best addressed by the h.323 > > implementors list > > (if someone can please provide it). > > > > -Jonathan R. > > > > Beatles Fan wrote: > > > > > > Hi, > > > > > > I am looking at the raw data in VoIP frames. In > > > particular H.225 frames. One particular frame > > > has Message Type set to Alerting. After the User > > > Info in the frame there are still 256 bytes that > > > have relevance. This is evident from the contents > > > of some of this raw data. It looks as if it is > > > setting something up on an Intel video phone. > > > > > > I have enclosed a decode of the frame below and > > > have marked off where my decoding of the H.225 > > > starts and ends. I am interested in the bytes > > > after the 02 00 (beginning with 03 00 01 00 08 02 etc.) > > > The ITUT H.225 spec says that Alerting frames > > > are defined as follows: > > > > > > Alerting-UUIE ::= SEQUENCE > > > { > > > protocolIdentifier ProtocolIdentifier, > > > destinationInfo EndpointType, > > > h245Address TransportAddress OPTIONAL, > > > ..., > > > callIdentifier CallIdentifier, > > > h245SecurityMode H245Security OPTIONAL, > > > tokens SEQUENCE OF ClearToken OPTIONAL, > > > cryptoTokens SEQUENCE OF CryptoH323Token OPTIONAL, > > > fastStart SEQUENCE OF OCTET STRING OPTIONAL, > > > } > > > > > > Here is where I lose it (thanks for bearing with me, it's > > > almost over). Taking the protocolIdentifier, the H.225 > > > spec defines it as follows: > > > > > > [skip some H.225] > > > ProtocolIdentifier ::= OBJECT IDENTIFIER > > > > > -- shall be set to > > > > > -- {itu-t (0) recommendation (0) h (8) 2250 > > > > -- > > > version (0) 2} > > > > > > So does this mean that there should be a 00 00 08 02 > > > following? I don't see a pattern like this anywhere > > > (although I see something close with 03 00 01 00 08 02). > > > > > > Am I missing something? Does PER come into play? > > > > > > ANY help is gratefully appreciated. Thank you - > > > > > > Chris > > > > > > Here's the frame data with the start of H.225 marked out > > > > > > 4B 95 FB C4 08 00 45 00 K.....E. > > > 01 3C 08 95 40 00 74 06 .<..@.t. > > > BE DC 86 86 F6 10 C0 A8 ........ > > > 01 0B 06 B8 04 13 00 63 .......c > > > 4C E6 00 02 50 B1 50 18 L...P.P. > > > 21 43 DD 50 00 00 08 02 !C.P.... <- H.225 starts w/ 08 02 > > > E8 C2 01 7E 00 0C 05 03 ...~.... > > > 00 06 00 08 91 4A 00 01 .....J.. > > > 02 00 03 00 01 00 08 02 ........ <- H.225 ends with 02 00 > > > E8 C2 07 04 04 88 18 80 ........ > > > A5 28 12 54 65 73 74 20 .(.Test > > > 43 61 6C 6C 20 49 6E 74 Call Int > > > 65 72 6E 65 74 7E 00 DA ernet~.. > > > 05 12 40 06 00 08 91 4A ..@....J > > > 00 01 00 86 86 F6 10 08 ........ > > > 08 22 C0 B5 00 80 80 11 ."...... > > > 49 6E 74 65 6C 20 56 69 Intel Vi > > > 64 65 6F 20 50 68 6F 6E deo Phon > > > 65 00 0E 32 2E 31 31 2E e..2.11. > > > 31 2E 37 2E 36 2E 31 2E 1.7.6.1. > > > 31 00 00 21 56 D8 B1 13 1..!V... > > > 12 D3 11 A3 B2 00 A0 C9 ........ > > > 27 5D 69 40 B5 00 80 80 ']i@.... > > > 80 88 76 69 64 62 6F 78 ..vidbox > > > 31 40 69 6E 74 65 6C 2E 1@intel. > > > 63 6F 6D 00 00 00 00 00 com..... > > > 00 00 00 00 00 00 00 00 ........ > > > 00 00 00 00 00 00 00 00 ........ > > > 00 00 00 00 00 00 00 00 ........ > > > 00 00 00 00 00 00 00 00 ........ > > > 00 00 00 00 00 00 00 00 ........ > > > 00 00 6C 64 61 70 2E 64 ..ldap.d > > > 69 72 65 63 74 2E 63 6F irect.co > > > 6E 6E 65 63 74 65 64 70 nnectedp > > > 63 2E 63 6F 6D 00 00 00 c.com... > > > 00 00 00 00 00 00 00 00 ........ > > > 00 00 00 00 00 00 00 00 ........ > > > 00 00 00 00 00 00 00 00 ........ > > > 00 00 00 00 00 00 00 00 ........ > > > 00 00 43 41 4C 4C 00 00 ..CALL.. > > > 00 00 .. > > > > > > TCP (Transmission Control Protocol) > > > Source Port = H225 (1720) > > > Dest Port = 1043 > > > Sequence Number = 6507750 > > > Acknowledgement = 151729 > > > Data Offset = 20 Octets > > > Control Flags = PSH,ACK > > > Window Size = 8515 > > > Checksum = DD50H > > > Urgent Pointer = 0 > > > No TCP Options > > > > > > H.225 Call Signalling > > > Discriminator = 8 > > > Call Ref Length = 2 > > > Message Sent = To Originator > > > Call Ref Value = 26818 > > > Message Type = Alerting > > > Info Element = User-User > > > User-User Length = 12 > > > Protocol Discrim = X.208 and X.209 > > > User Info = 0x0300060008914A00010200 > > > > > > Data Length = 256 Bytes > > > > > > _________________________________________________________ > > > Do You Yahoo!? > > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > --------- > > > This message came from the IETF IPTEL Working Group Mailing > > List. > > > > -- > > Jonathan D. Rosenberg Lucent Technologies > > Member of Technical Staff 101 Crawfords Corner > > Rd. > > High Speed Networks Research Holmdel, NJ 07733 > > FAX: (732) 834-5379 Rm. 4C-526 > > EMAIL: jdrosen@bell-labs.com > > URL: http://www.cs.columbia.edu/~jdrosen > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > --------- > This message came from the IETF IPTEL Working Group Mailing List. > --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Jun 30 17:22:22 1999 Received: from lists.research.bell-labs.com (H-135-180-161-172.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29154 for ; Wed, 30 Jun 1999 17:22:21 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 30FEA52E0; Wed, 30 Jun 1999 15:45:20 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8ED2F52E4; Wed, 30 Jun 1999 15:45:19 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <19990630195216.19176.rocketmail@web116.yahoomail.com> Date: Wed, 30 Jun 1999 12:52:16 -0700 (PDT) From: Beatles Fan Subject: H.225 Alerting Frames To: fab4_fan@yahoo.com Cc: iptel@lists.research.bell-labs.com, rem-conf@es.net MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hi, I am looking at the raw data in VoIP frames. In particular H.225 frames. One particular frame has Message Type set to Alerting. After the User Info in the frame there are still 256 bytes that have relevance. This is evident from the contents of some of this raw data. It looks as if it is setting something up on an Intel video phone. I have enclosed a decode of the frame below and have marked off where my decoding of the H.225 starts and ends. I am interested in the bytes after the 02 00 (beginning with 03 00 01 00 08 02 etc.) The ITUT H.225 spec says that Alerting frames are defined as follows: Alerting-UUIE ::= SEQUENCE { protocolIdentifier ProtocolIdentifier, destinationInfo EndpointType, h245Address TransportAddress OPTIONAL, ..., callIdentifier CallIdentifier, h245SecurityMode H245Security OPTIONAL, tokens SEQUENCE OF ClearToken OPTIONAL, cryptoTokens SEQUENCE OF CryptoH323Token OPTIONAL, fastStart SEQUENCE OF OCTET STRING OPTIONAL, } Here is where I lose it (thanks for bearing with me, it's almost over). Taking the protocolIdentifier, the H.225 spec defines it as follows: [skip some H.225] ProtocolIdentifier ::= OBJECT IDENTIFIER -- shall be set to -- {itu-t (0) recommendation (0) h (8) 2250 -- version (0) 2} So does this mean that there should be a 00 00 08 02 following? I don't see a pattern like this anywhere (although I see something close with 03 00 01 00 08 02). Am I missing something? Does PER come into play? ANY help is gratefully appreciated. Thank you - Chris Here's the frame data with the start of H.225 marked out 4B 95 FB C4 08 00 45 00 K.....E. 01 3C 08 95 40 00 74 06 .<..@.t. BE DC 86 86 F6 10 C0 A8 ........ 01 0B 06 B8 04 13 00 63 .......c 4C E6 00 02 50 B1 50 18 L...P.P. 21 43 DD 50 00 00 08 02 !C.P.... <- H.225 starts w/ 08 02 E8 C2 01 7E 00 0C 05 03 ...~.... 00 06 00 08 91 4A 00 01 .....J.. 02 00 03 00 01 00 08 02 ........ <- H.225 ends with 02 00 E8 C2 07 04 04 88 18 80 ........ A5 28 12 54 65 73 74 20 .(.Test 43 61 6C 6C 20 49 6E 74 Call Int 65 72 6E 65 74 7E 00 DA ernet~.. 05 12 40 06 00 08 91 4A ..@....J 00 01 00 86 86 F6 10 08 ........ 08 22 C0 B5 00 80 80 11 ."...... 49 6E 74 65 6C 20 56 69 Intel Vi 64 65 6F 20 50 68 6F 6E deo Phon 65 00 0E 32 2E 31 31 2E e..2.11. 31 2E 37 2E 36 2E 31 2E 1.7.6.1. 31 00 00 21 56 D8 B1 13 1..!V... 12 D3 11 A3 B2 00 A0 C9 ........ 27 5D 69 40 B5 00 80 80 ']i@.... 80 88 76 69 64 62 6F 78 ..vidbox 31 40 69 6E 74 65 6C 2E 1@intel. 63 6F 6D 00 00 00 00 00 com..... 00 00 00 00 00 00 00 00 ........ 00 00 00 00 00 00 00 00 ........ 00 00 00 00 00 00 00 00 ........ 00 00 00 00 00 00 00 00 ........ 00 00 00 00 00 00 00 00 ........ 00 00 6C 64 61 70 2E 64 ..ldap.d 69 72 65 63 74 2E 63 6F irect.co 6E 6E 65 63 74 65 64 70 nnectedp 63 2E 63 6F 6D 00 00 00 c.com... 00 00 00 00 00 00 00 00 ........ 00 00 00 00 00 00 00 00 ........ 00 00 00 00 00 00 00 00 ........ 00 00 00 00 00 00 00 00 ........ 00 00 43 41 4C 4C 00 00 ..CALL.. 00 00 .. TCP (Transmission Control Protocol) Source Port = H225 (1720) Dest Port = 1043 Sequence Number = 6507750 Acknowledgement = 151729 Data Offset = 20 Octets Control Flags = PSH,ACK Window Size = 8515 Checksum = DD50H Urgent Pointer = 0 No TCP Options H.225 Call Signalling Discriminator = 8 Call Ref Length = 2 Message Sent = To Originator Call Ref Value = 26818 Message Type = Alerting Info Element = User-User User-User Length = 12 Protocol Discrim = X.208 and X.209 User Info = 0x0300060008914A00010200 Data Length = 256 Bytes _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Jun 30 21:34:02 1999 Received: from lists.research.bell-labs.com (H-135-180-161-172.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04338 for ; Wed, 30 Jun 1999 21:34:01 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id C987D52E8; Wed, 30 Jun 1999 21:27:18 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 25E5C52E9; Wed, 30 Jun 1999 21:27:18 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <377AC296.8413F238@saga.com.br> Date: Wed, 30 Jun 1999 22:21:27 -0300 From: Reinaldo Penno Filho X-Mailer: Mozilla 4.6 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: iptel@lists.research.bell-labs.com Subject: QoS and GLP Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by mousse.gt-er.cg.org.br id WAA17597 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA04338 Sorry if this is a repetition, but I didn't receive may email.... ---------------------- Hi Folks, I've been out for a long time, but I would to add a few comments to the GLP attributes draft. I think there should a QoS non mandatory parameter in the spec. This QoS parameter would indicate to the EU what mechanisms for bandwidht reservation (RSVP,Diffserv, etc) does the network provide on the path till he reaches de Gateway. I think it would be a good ideia to insert a QoS parameter now rather to patch the spec later (if you agree of course). Making it non-mandatory would mean that if some LS wants to advertise this parameter, for example, to be more competitive fine, otherwise, just ommit it. There's a lot of parameters to help choose the best (or more adequate) gateway for a call, but few to help choose the best (or more adequate) path when the user is still in the IP network. best regards, Reinaldo -- ______________________________________ Universidade Federal do Rio de Janeiro Núcleo de Computação Eletrônica Instituto de Matemática email:reinaldo@lci.ufrj.br ______________________________________ --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Jun 30 21:44:15 1999 Received: from lists.research.bell-labs.com (H-135-180-161-172.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04665 for ; Wed, 30 Jun 1999 21:44:14 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 3FF5452F2; Wed, 30 Jun 1999 21:35:34 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9C91B52F1; Wed, 30 Jun 1999 21:35:33 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: From: "El-Gebaly, Hani" To: Beatles Fan , iptel@lists.research.bell-labs.com Cc: rem-conf@es.net Subject: RE: H.225 Alerting Frames Date: Wed, 30 Jun 1999 18:32:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Chris, Here is the info needed to join the implementers group: for list subscription instructions, send email to h323implementors-request@imtc.org with text "info" To answer your question, you are using a version 1 H.323 stack and hence the protocol identifier is 0, 0, 8, 2250, 0, 1. Here is a description of the alerting raw PDU and how it is decoded. I am not an ASN1 expert to explain why the fields are mapped that way but hope that helps. LAYER: Q931 RAW_PDU: - - - - - - - - RAW PDU - - - - - - - - 20 octets (hex output): 08 02 f6 59 01 7e 00 0c 05 03 00 06 00 08 91 4a 00 01 02 00 DECODED_PDU: - - - - - - - DECODED PDU - - - - - - - PDU_TYPE: Alerting Protocol Discriminator: 8 Call Reference: length (in octets): 2 value (in hex): 76 59 , flag: 1 - destination side User-user: length: 12 protocol discriminator: 5 h323_uu_pdu: alerting: protocolIdentifier: 0, 0, 8, 2250, 0, 1 destinationInfo: terminalInfo: cheers, Hani > -----Original Message----- > From: Beatles Fan > Sent: Wednesday, June 30, 1999 1:49 PM > To: iptel@lists.research.bell-labs.com > Cc: rem-conf@es.net > Subject: Re: H.225 Alerting Frames > > Anybody have a name or URL? > > --- Jonathan Rosenberg wrote: > > This question is probably best addressed by the h.323 > > implementors list > > (if someone can please provide it). > > > > -Jonathan R. > > > > Beatles Fan wrote: > > > > > > Hi, > > > > > > I am looking at the raw data in VoIP frames. In > > > particular H.225 frames. One particular frame > > > has Message Type set to Alerting. After the User > > > Info in the frame there are still 256 bytes that > > > have relevance. This is evident from the contents > > > of some of this raw data. It looks as if it is > > > setting something up on an Intel video phone. > > > > > > I have enclosed a decode of the frame below and > > > have marked off where my decoding of the H.225 > > > starts and ends. I am interested in the bytes > > > after the 02 00 (beginning with 03 00 01 00 08 02 etc.) > > > The ITUT H.225 spec says that Alerting frames > > > are defined as follows: > > > > > > Alerting-UUIE ::= SEQUENCE > > > { > > > protocolIdentifier ProtocolIdentifier, > > > destinationInfo EndpointType, > > > h245Address TransportAddress OPTIONAL, > > > ..., > > > callIdentifier CallIdentifier, > > > h245SecurityMode H245Security OPTIONAL, > > > tokens SEQUENCE OF ClearToken OPTIONAL, > > > cryptoTokens SEQUENCE OF CryptoH323Token OPTIONAL, > > > fastStart SEQUENCE OF OCTET STRING OPTIONAL, > > > } > > > > > > Here is where I lose it (thanks for bearing with me, it's > > > almost over). Taking the protocolIdentifier, the H.225 > > > spec defines it as follows: > > > > > > [skip some H.225] > > > ProtocolIdentifier ::= OBJECT IDENTIFIER > > > > > -- shall be set to > > > > > -- {itu-t (0) recommendation (0) h (8) 2250 > > > > -- > > > version (0) 2} > > > > > > So does this mean that there should be a 00 00 08 02 > > > following? I don't see a pattern like this anywhere > > > (although I see something close with 03 00 01 00 08 02). > > > > > > Am I missing something? Does PER come into play? > > > > > > ANY help is gratefully appreciated. Thank you - > > > > > > Chris > > > > > > Here's the frame data with the start of H.225 marked out > > > > > > 4B 95 FB C4 08 00 45 00 K.....E. > > > 01 3C 08 95 40 00 74 06 .<..@.t. > > > BE DC 86 86 F6 10 C0 A8 ........ > > > 01 0B 06 B8 04 13 00 63 .......c > > > 4C E6 00 02 50 B1 50 18 L...P.P. > > > 21 43 DD 50 00 00 08 02 !C.P.... <- H.225 starts w/ 08 02 > > > E8 C2 01 7E 00 0C 05 03 ...~.... > > > 00 06 00 08 91 4A 00 01 .....J.. > > > 02 00 03 00 01 00 08 02 ........ <- H.225 ends with 02 00 > > > E8 C2 07 04 04 88 18 80 ........ > > > A5 28 12 54 65 73 74 20 .(.Test > > > 43 61 6C 6C 20 49 6E 74 Call Int > > > 65 72 6E 65 74 7E 00 DA ernet~.. > > > 05 12 40 06 00 08 91 4A ..@....J > > > 00 01 00 86 86 F6 10 08 ........ > > > 08 22 C0 B5 00 80 80 11 ."...... > > > 49 6E 74 65 6C 20 56 69 Intel Vi > > > 64 65 6F 20 50 68 6F 6E deo Phon > > > 65 00 0E 32 2E 31 31 2E e..2.11. > > > 31 2E 37 2E 36 2E 31 2E 1.7.6.1. > > > 31 00 00 21 56 D8 B1 13 1..!V... > > > 12 D3 11 A3 B2 00 A0 C9 ........ > > > 27 5D 69 40 B5 00 80 80 ']i@.... > > > 80 88 76 69 64 62 6F 78 ..vidbox > > > 31 40 69 6E 74 65 6C 2E 1@intel. > > > 63 6F 6D 00 00 00 00 00 com..... > > > 00 00 00 00 00 00 00 00 ........ > > > 00 00 00 00 00 00 00 00 ........ > > > 00 00 00 00 00 00 00 00 ........ > > > 00 00 00 00 00 00 00 00 ........ > > > 00 00 00 00 00 00 00 00 ........ > > > 00 00 6C 64 61 70 2E 64 ..ldap.d > > > 69 72 65 63 74 2E 63 6F irect.co > > > 6E 6E 65 63 74 65 64 70 nnectedp > > > 63 2E 63 6F 6D 00 00 00 c.com... > > > 00 00 00 00 00 00 00 00 ........ > > > 00 00 00 00 00 00 00 00 ........ > > > 00 00 00 00 00 00 00 00 ........ > > > 00 00 00 00 00 00 00 00 ........ > > > 00 00 43 41 4C 4C 00 00 ..CALL.. > > > 00 00 .. > > > > > > TCP (Transmission Control Protocol) > > > Source Port = H225 (1720) > > > Dest Port = 1043 > > > Sequence Number = 6507750 > > > Acknowledgement = 151729 > > > Data Offset = 20 Octets > > > Control Flags = PSH,ACK > > > Window Size = 8515 > > > Checksum = DD50H > > > Urgent Pointer = 0 > > > No TCP Options > > > > > > H.225 Call Signalling > > > Discriminator = 8 > > > Call Ref Length = 2 > > > Message Sent = To Originator > > > Call Ref Value = 26818 > > > Message Type = Alerting > > > Info Element = User-User > > > User-User Length = 12 > > > Protocol Discrim = X.208 and X.209 > > > User Info = 0x0300060008914A00010200 > > > > > > Data Length = 256 Bytes > > > > > > _________________________________________________________ > > > Do You Yahoo!? > > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > --------- > > > This message came from the IETF IPTEL Working Group Mailing > > List. > > > > -- > > Jonathan D. Rosenberg Lucent Technologies > > Member of Technical Staff 101 Crawfords Corner > > Rd. > > High Speed Networks Research Holmdel, NJ 07733 > > FAX: (732) 834-5379 Rm. 4C-526 > > EMAIL: jdrosen@bell-labs.com > > URL: http://www.cs.columbia.edu/~jdrosen > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > --------- > This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed Jun 30 21:57:52 1999 Received: from lists.research.bell-labs.com (H-135-180-161-172.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05384 for ; Wed, 30 Jun 1999 21:57:51 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 4898152E5; Wed, 30 Jun 1999 21:51:16 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 93F8B52EA; Wed, 30 Jun 1999 21:51:15 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <377AC63A.2FA30D36@dnrc.bell-labs.com> Date: Wed, 30 Jun 1999 21:36:58 -0400 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Reinaldo Penno Filho Cc: iptel@lists.research.bell-labs.com Subject: Re: QoS and GLP References: <377AC296.8413F238@saga.com.br> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Reinaldo Penno Filho wrote: > > I think there should a QoS non mandatory parameter in the spec. This QoS > > parameter would indicate to the EU what mechanisms for bandwidht > reservation > (RSVP,Diffserv, etc) does the network provide on the path till he > reaches de > Gateway. I think it would be a good ideia to insert a QoS parameter now > rather to patch the spec later (if you agree of course). We have discussed ideas similar to this one in the past. The problem is that the signaling and media paths are different and completely independent. An LS will, in general, have no idea what QoS mechanisms are supported along the media path. Handling of media across administrative boundaries is best left to devices like diffserv boundary routers and COPS servers which sit along the media path. The best we could do would be to indicate the QoS mechanism supported in the ISP (not ITAD, which may or may not be the same organization) of the gateway itself. Not sure this helps much, and anyway its impossible to aggregate. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List.