- sg16-avd - lists.packetizer.com

Re: H225.0 Annex G: Response to Radhika's "clarifications"
by Roy, Radhika R, ALTEC 27 Aug '98

27 Aug '98

Hi Everyone: We all agree that the lower netwokring layer will deal with specific QOS/BW issues. However, it the GK which is responsible for the ARQ and Bandwidth messages. At the call level, a GK has to decide whether a H.323 call has to be accepted or not. So, options are there that there will be an "abstraction" of QOS/BW at the GK level before acceptance of the call. This is an important parameter to provide or differentiate services (if anyone does not want to differentiate a service by using that parameter may be one's choice, but others do want to keep that option open). Thanks and regards, Radhika R. Roy AT&T ---------- From: Chris Purvis WVdevmt-WS [SMTP:cpurvis@MADGE.COM] Sent: Wednesday, August 26, 1998 1:09 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: H225.0 Annex G: Response to Radhika's "clarifications" All, Last week's conference call seemed to me to come to some fairly clear conclusions, on the basis of which I understood that the following would be the basis for our ongoing work in this area. Assume initially that there is global transport-layer connectivity between border-elements. We will consider the case where this is not so below. There are up to four essentially different sorts of message that may be propogated for a call to take place in the envisaged environment: 1. Location messages. These allow a caller to discover, essentially, where to send its setup message. 2. Call setup messages 3. "H.245" messages 4. Data (in which I include audio & video data). There is no reason for any two of these types of message to propogate by the same route between border elements (indeed, there's no reason why audio and video, for example, should go the same route either). In particular, what I have designated the "location" stage may go take a complex route or consist of the "source" border element asking other border elements in turn for more information (where the "more information" may consist of more border elements to ask the question, in some structured form - probably traversing a hierarchy). There is also the point that a gatekeeper does not necessarily have (and neither should it be encumbered with) knowledge of other sorts of traffic traversing a network it is on. These points appeared to lead to a consensus that the bandwidth management scheme implemented in ARQ and BRQ messages, while of some use in a controlled LAN environment, is not up to the demands that this larger scheme would place on it. Moving on from that we seemed to be in agreement that, at least in these less controlled environments, bandwidth and QoS issues should be handled at a lower layer, on the grounds that there is (and should be) no difference from a router's point of view between H.323 data and any other UDP packets. In the case without global transport-layer connectivity between border elements, things will change slightly, but only inasmuch as there may be one or more "pinch points" (such as proxies between transport networks) along the routes that all the different sorts of messages have to go through. The presence of such "pinch points" in some circumstances is not an argument in favour of artificially imposing them on all networks, however: even if a given route has "pinch points" there is no reason to force different types of message to go the same route between "pinch points". Regards, Chris ---------------------------------------- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. Phone:+44 1753 661359 email: cpurvis(a)madge.com

1 0

Re: ARQ/ACF
by Roy, Radhika R, ALTEC 27 Aug '98

27 Aug '98

W. Liao WanJiun: I am in Wash DC, and will be answering your question very shortly. Regards, Radhika ---------- From: WanJiun Liao [SMTP:wjliao@EEE.HKU.HK] Sent: Thursday, August 27, 1998 12:30 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: ARQ/ACF Roy, Sorry, I just joined, and maybe have missed the disscussion of the following questions. I am a bit confused about how they are handled. ---- In a distributed gatekeeper architecture of multiple zones environment, say, the H.245 control channel topology looks like as follows: E1 ----- GK -------E2 / | \ / | \ / | \ E3 E4 E5 E1 is in zone 1, E2 is in zone 2, and (E3,E4,E5) are in zone 3. (the corresponding gatekeeper in each zone is denoted to GKi) GK is a gatekeeper that contains an active MC for multipoint conference ocntrol. 1. Should GK has to be in one of {zone1, zone2, zone3)? 2. If endpoint F in in zone 4 would like to join the conference, F must send an ARQ to GK4 before any setup to join the conf. (because GK4 is in charge of the admission for call bandwidth etc. local resources.) Should GK4 forwards ARQ to GK that has the MC?? F should not use any resources in the zone of GK is responsible for. or F has to, because H.245 control message exchanges also consume the reources? or some others? Please advise. Thanks a lot. Regards, Vivian Liao

1 0

COM 16-67 (Amendment 5 to H.222.0|ISO/IEC 13818-1) is correct
by Sakae OKUBO 27 Aug '98

27 Aug '98

Dear SG16 colleagues, Yesterday I wrote: >>In Table 2-18, the stream coding for stream_id = 1111 0010 >>currently reads "ITU-T Rec. H.222.0 | ISO/IEC 13818-1 >>Annex B or ISO/IEC 13818-6_DSMCC_stream", where >>"Annex B" should read "Annex A". but it has been found in the publication version of H.222.0 that Annex B refers to DSM-CC, thus the text in COM 16-67 is correct. Sorry for my confusion. Annexes A and B were swapped when H.222.0 was elevated to the publication version from the final draft. Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

test message
by Dale L. Skran 27 Aug '98

27 Aug '98

Please ignore. Dale Skran

1 0

Re: Protocol analyzing tools for VoIP?
by Paul Long 26 Aug '98

26 Aug '98

> From: Rod Gotty[SMTP:rgotty@DIALISDN.COM] > Could someone please direct me to where I might find tools for "sniffing" > a LAN segment and expose the VoIP traffic. > Yes. 1. Delta Information Systems has an H.323 protocol analyzer. http://www.delta-info.com/products/vt320/h323spec.html 2. Microsoft had a NetMon H.323 parser available at no charge from their server at the recent SuperOp! I was too busy to download a copy, though. Anybody know where I can get one now? (Deepak, are you reading this?) I couldn't find a copy on their web site. Paul Long Smith Micro

1 0

H225.0 Annex G: Response to Radhika's "clarifications"
by Chris Purvis WVdevmt-WS 26 Aug '98

26 Aug '98

All, Last week's conference call seemed to me to come to some fairly clear conclusions, on the basis of which I understood that the following would be the basis for our ongoing work in this area. Assume initially that there is global transport-layer connectivity between border-elements. We will consider the case where this is not so below. There are up to four essentially different sorts of message that may be propogated for a call to take place in the envisaged environment: 1. Location messages. These allow a caller to discover, essentially, where to send its setup message. 2. Call setup messages 3. "H.245" messages 4. Data (in which I include audio & video data). There is no reason for any two of these types of message to propogate by the same route between border elements (indeed, there's no reason why audio and video, for example, should go the same route either). In particular, what I have designated the "location" stage may go take a complex route or consist of the "source" border element asking other border elements in turn for more information (where the "more information" may consist of more border elements to ask the question, in some structured form - probably traversing a hierarchy). There is also the point that a gatekeeper does not necessarily have (and neither should it be encumbered with) knowledge of other sorts of traffic traversing a network it is on. These points appeared to lead to a consensus that the bandwidth management scheme implemented in ARQ and BRQ messages, while of some use in a controlled LAN environment, is not up to the demands that this larger scheme would place on it. Moving on from that we seemed to be in agreement that, at least in these less controlled environments, bandwidth and QoS issues should be handled at a lower layer, on the grounds that there is (and should be) no difference from a router's point of view between H.323 data and any other UDP packets. In the case without global transport-layer connectivity between border elements, things will change slightly, but only inasmuch as there may be one or more "pinch points" (such as proxies between transport networks) along the routes that all the different sorts of messages have to go through. The presence of such "pinch points" in some circumstances is not an argument in favour of artificially imposing them on all networks, however: even if a given route has "pinch points" there is no reason to force different types of message to go the same route between "pinch points". Regards, Chris ---------------------------------------- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. Phone:+44 1753 661359 email: cpurvis(a)madge.com

1 0

Re: Protocol analyzing tools for VoIP?
by HERSENT Olivier CNET/DSE/CAE 26 Aug '98

26 Aug '98

I believe you can buy it from Vocaltec , or for RTP you could also use utilities as RTPdump Olivier HERSENT > ---------- > De : Rod Gotty[SMTP:rgotty@DIALISDN.COM] > Répondre à : Mailing list for parties associated with ITU-T Study Group > 16 > Date : Wednesday, August 26, 1998 3:30 PM > A : ITU-SG16(a)MAILBAG.INTEL.COM > Objet : Protocol analyzing tools for VoIP? > > Could someone please direct me to where I might find tools for "sniffing" > a LAN segment and expose the VoIP traffic. I'm looking for something more > than just a LAN protocol analyzer that only shows TCP & UDP frames but > something more that recognizes the various VoIP protocols (RTP, H.245 > messages, etc) and breaks them down into constituent fields. > > Thanks > -Rod >

1 0

Q. about master/slave determination in H.245
by WanJiun Liao 26 Aug '98

26 Aug '98

Hi.. I have some questions about master/slave determination in H.245. Perhpas these questions are stupid... but could you please kindly give me some help? With H.245, we need to do master/slave determination to resolve conflicts between two endpoints which can be the MC in a conference. (1) If there is no MC is active and all entities are of different types, the priority to win the master/slave determination is MCU > Gatkeeper > Gateway > terminal. THis means. e.g., with Gatekeeper and terminal, Gatekeeper always wins the determination? then why bothering to set "statusDeterminationNumber" to be a random no. in that certain range? or only when those entities are all in the same type, then such setting just makes sense? i.e., "terminalType" overrules "statusDeterminationNumber" ?? (2) An MC that is already acting as an MC shall always remian the active MC. However, assume that there are only terminals participating in a conference, what if a terminal that won the determination already decides to leave the conference at some time during the call? Should we need to perform such master/slave determination again?, or the terminal can assign the other to be an active MC?, or the terminal by no means can not leave the conference in the middle of the call? Please advise... thanks a lot.. Best regards, Wanjiun Liao

3 2

subscribe
by alexa 26 Aug '98

26 Aug '98

Alexa(a)inobject.com <mailto:Alexa@inobject.com>

1 0

Comment on COM 16-67 (Amendment 5 to H.222.0|ISO/IEC 13818-1)
by Sakae OKUBO 26 Aug '98

26 Aug '98

Dear SG16 colleagues, In the course of reviwing the subject white contribution for decision, I have found an error in the text. I would like to submit Rapporteur TD as attached. Please review it. Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ITU - Telecommunication Standardization Sector Temporary Document XXX STUDY GROUP 16 Geneva, 14-25 September 1998 Question(s): 12/16 SOURCE*: RAPPORTEUR FOR Q.12/16 TITLE: TYPOGRAPHICAL ERROR IN COM 16-67-E (AMENDMENT 5 TO H.222.0) __________________ In Table 2-18, the stream coding for stream_id = 1111 0010 currently reads "ITU-T Rec. H.222.0 | ISO/IEC 13818-1 Annex B or ISO/IEC 13818-6_DSMCC_stream", where "Annex B" should read "Annex A". __________________

1 0