March 1999 - sg16-avd - lists.packetizer.com

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

Re: H.323/VoIP QoS
by Roy, Radhika R, ALCOO 03 Mar '99

03 Mar '99

Hi Scott: 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. Now how this H.323 application level QOS information will be implemented over a specific network layer can be implementation specific. For example, if it is an Internet/IP network, IETF's DiffServ, RSVP, intserv, and other QOS related services can be used by H.323's application level QOS signaling messages. Similarly, ATM network's QOS related services can also be used by the H.323's application level signaling messages. My view is that H.323's application level QOS work is intended to complement all QOS related works that are being carried out at the lower "network layer (e.g., IP/Internet, ATM, etc.)" in all standard bodies/forums (e.g., IETF, ATM Forum, T1A1, TIPHON, IMTC, MSAF, etc.). I do agree with you that no work should be undertaken that becomes counter productive with respect to on-going works of IETF, ATM Forum, T1A1, TIPHON, IMTC, MSAF, and other standard bodies/forums. My view is that only complementary solutions should be considered. With respect to H.323 QOS activity group's membership (per Joon Maeng's email), I am not sure what actually it means. I thought that it might be a part of the activities of SG16 to address QOS related issues at the H.323 application layer. Joon Maeng may elaborate more on that. Regards, Radhika > -----Original Message----- > From: Scott Bradner [SMTP:sob@HARVARD.EDU] > Sent: Wednesday, March 03, 1999 4:52 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323/VoIP QoS > > I do hope that you-all take a look at what is going on in the IETF > before going off to invent a different QoS for IP technology - SG16 > doing that sort of thing would seem to be quite counter productive > > I would suggest that people interested in IP QoS get on the IETF mailing > lists > (diffserv, RSVP, and intserv - see www.ietf.org under working > groups to find out how) > > Scott > > ---- > From ITU-SG16(a)mailbag.cps.intel.com Wed Mar 3 12:55:07 1999 > MIME-Version: 1.0 > X-Mailer: Internet Mail Service (5.5.2232.9) > Content-Type: text/plain > Date: Wed, 3 Mar 1999 12:41:50 -0500 > Reply-To: Mailing list for parties associated with ITU-T Study Group 16 > <ITU-SG16(a)mailbag.cps.intel.com> > Sender: Mailing list for parties associated with ITU-T Study Group 16 > <ITU-SG16(a)mailbag.cps.intel.com> > From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> > Subject: Re: H.323/VoIP QoS > To: ITU-SG16(a)mailbag.cps.intel.com > > Hi Everyone: > > I support this effort. In fact, Maeng and I had a very brief talk in the > last Monterey meeting related to the QOS aspects of H.323. Recent AT&T, > VTEL, and TIPHON contributions reflect many aspects of H.323/VoIP QOS. > > I also got encouraging responses when we talked about QOS related issues > to > many other companies. I guess that all of us would be benefited if the > H.323/VoIP QOS aspects are satisfactorily addressed. > > Hope that the QOS activity group will be formed. > > Thanks, > Radhika R. Roy > AT&T > (732) 420 1580 > rrroy(a)att.com > > > -----Original Message----- > > From: Joon Maeng [SMTP:Joon_Maeng@VTEL.COM] > > Sent: Wednesday, March 03, 1999 11: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