- sg16-avd - lists.packetizer.com

Re: VoIP QOS!
by Kevin Davis 05 Mar '99

05 Mar '99

J.Aridaman wrote: >>Please do not include me in further e-mails. 1) If you wish to unsubscribe from the SG16 mail list, this is not how to do it. 2) If you wish the VoIP QoS discussion to discontinue using the SG16 list, this has already been established 3) Joon has already setup a mail list for the discussion >Hi! To subscribe H.323/VoIP QoS Activity Group, please send mail >to majordomo(a)majordomo.vtel.com with a command line >subscribe h323_voip_qos your email address >in the body of the message

1 0

Re: Invitation via Gatekeeper
by Roy, Radhika R, ALCOO 05 Mar '99

05 Mar '99

This was my understanding as well. Does anyone disagree with Gary? Regards, Radhika ------------------------------------------- Radhika R. Roy AT&T Labs Room C1-2B03 200 Laurel Avenue S. Middletwon, NJ 07748 USA + 1 732 420 1580 Tel rrroy(a)att.com > -----Original Message----- > From: Gary A. Thom [SMTP:gthom@DELTA-INFO.COM] > Sent: Friday, March 05, 1999 11:18 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Invitation via Gatekeeper > > I have this minor semantic clarification: > > > 2. I disagree with Linh's assertion that "an MC never sends ARQ". If I > am > > administering an MCU which can initiate conferences by calling up a list > of > > participants at a given time, I will certainly require that MCU to apply > to > > its gatekeeper for permission to make these calls. > > In the particular case under discussion, E2/its MC certainly has to send > > ARQ. It is going to make a call, which will result in data flowing its > > gatekeeper's zone, and which may end up costing money. > > The original idea was that only endpoints send ARQ. An MC is not an > endpoint, however, it is a > functional element which can be contained in an endpoint (such is the case > of an MCU or a terminal > which contains an MC). So even though the endpoint contains an MC, it is > the endpoint which is > sending the ARQ not the MC functional element. > > If an MC exists in the Gatekeeper, I do not beleive that that MC will ever > send ARQ for any of the > connections in the conference. Only the endpoints in that conference will > send ARQ to their > Gatekeepers. > > > Gary > ------------------------------------------------------ > Name : Gary A. Thom > Company: Delta Information Systems, Inc. > Address: 300 Welsh Rd., Bldg 3 > Horsham, PA 19044 USA > Phone : +1-215-657-5270 Fax : +1-215-657-5273 > E-mail : gthom(a)delta-info.com > ------------------------------------------------------

1 0

Re: BT change of representative
by Roy, Radhika R, ALCOO 05 Mar '99

05 Mar '99

Hi Pete, I like to extend my sincere thanks for your great contributions in SG16 especially related to H.323. I am sure that all of us will miss you because you may not be involved with H.323. Hope for the best in your new venture! Sincerely, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com > -----Original Message----- > From: Pete Cordell [SMTP:pete.cordell@BT-SYS.BT.CO.UK] > Sent: Wednesday, March 03, 1999 3:32 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: BT change of representative > > Dear All, > > As you may know by know, I am moving on to own little venture. In case > you were wondering, it doesn't involve H.323!!! > > This does mean that I will not be representing BT any more in SG16. > This role will probably be taken over by Morgan Potter at > morgan.potter(a)bt.com, so if you have any questions from BT he is the one > to ask. Also Mike should be able to help. > > I would like to take this opportunity to say that, despite the hard > work, I have enjoyed my time working with you and I wish you all the > best. And, who knows, perhaps we'll meet again in the future - If you > get back to Ipswich sometime on your travels, then look me up (assuming > the Rapporteurs give you time to get out the meetings!). > > Regards, > > Pete > ================================= > Pete Cordell > BT Labs > E-Mail: pete.cordell(a)bt-sys.bt.co.uk > Tel: +44 1473 646436 > Fax: +44 1473 645499 > =================================

1 0

Re: Invitation via Gatekeeper
by Truong Hong-Linh 04 Mar '99

04 Mar '99

Chris and Soo, my comments are inserted below (and marked with <Linh>). Hope, they help clarify the scenario you are looking for. Linh --- TRUONG Hong Linh hlt(a)zurich.ibm.com IBM Zurich Research Laboratory tel : +41 1 724 8434 CH-8803 Rueschlikon / Switzerland fax : +41 1 724 8955 _______________________________________________ Soo, Yes, it is splendidly unclear, isn't it? > I tried to get answer from implementors group and some other > person, but I couldn't get any satisfiable answer. > > My question is here. > > In section 8.4.3.2(Figure 28/H.323-Non-MC invite signalling), It's worth mentioning which standard here. For the benefit of anyone needing to catch up, we're talking about H.323. > when an > endpoint(E1) which do not have active MC wants to invite other > endpoint(E3), does E1 send an ARQ to its Gatekeeper for the invite or > does E2 send the ARQ to its gatekeeper, or do both of them send ARQ's? I would suggest that both ought to send ARQs. Both are logically setting up calls, so both need to ask permission. However, E1's ARQ need ask for no bandwidth as none will be used on the call between it and E2. <Linh> Here I think we have to distinguish carefully between an endpoint and an MC (what the current H.323 achieves very badly!). In the above scenario, the MC is hosted in the same device as E2 and E1 is sending the SETUP message to the MC and not to E2 (H.323 Figure 28-30 are misleading, because they only show E2 and not the MC!). Therefore, IMO only E1 has to send an ARQ, not E2, and an MC never sends ARQ! > And, when Gatekeeper doesn't know which endpoint has active MC in any > conference, what should Gatekeeper do if it receives ARQ(for > invitation) > from an endpoint which do not have active MC? I mean, if Gatekeeper > receives ARQ from E1, what should Gatekeeper do? Does Gatekeeper send > ACR with E2's CallTransportAddress instead of E3's > CallTransportAddress? E1's gatekeeper can conceivably spot that invite is probably what's wanted, by matching up conferenceIDs, although there's nothing in the ARQ message to say directly that invite is the desired outcome. The gatekeeper certainly MUST return the address to which E1 should send its Setup message, so in the direct-routed model that will be E2. However, a non-routing gatekeeper will have no way of knowing where the active MC is. I believe this is a genuine "hole" in the standard. Linh, I know you've implemented some of this stuff: how do you get around this? <Linh>The point here is in general the GK does not (and needs not) know where the MC is actually located! It therefore, in response to the ARQ sent by E1, returns the transport address of either E3 (direct model) or itself (GK-routed model). In both cases, E1 has to send its SETUP message to the MC (which is in our specific scenario colocated with E2).Then the MC will relay that message to either E3 or the GK, depending on which transport address is included in the SETUP message sent by E1. Regards, Chris -- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. ENGLAND Phone: +44 1753 661 359 email: cpurvis(a)madge.com

2 1

Re: H.323/VoIP QoS
by Tom-PT Taylor 04 Mar '99

04 Mar '99

> -----Original Message----- > From: Ying, Wen-Ping [SMTP:wen-ping.ying@ATTWS.COM] > Sent: Thursday, March 04, 1999 3:35 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323/VoIP QoS > [[TomT]] snip... > 7. transport efficiency - concerns about header overhead that triggers > the > proposed solution hop2hop header compression (rfc-2508) and the recent > work > in MEGACO regarding g.729/udp/rtp/ip/atm & g.729/aal2/atm interworking. > [[TomT]] Sorry, [[TomT]] we've discussed a lot of things on the MEGACO list, but not this.

1 0

Please ignore RE: H.GCP Audio Call
by Bryan Hill 04 Mar '99

04 Mar '99

Please ignore the previous mail, I was still writing up today minutes and the message was sent accidentally (fat finger. . . ) -----Original Message----- From: Bryan Hill [SMTP:bhill@VIDEOSERVER.COM] Sent: Thursday, March 04, 1999 5:00 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: H.GCP Audio Call The H.GCP audio call was held today, 18 ports called in including a group from the TIPHON meeting. The working model =============== Individuals have will be working up submissions to be review by the entire group at the next audio call. The objective is that the principals involved will collaborate off line initially, post the results to the SG16 reflector for comments and a final version will be posted for discussion in an audio call. The result of that final review will be added into the H.GCP by the editor. Every effort will be made to resolve issues but if they cannot they must be presented in Santiago. Work items =============== The following work items were identified and individuals who expressed an interest in working on them are noted. -----Original Message----- From: Bryan Hill [SMTP:bhill@VIDEOSERVER.COM] Sent: Monday, March 01, 1999 2:37 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: H.GCP Audio Call Colleagues, I would like to invite you to participate in audio call on Thursday March 4th from 11AM until 1PM EST to discuss H.GCP. The call details are as follows: Calls from outside the US: 312-470-7273 Calls from within the US: 888-847-7598 Passcode: BryanHill Confirmation number: 5193957 Please respond to me directly to reserve a port for this call (where ever possible please try to minimize port requirements by sharing a port with a colleague). The main purpose of this initial call will be to review requirements and terminology for H.GCP which were discussed in Monterey. I have been editing these sections and will make them available on the ptel SG16 ftp site no later than tomorrow 3/2. The second purpose of the call is to identify other areas that need to be discussed in subsequent audio calls. An initial pass of topics is listed below. I would like to solicit volunteers to submit written contribution in each of the areas identified and use these submissions as a basis for discussing topics in future audio calls. In this manner I hope to scope our discussion to specific technical topics and combine the benefits from MDCP and MGCP approaches into H.GCP. 1) Control model a) Controller to gateway associations b) Controller to internal gateway entity associations c) Failover d) Security 2) Connection model a) Controllable entities b) Controllable entity properties 3) Commands a) Types b) Parameters c) Acknowledgement styles/sequencing 4) Messages (i.e.-command packaging) 5) Message Encoding 6) Resource management 7) Scripting/Packages 8) Interface C protocol (Q.931/Q.764) 9) Interface B protocol (Q.931 ) Best Regards, Bryan _________________________________________________________ Bryan Hill VideoServer Inc. (781) 505-2159 <mailto:bhill@videoserver.com>

1 0

Re: H.GCP Audio Call
by Bryan Hill 04 Mar '99

04 Mar '99

The H.GCP audio call was held today, 18 ports called in including a group from the TIPHON meeting. The working model =============== Individuals have will be working up submissions to be review by the entire group at the next audio call. The objective is that the principals involved will collaborate off line initially, post the results to the SG16 reflector for comments and a final version will be posted for discussion in an audio call. The result of that final review will be added into the H.GCP by the editor. Every effort will be made to resolve issues but if they cannot they must be presented in Santiago. Work items =============== The following work items were identified and individuals who expressed an interest in working on them are noted. -----Original Message----- From: Bryan Hill [SMTP:bhill@VIDEOSERVER.COM] Sent: Monday, March 01, 1999 2:37 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: H.GCP Audio Call Colleagues, I would like to invite you to participate in audio call on Thursday March 4th from 11AM until 1PM EST to discuss H.GCP. The call details are as follows: Calls from outside the US: 312-470-7273 Calls from within the US: 888-847-7598 Passcode: BryanHill Confirmation number: 5193957 Please respond to me directly to reserve a port for this call (where ever possible please try to minimize port requirements by sharing a port with a colleague). The main purpose of this initial call will be to review requirements and terminology for H.GCP which were discussed in Monterey. I have been editing these sections and will make them available on the ptel SG16 ftp site no later than tomorrow 3/2. The second purpose of the call is to identify other areas that need to be discussed in subsequent audio calls. An initial pass of topics is listed below. I would like to solicit volunteers to submit written contribution in each of the areas identified and use these submissions as a basis for discussing topics in future audio calls. In this manner I hope to scope our discussion to specific technical topics and combine the benefits from MDCP and MGCP approaches into H.GCP. 1) Control model a) Controller to gateway associations b) Controller to internal gateway entity associations c) Failover d) Security 2) Connection model a) Controllable entities b) Controllable entity properties 3) Commands a) Types b) Parameters c) Acknowledgement styles/sequencing 4) Messages (i.e.-command packaging) 5) Message Encoding 6) Resource management 7) Scripting/Packages 8) Interface C protocol (Q.931/Q.764) 9) Interface B protocol (Q.931 ) Best Regards, Bryan _________________________________________________________ Bryan Hill VideoServer Inc. (781) 505-2159 <mailto:bhill@videoserver.com>

1 0

Re: H.323/VoIP QoS (further to Randy Bloomfield's note)
by Demosthenes Kostas 04 Mar '99

04 Mar '99

Could you translate it for some of us that don't read French Kannst du nicht allen gefallen durch deine That und dein Kunstwerk -- mach es wenigen recht, vielen gefallen ist schlimm" -- Schiller --------------------------------------------- Demosthenes Kostas PhD/MBA Manager-Industry Standards GTE 700 Hidden Ridge, HQW02J85 Irving, TX 75038 (972) 718-6291 FAX: (972) 718-4393 Internet: demos.kostas(a)telops.gte.com ------------- Original Text From: "Christian Kuhtz" <ck(a)ns1.adsu.bellsouth.com>, on 3/3/99 4:14 PM: Eric, I think the purpose of this group is to discuss and explore ways of providing IP QoS for VoIP networks, and to evaluate applicable existing technology as well as provide feedback for emerging technology. I don't quite understand why we need a managed membership committee to run this -- particularly the managed membership part is what I find troubling. What benefit are you providing? Personally, I find this difficult to define, because you are obviously not the premier forum for IP related issues (the IETF is). Please explain. So, if you're affiliated with the IETF, why don't you participate in our working group rather than we move our IP network related issues into T1? And, was it really neccessary to carbon copy over half a dozen mailing lists on this subject matter? Thanks in advance. Cheers, Chris -- "Kannst du nicht allen gefallen durch deine That und dein Kunstwerk -- mach es wenigen recht, vielen gefallen ist schlimm" -- Schiller [Disclaimer: I speak for myself and my views are my own and not in any way to be construed as the views of BellSouth Corporation. ] *

1 0

FW: H.323/VoIP QoS
by Malcolm McDonald 04 Mar '99

04 Mar '99

Joon, Please include me in the QoS discussions. Thanks, Malcolm 561 989-2312 malcolm(a)netspeak.com http://www.netspeak.com

1 0

Re: H.323/VoIP QoS
by Ying, Wen-Ping 04 Mar '99

04 Mar '99

Joon, I am a bit confused by the charter of this proposed group, but in general, I am very interested in having a place to discuss generic QoS issues related to voice over a packet data network. Are you planning to include the following topics in your proposed group discussion? 1. VoIP flow reserving resource (flow based RSVP interacting with QoS aware switch/router , SLA based diffserv, SLA based MPLS) - will this group be recommending the model, or will it discuss the pros/cons or interoperability? 2. switch/router resource mgmt (MPLS, Constrained-Based MPLS, diffserv, etc.) - ditto 3. Control of the resource allocation (GK/GW/H.323 endpoints) - problems such as GK granting the bandwidth without having the real control on actual usage (bandwidth mgmt with collaboration from many components.) 4. speech coding/quality - encourage single LBRV to reduce transcoding. 5. absolute delay control. 6. echo cancellation problem with the existence of large jitter. 7. transport efficiency - concerns about header overhead that triggers the proposed solution hop2hop header compression (rfc-2508) and the recent work in MEGACO regarding g.729/udp/rtp/ip/atm & g.729/aal2/atm interworking. Regards, Wen-Ping Ying AT&T Wireless Services PO Box 97059 Redmond, WA 98073 Voice 425-702-2725 Fax 425-702-2568 wying(a)att.com wen-ping.ying(a)attws.com > -----Original Message----- > From: Joon Maeng [SMTP:Joon_Maeng@VTEL.COM] > Sent: Wednesday, March 03, 1999 8:40 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.323/VoIP QoS > > Greetings! My name is Joon Maeng. I work for VTEL Corp in USA. I've > talked to > several companies while I was attending ITU and IETF meetings about > establishing > an ad-hoc group to address QoS (Quality of Service) issues in TRANSPORTING > REAL-TIME TRAFFICS in the packet switched network, especially in the IP > network. > I was very encouraged by responses from those companies. Most of them > agreed > that lack of QoS support for real-time traffics was one of major barriers > in > deploying H.323/VoIP products and the H.323 industry would benefit by > having a > QoS activity group. I would like to ask if your company would be > interested in > the activities described in the following: > > Proposed name of the group: H.323/VoIP QoS Activity Group. > > Motivation: ITU defined a good conference standard, H.323, for the packet > network. IETF is actively defining QoS standards for the IP network. The > deployment of H.323/VoIP products has been slow partially due to lack of > QoS > supports in current IP network. The H.323/VoIP industry shall work > together to > access the issues and provide solutions for the users. > > Proposed charter of the group: > - Assess QoS issues in transporting real-time traffics (calls with > long-duration > compared to web-access) in the IP network, > - Find the solutions to resolve issues, > - Execute solutions via various processes such as building consensus on > various > QoS solutions among participants, > submitting recommendations to standardization bodies if needed, and > facilitating inter-operablity testing between QoS standards and > application > standards, > - and education, promotion, etc. > > I would expect the final charter and the structure of the group will be > determined by the participants and their interests. I would say that > everything is open at this time except that the industry shall look at the > QoS > issues seriously for real-time traffics. I'd like to clarify that the > proposed > group is not a group to standardize the QoS. It is a group or a forum > that is > interested in helping and promoting the real-time QoS for H.323/VoIP > industry > through various methods (to be determined). I plan to set up an email > reflector for the initial discussions among participants and decide the > following steps based on the discussions. Please email me (joon_maeng@ > vtel.com) > if you and your company would be interested in joining the initial talks > via > email reflector. Your comments and suggestions will be greatly > appreciated. > Regards, > Joon

1 0

Re: H.323/VoIP QoS (further to Randy Bloomfield's note)
by Tony.Pillai＠TELLABS.COM 04 Mar '99

04 Mar '99

Please do not include me in your future e-mails. -----Original Message----- From: ehauch Sent: Wednesday, March 03, 1999 3:50 PM To: Joon.Maeng Cc: ehauch; diff-serv-interest; h323implementors; interwkg; voip; int-serv; neal; ITU-SG16; t1a12; t1a15; mpls Subject: Re: H.323/VoIP QoS (further to Randy Bloomfield's note) Joon, My name is Eric Hauch. I am the current Ad Hoc Group leader for a Working Group T1A1.5 activity that appears to closely parallel your initiative. Committee T1 (of which TSC T1A1 is part) is an open standards forum sponsored by the Alliance for Telecommunications Industry Solutions (ATIS) and accredited by the American National Standards Institute (ANSI). As such, Committee T1 is the ANSI authority in the United States for defining telecommunications interface and performance standards. Committee T1 TSC's are also a key source of research and advice to the US State Department's delegations to the ITU - and have formal liaisons with the IETF. The current Ad Hoc Group work on defining multimedia performance requirements for business quality conferences carried over IP based networks is part of addressing these standards setting responsibilities. We very much share the reasons you state for needing these QoS standards soon. The work of the MMoIP Ad Hoc Group is about 60% complete (i.e. we're just over half way to making a recommendation to send our draft standard to T1 letter ballot). The last Ad Hoc group conference call was Feb 25, 99 - the next, Apr 1, 99. Attendance and participation in any T1 activity is completely open. Voting at the TSC and T1 levels is by membership (for example, VTel is a member of T1A1). You can find out more about TSC T1A1, WG T1A1.5 and the Ad Hoc Group activities (through the posted documentation) at www.t1.org. As past chair of WG T1A1.5, I have enjoyed VTel's excellent past contributions to our efforts and have been very supportive and encouraging of VTel's particpation in this particular Ad Hoc group. To the extent your initiative indicates a renewed interest on your part and others in your industry segment, I am delighted - and encourage and welcome all of you to work with us. I'll look forward to hearing from you, Eric G. Hauch Vice-Chair T1A1 615-532-2365 ehauch(a)mail.state.tn.us >>> "Joon Maeng" <Joon_Maeng(a)vtel.com> 03/03 10:40 AM >>> Greetings! My name is Joon Maeng. I work for VTEL Corp in USA. I've talked to several companies while I was attending ITU and IETF meetings about establishing an ad-hoc group to address QoS (Quality of Service) issues in TRANSPORTING REAL-TIME TRAFFICS in the packet switched network, especially in the IP network. I was very encouraged by responses from those companies. Most of them agreed that lack of QoS support for real-time traffics was one of major barriers in deploying H.323/VoIP products and the H.323 industry would benefit by having a QoS activity group. I would like to ask if your company would be interested in the activities described in the following: Proposed name of the group: H.323/VoIP QoS Activity Group. Motivation: ITU defined a good conference standard, H.323, for the packet network. IETF is actively defining QoS standards for the IP network. The deployment of H.323/VoIP products has been slow partially due to lack of QoS supports in current IP network. The H.323/VoIP industry shall work together to access the issues and provide solutions for the users. Proposed charter of the group: - Assess QoS issues in transporting real-time traffics (calls with long-duration compared to web-access) in the IP network, - Find the solutions to resolve issues, - Execute solutions via various processes such as building consensus on various QoS solutions among participants, submitting recommendations to standardization bodies if needed, and facilitating inter-operablity testing between QoS standards and application standards, - and education, promotion, etc. I would expect the final charter and the structure of the group will be determined by the participants and their interests. I would say that everything is open at this time except that the industry shall look at the QoS issues seriously for real-time traffics. I'd like to clarify that the proposed group is not a group to standardize the QoS. It is a group or a forum that is interested in helping and promoting the real-time QoS for H.323/VoIP industry through various methods (to be determined). I plan to set up an email reflector for the initial discussions among participants and decide the following steps based on the discussions. Please email me (joon_maeng@ vtel.com) if you and your company would be interested in joining the initial talks via email reflector. Your comments and suggestions will be greatly appreciated. Regards, Joon << File: Re_ H.TXT >>

1 0

Re: question: asn.1
by Derks, Frank 04 Mar '99

04 Mar '99

Hi Jihye, try: http://www-sop.inria.fr/rodeo/personnel/hoschka/asn1.html to get an overview of ASN.1 products. The OSS ( http://www.oss.com) ASN.1 compiler, which is commercial, support the packed encoding rules, which are required for H.323. Frank -----Original Message----- From: pjh [mailto:pjh@DESKVIEW.NADA.CO.KR] Sent: 04 March 1999 10:55 To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: question: asn.1 Dear ITU-SG16 experts I am searching for commercial or free ASN.1 compiler . Further details are as follows: Features: o ASN.1 to C or C++ source code compiler ( A run-time version of the source code is available) o Fully supports ASN.1:1997 o Library of low-level PER encode/decode functions o Compiler has been tested on following RealTime OS: pSOS, vxWorks, Ets kernel If you are using ASN.1 compiler on RealTime OS, Please let me know where I get it. Please reply to this E-Mail Sincerely, Jihye Park(Miss) Nada Research Co., Ltd. Seoul 137-070 , Korea Tel: 82-2-525-3941 Fax: 82-2-525-3945 pjh(a)deskview.nada.co.kr < mailto:pjh@deskview.nada.co.kr>

2 1

who
by Keith Kelly 04 Mar '99

04 Mar '99

who Keith C. Kelly VP Emerging Technologies and Standards ___________________ keith(a)netspeak.com NetSpeak Corporation 902 Clint Moore Rd. Suite 104 Boca Raton, FL 33487 Direct:(561) 998-8752 Pager (800) 946-4645 #1441506 Main: (561) 998-8700 Fax (561) 997-2401 http://www.netspeak.com The Art of Sound Communication ==================================================================== Privacy and Confidentiality Notice The information contained in this transmission is intended for the above-named recipient(s) only and contains privileged and confidential information. If the reader of this message is not an intended recipient, you are strictly prohibited from using, copying, distributing, or taking any action in reliance on such information. If you have received this communication in error, please notify us immediately.

1 0

Subscribe
by Keith Kelly 04 Mar '99

04 Mar '99

subscribe Keith C. Kelly VP Emerging Technologies and Standards ___________________ keith(a)netspeak.com NetSpeak Corporation 902 Clint Moore Rd. Suite 104 Boca Raton, FL 33487 Direct:(561) 998-8752 Pager (800) 946-4645 #1441506 Main: (561) 998-8700 Fax (561) 997-2401 http://www.netspeak.com The Art of Sound Communication ==================================================================== Privacy and Confidentiality Notice The information contained in this transmission is intended for the above-named recipient(s) only and contains privileged and confidential information. If the reader of this message is not an intended recipient, you are strictly prohibited from using, copying, distributing, or taking any action in reliance on such information. If you have received this communication in error, please notify us immediately.

1 0

Re: VoIP QOS!
by Jain, Aridaman K (Aridaman) 04 Mar '99

04 Mar '99

Please do not include me in further e-mails. > ---------- > From: long keping[SMTP:lkp@bupt.edu.cn] > Reply To: long keping > Sent: Thursday, March 04, 1999 2:52 PM > To: Joon_Maeng(a)vtel.com > Cc: mpls(a)UU.NET; ITU-SG16(a)mailbag.cps.intel.com; voip(a)imtc.org; > interwkg(a)imtc.org; h323implementors(a)imtc.org; 'T1A1.2 e-mail reflector'; > diff-serv-interest(a)BayNetworks.COM; int-serv(a)isi.edu > Subject: VoIP QOS! > > Joon, > > please include me in any further discussions. > > thanks > > Long keping > lkp(a)bupt.edu.cn >

1 0

Re: About itu-t files?
by Derks, Frank 04 Mar '99

04 Mar '99

Hi Li, from the ITU-T of course! These documents are not freely available. Check: http://www.itu.ch. Frank -----Original Message----- From: Li Jing [mailto:lijing@CN-WHNEC.CCGW.NEC.CO.JP] Sent: 04 March 1999 08:44 To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: About itu-t files? Please tell me where can I get full files about Recommendation G.XXX ? Thanks a lot!

1 0

Re: Invitation via Gatekeeper
by Chris Purvis 04 Mar '99

04 Mar '99

Soo, Yes, it is splendidly unclear, isn't it? > I tried to get answer from implementors group and some other > person, but I couldn't get any satisfiable answer. > > My question is here. > > In section 8.4.3.2(Figure 28/H.323-Non-MC invite signalling), It's worth mentioning which standard here. For the benefit of anyone needing to catch up, we're talking about H.323. > when an > endpoint(E1) which do not have active MC wants to invite other > endpoint(E3), does E1 send an ARQ to its Gatekeeper for the invite or > does E2 send the ARQ to its gatekeeper, or do both of them send ARQ's? I would suggest that both ought to send ARQs. Both are logically setting up calls, so both need to ask permission. However, E1's ARQ need ask for no bandwidth as none will be used on the call between it and E2. > And, when Gatekeeper doesn't know which endpoint has active MC in any > conference, what should Gatekeeper do if it receives ARQ(for > invitation) > from an endpoint which do not have active MC? I mean, if Gatekeeper > receives ARQ from E1, what should Gatekeeper do? Does Gatekeeper send > ACR with E2's CallTransportAddress instead of E3's > CallTransportAddress? E1's gatekeeper can conceivably spot that invite is probably what's wanted, by matching up conferenceIDs, although there's nothing in the ARQ message to say directly that invite is the desired outcome. The gatekeeper certainly MUST return the address to which E1 should send its Setup message, so in the direct-routed model that will be E2. However, a non-routing gatekeeper will have no way of knowing where the active MC is. I believe this is a genuine "hole" in the standard. Linh, I know you've implemented some of this stuff: how do you get around this? Regards, Chris -- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. ENGLAND Phone: +44 1753 661 359 email: cpurvis(a)madge.com

1 0

question: asn.1
by pjh 04 Mar '99

04 Mar '99

Dear ITU-SG16 experts I am searching for commercial or free ASN.1 compiler . Further details are as follows: Features: o ASN.1 to C or C++ source code compiler ( A run-time version of the source code is available) o Fully supports ASN.1:1997 o Library of low-level PER encode/decode functions o Compiler has been tested on following RealTime OS: pSOS, vxWorks, Ets kernel If you are using ASN.1 compiler on RealTime OS, Please let me know where I get it. Please reply to this E-Mail Sincerely, Jihye Park(Miss) Nada Research Co., Ltd. Seoul 137-070 , Korea Tel: 82-2-525-3941 Fax: 82-2-525-3945 pjh(a)deskview.nada.co.kr <mailto:pjh@deskview.nada.co.kr>

1 0

Re: H.323/VoIP QoS
by Roni Even 04 Mar '99

04 Mar '99

Joon, Please count me in. Roni Even ********************************************** Roni Even VP Product Marketing Accord Video Telecommunication Email: roni_e(a)accord.co.il Tel: +972-3-9251412 Fax: +972-3-9211571 *************************************************** > -----Original Message----- > From: Joon Maeng [SMTP:Joon_Maeng@VTEL.COM] > Sent: Wednesday, March 03, 1999 6:40 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.323/VoIP QoS > > Greetings! My name is Joon Maeng. I work for VTEL Corp in USA. I've > talked to > several companies while I was attending ITU and IETF meetings about > establishing > an ad-hoc group to address QoS (Quality of Service) issues in > TRANSPORTING > REAL-TIME TRAFFICS in the packet switched network, especially in the > IP network. > I was very encouraged by responses from those companies. Most of them > agreed > that lack of QoS support for real-time traffics was one of major > barriers in > deploying H.323/VoIP products and the H.323 industry would benefit by > having a > QoS activity group. I would like to ask if your company would be > interested in > the activities described in the following: > > Proposed name of the group: H.323/VoIP QoS Activity Group. > > Motivation: ITU defined a good conference standard, H.323, for the > packet > network. IETF is actively defining QoS standards for the IP network. > The > deployment of H.323/VoIP products has been slow partially due to lack > of QoS > supports in current IP network. The H.323/VoIP industry shall work > together to > access the issues and provide solutions for the users. > > Proposed charter of the group: > - Assess QoS issues in transporting real-time traffics (calls with > long-duration > compared to web-access) in the IP network, > - Find the solutions to resolve issues, > - Execute solutions via various processes such as building consensus > on various > QoS solutions among participants, > submitting recommendations to standardization bodies if needed, and > facilitating inter-operablity testing between QoS standards and > application > standards, > - and education, promotion, etc. > > I would expect the final charter and the structure of the group will > be > determined by the participants and their interests. I would say > that > everything is open at this time except that the industry shall look at > the QoS > issues seriously for real-time traffics. I'd like to clarify that the > proposed > group is not a group to standardize the QoS. It is a group or a forum > that is > interested in helping and promoting the real-time QoS for H.323/VoIP > industry > through various methods (to be determined). I plan to set up an > email > reflector for the initial discussions among participants and decide > the > following steps based on the discussions. Please email me (joon_maeng@ > vtel.com) > if you and your company would be interested in joining the initial > talks via > email reflector. Your comments and suggestions will be greatly > appreciated. > Regards, > Joon

1 0

About itu-t files?
by Li Jing 04 Mar '99

04 Mar '99

Please tell me where can I get full files about Recommendation G.XXX ? Thanks a lot!

1 0

Re: H.323/VoIP QoS
by Joon Maeng 04 Mar '99

04 Mar '99

Hi! To subscribe H.323/VoIP QoS Activity Group, please send mail to majordomo(a)majordomo.vtel.com with a command line subscribe h323_voip_qos your email address in the body of the message and follow the instructions in the response from the majordomo. Any text in the subject will be ignored. If you have any problem in subscribing the list server, please email me. Thank you much for your interests. Regards, Joon

1 0

Re: H.323/VoIP QoS (further to Randy Bloomfield's note)
by Joon Maeng 03 Mar '99

03 Mar '99

Hi folks, I do apologize using your reflectors for other purpose. I would like to stop any further discussions regarding H.323/VoIP QoS Ad-hoc group in others reflectors. By end of today (midnight), I'll include all the names who requested to join the group to a reflector, h323_voip_qos(a)majordomo.vtel.com. I'll also provide information about subscribing the reflector. Please hold any discussions until tomorrow morning. We can discuss whatever we want to tomorrow via new reflector and please please stay out of others reflectors. Thank you for your cooperation and tremendous interests. Regards, Joon

2 1

Re: H.323/VoIP QoS
by Joon Maeng 03 Mar '99

03 Mar '99

Hi! To subscribe H.323/VoIP QoS Activity Group, please send mail to majordomo(a)majordomo.vtel.com with a command line subscribe h323_voip_qos your email address in the body of the message and follows the instruction of the response from the majordomo. Any text in the subject will be ignored. If you have any problem in subscribing the list server, please email me. Thank you much for your interests. Regards, Joon

1 0

Invitation via Gatekeeper
by Lee Hyoung soo 03 Mar '99

03 Mar '99

Hello! I tried to get answer from implementors group and some other person, but I couldn't get any satisfiable answer. My question is here. In section 8.4.3.2(Figure 28/H.323-Non-MC invite signalling), when an endpoint(E1) which do not have active MC wants to invite other endpoint(E3), does E1 send an ARQ to its Gatekeeper for the invite or does E2 send the ARQ to its gatekeeper, or do both of them send ARQ's? And, when Gatekeeper doesn't know which endpoint has active MC in any conference, what should Gatekeeper do if it receives ARQ(for invitation) from an endpoint which do not have active MC? I mean, if Gatekeeper receives ARQ from E1, what should Gatekeeper do? Does Gatekeeper send ACR with E2's CallTransportAddress instead of E3's CallTransportAddress? Best wishes, soo. Nada Research Co., Ltd. Korea TEL : 82-2-525-3941 Lee Hyoung soo. mailto:soo@nada.co.kr

1 0

Re: H.323/VoIP QoS
by Scott Bradner 03 Mar '99

03 Mar '99

Radhika sends: > I guess that H.323 is a transport independent multimedia (audio, video, > and/or data) application. That is, H.323 can be transferred over any packet > network (e.g., IP, ATM, etc). So, one of the most important aspects of H.323 > is to define signaling messages that will carry the QOS information at the > H.323 application level. H.323 will then signal the underlying transport > network to support the appropriate QOS. > > I think that SG16 will limit their multimedia QOS activities at the H.323 > application layer. that makes sense but I will admit that is not what I read in the posting Scott

1 0