- sg16-avd - lists.packetizer.com

H.323 Mobilit
by Roy, Radhika R, ALTEC 28 Aug '98

28 Aug '98

> Hi Everyone: > > If we consider some examples how mobility problems have been solved in > different situations, we can find some clues how H.323 mobility problems > should be addressed. > > In this context, mobile IP and mobile MAC (mobile MAC is not a standard, > but it is used in many corporate networks). Let us assume both use IP/MAC > protocol over the LANs. (In addition, there can also be other kinds of > mobility environment: Virtual LAN layer 2 and 3, wireless, ATM, etc. I am > not considering those for the sake of simplicity). > > If we consider that both of them are addressing the device mobility, we > can analyze why they are using two different approaches to solve the same > mobility problem. By device mobility, it is meant that a use will move > from one place to another with his or her device. > > Mobile IP: > > It considers that the IP address that is being used by a device should > remain the same or fixed. That is, this device will always be reachable > using the same IP address whether the device remains in its home network > or moves to a different network. > > This problem has been solved based on the above requirement. > > The price that has been paid by this is as follows: > > 1. Needs to have home and foreign agent that will tunnel or de-tunnel > the IP packet. Note that the IP address of a device changes as soon as the > device is attached to new network. It is the agents that encapsulate or > de-encapsulate the IP transparently to the end user. I am not going > in-depth in discussing this. This is done within network, and the end use > is not affected. > > 2. New applications have been added to the end use's devices: > Registration and Authentication. Registration is needed purely for solving > the mobility problem, while authentication is needed from security point > of view. These new applications are needed by the end user device. > > Mobile MAC: > > It is much more robust. It assumes that as the device moves from one > network to another, there is a server in each LAN that detects the > movement of the MAC addresses through listening. There is a central server > in the network that has the repository of all MAC addresses that are being > stored since the service is provided through subscription only. > > Here registration is not needed to solve the mobility problems. However, > authentication may be needed for security purposes. > > Comparison between Mobile IP and Mobile MAC: > > 1. Both approaches solve the same problem: End user's device mobility. > > 2. But the architecture and the functional entities that are required > are quite different. > > How do we apply this above insights of our findings in the context of > H.323 mobility? > > H.323 Mobility: > > In H.323 mobility, we are dealing primarily with the following situations: > > 1. Transport level addresses: RTP, RTCP, UDP, TCP port addresses. > 2. GK in each Zone (a GK will also have a network level address). > > Now we can look back. > > A use may move from one network to another with the device. As a result, > the GK in which the registration of transport addresses has been made will > change. > > If appears that we may have to define the home and foreign GK something > like that. > > Then, we may have to deal with the problems of registration of the user > device when it moves to the new network. > > Finally, we have to deal with the transport addresses in mobility > environment. > > The question that I have: Can we use the "Mobile IP" transparently to > solve H.323 mobility problems? Can we use other adopted "Mobility Scheme" > transparently to solve H.323 mobility problems? > > If the answer is NO, then we have to design a new H.323 mobility > architecture to solve H.323 mobility problems. > > That is what I have to say for now. > > Thanks and regards, > > Radhika R. Roy > AT&T, USA > Tel: +1 732 949 8657 > E-mail: rrroy(a)att.com > > > >

1 0

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

28 Aug '98

Hi Santo: Section 8.1.6.(3/27/98 - Contact Person G. Thom - Editor) - Thanks, Radhika 8.1.6 Optional Called Endpoint Signalling The procedures defined in 8.1.4 and 8.1.5 show that when a called endpoint is registered to a Gatekeeper, a Setup message is initially sent to the called endpoint from the calling endpoint or the calling endpoint's Gatekeeper. If the called endpoint's Gatekeeper wishes to use the Gatekeeper routed call model, it returns its own Call Signalling Channel Transport Address in the ACF. The called endpoint then uses the Facility message to redirect the call to the called endpoint's Gatekeeper's Call Signalling Transport Address. These procedures assume that the calling endpoint or calling endpoint's Gatekeeper only knows the called endpoints Call Signalling Channel Transport Address. This address may have been received in an LCF sent in response to an LRQ requesting the address of the called endpoint or it may be known through out of band methods. If the called endpoint's Gatekeeper desires a Gatekeeper routed call model, it may return its own Call Signalling Transport Address in the LCF. This will allow the calling endpoint or calling endpoints Gatekeeper to send the Setup message directly to the called endpoints Gatekeeper, thus eliminating the redirection process. An example of this scenario is shown in Figure 24/H.323. In this example, both endpoints are registered to different Gatekeepers, and both Gatekeepers choose to route the call signalling (similar to the case in Figure 23/H.323). Endpoint 1 (calling endpoint) sends an ARQ (1) to Gatekeeper 1. Gatekeeper 1 multicasts an LRQ(2) to locate called Endpoint 2. Gatekeeper 2 returns an LCF(3) with the Call Signalling Channel Transport Address of itself. Thus, Gatekeeper 1 will subsequently send a Setup (6) message to Gatekeeper 2's Call Signalling Channel Transport Address and Gatekeeper 2 will send a Setup (8) message to Endpoint 2. Endpoint 2 initiates the ARQ (9)/ACF (10) exchange with Gatekeeper 2. Endpoint 2 then responds to Gatekeeper 2 with the Connect (12) message which contains its H.245 Control Channel Transport Address for use in H.245 signalling. Gatekeeper 2 sends the Connect (13) message to Gatekeeper 1 which may contain the Endpoint 2 H.245 Control Channel Transport Address, or a Gatekeeper 2 (MC) H.245 Control Channel Transport Address, based on whether the Gatekeeper 2 chooses to route the H.245 Control Channel or not. Gatekeeper 1 sends the Connect (14) message to Endpoint 1 which may contain the H.245 Control Channel Transport Address sent by Gatekeeper 2, or a Gatekeeper 1 (MC) H.245 Control Channel Transport Address, based on whether the Gatekeeper 1 chooses to route the H.245 Control Channel or not. <<...>> > ---------- > From: Santo Wiryaman[SMTP:swiryaman@VIDEOSERVER.COM] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Friday, August 28, 1998 5:46 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: ARQ/ACF > > Hi Radhika: > > You wrote: > > 1. Current H.323v2 (e.g., Section 8 with explicit Figures) DOES envisions > the RAS signaling messages including ARQ can be sent between the GKs in > addition between the H.323 entities and the GK. (Please note the > difference with Mr. Purvis reply). > > I quickly scanned Section 8 of H.323v2 and could not find the case where > ARQ's are sent between GK's. Could you be more specific on which > sub-section it is in or what figure? That would help me a lot. Thanks. > > -santo >

1 0

Re: ARQ/ACF
by Santo Wiryaman 28 Aug '98

28 Aug '98

Hi Radhika: You wrote: 1. Current H.323v2 (e.g., Section 8 with explicit Figures) DOES envisions the RAS signaling messages including ARQ can be sent between the GKs in addition between the H.323 entities and the GK. (Please note the difference with Mr. Purvis reply). I quickly scanned Section 8 of H.323v2 and could not find the case where ARQ's are sent between GK's. Could you be more specific on which sub-section it is in or what figure? That would help me a lot. Thanks. -santo

1 0

H.225.0 Annex G conference call
by Glen Freundlich 28 Aug '98

28 Aug '98

There will be another conference call to discuss H.225.0 Annex G: date: 4 September 1998 (Friday) time: 9:00am Mountain Time (8:00 Pacific, 11:00 Eastern, etc) bridge number: +1 630-224-4444 code: 911202 duration: 1 hour Tentative agenda (time permitting): - review of Pete Cordell's proposal - review of Radhika Roy's proposal - review of Andrew Draper's proposal Notes from the last call: We started by trying to reach some closure on Santo Wiryaman's proposal. Points from the discussion: - All border elements should be required to support H.225 V2 for newly defined alias addresses (especially email-id) - If some form of hierarchy is imposed, who controls the root node in the hierarchy? - Private networks have different numbering schemes than the public network, so addresses cannot be resolved through the hierarchy in the public network. - Number portability is common in private networks, so using a hierarchy in private networks to aid address resolution may not be totally beneficial. - We may need some form of indirection or re-routing in the address resolution to support notions like number portability. How does this work in the telephone network, for example to resolve 800 numbers? - Can we rely on, or benefit from, mobile IP mechanisms? Will this solve mobility for free? - Call signaling (i.e., Setup message) and address resolution (annex G protocol, various existing RAS messages) may follow different paths. For those who were on the last call, please correct me if I've missed something. Glen -- Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA

1 0

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

28 Aug '98

Vivian: Kindly note the following: 1. Current H.323v2 (e.g., Section 8 with explicit Figures) DOES envisions the RAS signaling messages including ARQ can be sent between the GKs in addition between the H.323 enties and GK. (Please note the difference with Mr. Purvis reply). 2. In "logical" zone environment, the resource management is also extremely important especially in the context of large network where million of users share the same physical network (e.g., in carrier networks, in virtual private networking environment, the network reosources are partioned logically between the corporate customers). [Please note the difference with Mr. Purvis reply]. Thanks, Radhika PS: Please also see the reply sent complementing Mr. Clowes response. > ---------- > From: Chris Purvis WVdevmt-WS[SMTP:cpurvis@MADGE.COM] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Thursday, August 27, 1998 6:15 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: ARQ/ACF > > WanJiun, > > The important fact about GK in your diagram is that it is an MCU, not > that it is a gatekeeper. The functionalities are separate, and > inter-zone calls are possible. Hence, in answer to your specific > questions: > 1. There is no reason in the standard why an MCU needs to be in the same > zone as any of the endpoints is is joining in a conference. > 2. ARQs are not (in current versions of the standard) transmitted between > gatekeepers. They are ONLY transmitted from an endpoint (where gateways, > proxies, MCUs etc are endpoints in this sense) to the gatekeeper with > which it is registered. However, the MCU should send an ARQ to its > gatekeeper asking whether it should accept the call, and it is up to the > MCU's gatekeeper to permit or deny authorisation to use resources in its > zone. In your diagram the MCU and its gatekeeper are co-located, so the > ARQ per se might not be sent, but the MCU "part" will still be expected > to ask the gatekeeper "part" whether or not it should accept the call. > However, there is no guarantee that talking about resource usage "within > a zone" is useful, due to the fact that a zone has logical rather than a > physical scope. > > I hope this clears up your queries. > > 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 > > 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

Draft white papers on supplementary services H.450.4/5/6 uploaded
by Korpi Markku PN VS LP3 28 Aug '98

28 Aug '98

I have uploaded the draft white papers on supplementary services to the incoming directory of the avc-site. These are - H.450.4 Call Hold - H.450.5 Call Park and Call Pickup - H.450.6 Call Waiting and they can be proposed for determination in the SG-16 meeting in September. The fourth supplementary service, H.450.7 Message Waiting is also ready for determination, but will be uploaded separately by Dave Walker. --Markku

1 0

Communications between Administrative domains
by Andrew Draper WVdevmt-WS 28 Aug '98

28 Aug '98

I attach my proposal. This specifies a method of finding a suitable border element given the destinationAddress field in an LRQ or SETUP message. This is partly derived from Santo Wiryaman's proposal, and is partly tightening up on language in the existing spec. I have expanded the scope of the LCF message slightly to allow a border element to use the responses to choose from a set of border elements which are all able to route the call. Regards, Andy -- Andrew Draper - Principal Development Engineer - WAVE Software Madge Networks, Wexham Springs, Framewood Road, Wexham, Berks. mailto:adraper@dev.madge.com phone:+44 1753 661329 pgp fingerprint D6 ED 72 4F 96 BB CA 2D 68 74 4C E0 CB B9 0B 3F

1 0

Re: H.225.0 Annex G conference call
by Roy, Radhika R, ALTEC 27 Aug '98

27 Aug '98

Hi Everyone: I need to add some clarifications in Mr. Glen Freundlich's note. RAS messages are the madatory that are sent via the GKs. A GK is responsible for a given zone. H.323's ARQ/ACF/ARJ and BRQ/BCJ/BRJ messages do contain abstraction of BW. H.323 does not mandate how these parameters to be implemented for any specific networking environment. We have also discussed how important these BW/QOS parameters are to provide or differentiate services. Definitely, there can be many implementation schemes how to abstract those network level BW/QOS information to the higher layer such as GK level (In fact, H.323 GK does have the capability for admission control, bandwidth control, zone management, call control, etc) whether media and signaling are going through the same path or different paths. The complexity of implmentation will depend from a very simple one to a very complex one. It is the job of the lower layer how these functions will be performed, and how those abstractions will be communicated to the higher layer (e.g., GK level). In H.323v2, we have kept all those parameters open for use for RAS messages for the GKs. At H.323 level, we are not dealing with specific technology dependent implementation issues at the lower network level. There are many standard bodies including ITU-T, IETF, ATM-F, TIPHON, IMTC, and others are dealing with many aspects of H.323 for implementations over the specific networking technologies including abstraction of network level BW/QOS parameters up to the GK level. If anyone has any questions, please let me know. Thanks and regards, Radhika R. Roy AT&T, USA Tel: 732 949 8657 email: rrroy(a)at.com > ---------- > From: Glen Freundlich[SMTP:ggf@lucent.com] > Reply To: ggf(a)lucent.com > Sent: Tuesday, August 25, 1998 12:18 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.225.0 Annex G conference call > > There will be another conference call to discuss H.225.0 Annex G: > date: 27 August (Thursday) > time: 10:00am Mountain Time (9:00 Pacific, 12:00 Eastern, etc) > bridge number: +1 630-224-4444 > code: 911202 > duration: 1 hour > > Tentative agenda: > - next call 4 September (Friday)? more than 1 hour? > - closure on Santo Wiryaman's proposal > - review of Pete Cordell's proposal > - review of Radhika Roy's proposal > > Attendees on last call: > (I'm sorry if I didn't get your name on the list. Please email me after > a call so that I can build a roster.) > Kaynam Hedayat - PictureTel > Kerwin Yuu - PictureTel > Markku Korpi - Siemens > Pete Cordell - BT > Radhika Roy - AT&T > Hal Purdy - AT&T > Jim Toga - Intel > Dieter Rencken - Siemens > Chris Purvis - Madge Networks > Andrew Draper - Madge Networks > Michele Bozier - Madge Networks > Santo Wiryaman - VideoServer > Sree Peyyety - ITXC > Glen Freundlich - Lucent > > Notes from last call: > We spent about 40 minutes discussing Santo Wiryaman's document. The > proposal for an addressing hierarchy seems to help scaling, however > there are concerns about roaming, portability, and applicability to > private networks. There are concerns about defining a numbering or > addressing plan, which include political issues as well as technical. > However, we probably need some way to assure that an alias is unique. We > could leave definition of the address space to bodies such as Tiphon. > Annex G might specify that support for E.164 addressing is required, > email addresses optional. Annex G or H.225 should stress that email > addresses should use the email alias address, not the h323-id. There is > also some concern about signaling through the domains in the hierarchy > (e.g., going through domains B and C when domain A attempts to signal > domain D) - whether this is efficient, what happens when a node is out > of service, whether this makes sense in packet networks, and what the > net benefit is. > > This led into a discussion of some of the points in Radhika Roy's > proposal. It is difficult for a GK to control transport level QoS since > a GK does not know about other (non-H.323) traffic on the network, and > media may take a different path than the signaling between GKs. > > For those who were on the last call, please correct me if I've missed > something. > > Glen > > > -- > Glen Freundlich ggf(a)lucent.com > Lucent Technologies office: +1 303 538 2899 > 11900 N. Pecos fax: +1 303 538 3907 > Westminster, Colorado 80234 USA >

3 2

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

27 Aug '98

WanJiun: Kindly also wait to get an answer from me as per your proposed configurations and call flows explained step by step. Let me be settle after finishing my trip from Washington DC. I hope to get back to you soon. Thanks and regards, Radhika R. Roy AT&T > ---------- > From: Chris Purvis WVdevmt-WS[SMTP:cpurvis@MADGE.COM] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Thursday, August 27, 1998 6:15 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: ARQ/ACF > > WanJiun, > > The important fact about GK in your diagram is that it is an MCU, not > that it is a gatekeeper. The functionalities are separate, and > inter-zone calls are possible. Hence, in answer to your specific > questions: > 1. There is no reason in the standard why an MCU needs to be in the same > zone as any of the endpoints is is joining in a conference. > 2. ARQs are not (in current versions of the standard) transmitted between > gatekeepers. They are ONLY transmitted from an endpoint (where gateways, > proxies, MCUs etc are endpoints in this sense) to the gatekeeper with > which it is registered. However, the MCU should send an ARQ to its > gatekeeper asking whether it should accept the call, and it is up to the > MCU's gatekeeper to permit or deny authorisation to use resources in its > zone. In your diagram the MCU and its gatekeeper are co-located, so the > ARQ per se might not be sent, but the MCU "part" will still be expected > to ask the gatekeeper "part" whether or not it should accept the call. > However, there is no guarantee that talking about resource usage "within > a zone" is useful, due to the fact that a zone has logical rather than a > physical scope. > > I hope this clears up your queries. > > 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 > > 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

Re: ARQ/ACF
by Chris Purvis WVdevmt-WS 27 Aug '98

27 Aug '98

WanJiun, The important fact about GK in your diagram is that it is an MCU, not that it is a gatekeeper. The functionalities are separate, and inter-zone calls are possible. Hence, in answer to your specific questions: 1. There is no reason in the standard why an MCU needs to be in the same zone as any of the endpoints is is joining in a conference. 2. ARQs are not (in current versions of the standard) transmitted between gatekeepers. They are ONLY transmitted from an endpoint (where gateways, proxies, MCUs etc are endpoints in this sense) to the gatekeeper with which it is registered. However, the MCU should send an ARQ to its gatekeeper asking whether it should accept the call, and it is up to the MCU's gatekeeper to permit or deny authorisation to use resources in its zone. In your diagram the MCU and its gatekeeper are co-located, so the ARQ per se might not be sent, but the MCU "part" will still be expected to ask the gatekeeper "part" whether or not it should accept the call. However, there is no guarantee that talking about resource usage "within a zone" is useful, due to the fact that a zone has logical rather than a physical scope. I hope this clears up your queries. 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 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

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

Questions on V2 Source and Destination addressing
by Douglas Clowes 26 Aug '98

26 Aug '98

I have been looking at the source and destination address information in H.323 version 2, and am feeling a little confused. Perhaps someone can point me to something that will clarify the position. Version 1 had a number of addressing fields, for both the source and destination. Version 2 extends that in a number of areas, both as additional fields for what I'll call the primary address, but also as sequences of source and destination alternatives. It also introduces the Endpoint IE, which contains a number of OPTIONAL address structures. Referring to the Endpoint first, I notice that it contains both an aliasAddress, and a destinationInfo. The descriptions for these elements do not seem convincingly right. If the Endpoint refers to a destination, presumably both (this endpoint and destination) are the same. I also notice that Endpoint does not contain the new element remoteExtensionAddress which has been added, as destination address information, to both ACF and SETUP messages. If this is the number to be dialled from a remote gateway, may it not be different for different destination gateways? I think it could be, and so should also appear in the Endpoint IE. I think that it should be an optional element in the ARQ as well, if the source endpoint knows this information. I also see that remoteExtensionAddress is a SEQUENCE OF in the ACF, but only a single AliasAddress in the SETUP message. Why? I assume that alternateEndpoints, in the ACF message, are alternates to be tried in the event that the endpoint specified in the dest* elements (priority 0) is not successful. It gets more difficult when I look at the ARQ message. Can someone please tell me what is the intention of the srcAlternatives and destAlternatives elements? If the purpose of srcAlternatives, in ARQ, is to allow for an endpoint that has multiple possible identities, shouldn't ACF specify which identity is confirmed, and which alternative to use in the SETUP message? To include an OPTIONAL sourceAddress Endpoint in the ACF, would also allow a gatekeeper to override or add source address information for the call. On the subject of where authorisation tokens between source and destination could be included in call setup, has anything been discussed or decided? By that I mean a token of some kind, generated by the source gatekeeper and to be relayed through the setup process to the destination gatekeeper, as input to the destination admission determination. Regards, Douglas

1 0

Delayed contributions are moved to /9809_Gen/Delayed/
by Sakae OKUBO 26 Aug '98

26 Aug '98

Dear Q.11-14/16 experts, Mr. Harasaki wrote: >I have put a delayed contribution to September SG16 meeting as >ftp://standard.pictel.com/avc-site/Incoming/Delayed_H323_ISDN.zip This document has been moved to ftp://standard.pictel.com/avc-site/9809_Gen/Delayed/Delayed_H323_ISDN.zip with the following two delayed contributions: ATT_nh_gkx2.zip from Mr. Roy H323_Annex_E.zip from Mr. Gurle (I hope my understanding is correct that this is a delayed contribution) 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

H.225.0 Annex G conference call
by Glen Freundlich 25 Aug '98

25 Aug '98

There will be another conference call to discuss H.225.0 Annex G: date: 27 August (Thursday) time: 10:00am Mountain Time (9:00 Pacific, 12:00 Eastern, etc) bridge number: +1 630-224-4444 code: 911202 duration: 1 hour Tentative agenda: - next call 4 September (Friday)? more than 1 hour? - closure on Santo Wiryaman's proposal - review of Pete Cordell's proposal - review of Radhika Roy's proposal Attendees on last call: (I'm sorry if I didn't get your name on the list. Please email me after a call so that I can build a roster.) Kaynam Hedayat - PictureTel Kerwin Yuu - PictureTel Markku Korpi - Siemens Pete Cordell - BT Radhika Roy - AT&T Hal Purdy - AT&T Jim Toga - Intel Dieter Rencken - Siemens Chris Purvis - Madge Networks Andrew Draper - Madge Networks Michele Bozier - Madge Networks Santo Wiryaman - VideoServer Sree Peyyety - ITXC Glen Freundlich - Lucent Notes from last call: We spent about 40 minutes discussing Santo Wiryaman's document. The proposal for an addressing hierarchy seems to help scaling, however there are concerns about roaming, portability, and applicability to private networks. There are concerns about defining a numbering or addressing plan, which include political issues as well as technical. However, we probably need some way to assure that an alias is unique. We could leave definition of the address space to bodies such as Tiphon. Annex G might specify that support for E.164 addressing is required, email addresses optional. Annex G or H.225 should stress that email addresses should use the email alias address, not the h323-id. There is also some concern about signaling through the domains in the hierarchy (e.g., going through domains B and C when domain A attempts to signal domain D) - whether this is efficient, what happens when a node is out of service, whether this makes sense in packet networks, and what the net benefit is. This led into a discussion of some of the points in Radhika Roy's proposal. It is difficult for a GK to control transport level QoS since a GK does not know about other (non-H.323) traffic on the network, and media may take a different path than the signaling between GKs. For those who were on the last call, please correct me if I've missed something. Glen -- Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA

1 0

RDC docs posted to FTP site
by Mark Duckworth 25 Aug '98

25 Aug '98

I'm forwarding this for Andy Woollett. Hi All, At Andy's request I have posted VRDCrevA.doc and TRDCrevB.doc, they are at ftp://ftp.imtc-files.org/imtc-site/T120-top/geneva98-2/ Chuck ------- Forwarded Message Follows ------- From: Andy Woollett <a_woollett(a)imagecom.co.uk> To: Chuck Grandgent <k1om(a)world.std.com> Subject: V.RDC and T.RDC Draft Documents Date sent: Mon, 24 Aug 1998 15:54:21 +0100 Hi Chuck, Could you please place these documents into the Geneva98-2 directory at the IMTC site directory and then forward the following message to the Q3 and Q14 reflectors. Thanks Andy Woollett --------------------------------------------- All: The following draft documents have been placed in the Geneva98-2 directory at the IMTC site. /pub/imtc-site/T.120-top/Geneva98-2/VRDCrevA.doc /pub/imtc-site/T.120-top/Geneva98-2/TRDCrevB.doc VRDCrevA - Remote Device Control Protocol for Multimedia Applications (Q3/16, Q14/16) TRDCrevB - Remote Device Control Application Protocol (Q3/16) It is anticipated that these documents will be submitted for determination at the Geneva SG16 meeting in September. A list of the main changes is on page 2 of each document. Further work is in progress updating the ASN.1 in VRDCrevA.doc. Please could interested parties review these documents and send any questions or comments to me at a_woollett(a)imagecom.co.uk. Thanks Andy Woollett ImageCom Ltd

1 0

Delayed contribution on H.323 over ISDN
by Hidenobu Harasaki 25 Aug '98

25 Aug '98

Dear Q.11-14 Experts, I have put a delayed contribution to September SG16 meeting as ftp://standard.pictel.com/avc-site/Incoming/Delayed_H323_ISDN.zip. The title is "Comments on the projected Annex/Appendix for H.323 over N-ISDN". The contribution is prepared to discuss interworking of the projected H.323/I terminal with other type of terminals, comparing with a similar case of Annex C to H.323 (H.323 over ATM). It provides some analysis for possible interworking combinations with respect to audiovisual transport and suggests some directions to facilitate the conclusion of this topic. I will submit this contribution to ITU-T in a few days. Best regards, Hidenobu Harasaki harasaki(a)ccm.CL.nec.co.jp Manager, Research C&C Media Research Labs., NEC Corporation Phone: +81 44 856 8083 Fax: +81 44 856 2232

1 0