August 1998 - sg16-avd - lists.packetizer.com

Re: ARQ/ACF
by Tom-PT Taylor 29 Aug '98

29 Aug '98

Sorry, Radhika, nowhere in this is a GK sending an ARQ to another GK > -----Original Message----- > From: Roy, Radhika R, ALTEC [SMTP:rrroy@ATT.COM] > Sent: Friday, August 28, 1998 7:03 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: ARQ/ACF > > 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. > > <<...>> > > [Taylor, Tom [CAR:B318-I:EXCH]] <snip>

1 0

Document ID
by Roy, Radhika R, ALTEC 29 Aug '98

29 Aug '98

Hi Everyone: We are now enclosing very important documents via emails for our H.323 inter-GK conference calls. The number of documents will be increasing very soon. For example, 2 from VideoServer (Santo W.), 1 from BT (Pete C.), 2 from AT&T (Radhika R.), and 1 from Madge (Andrew D.). Now we have problems to refer each other's documents (If you read Mr. A. Draper's recent document, one may easily feel it). Each document contains a wealth of information. Let us preserve this valuable information so that we can keep refering each document even when we finish our conference calls after next week. The way I see that we need to use the ID for each enclosed document is as follows: 1. Each enclosed document should contain: Title, Author's name, Company Name, and Date. 2. If possible, the file name of the document (e.g., xxx.doc, etc). Does this proposal make sense? Thanks and regards, Radhika R. Roy > ---------- > From: Andrew Draper WVdevmt-WS[SMTP:adraper@DEV.MADGE.COM] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Friday, August 28, 1998 10:12 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Communications between Administrative domains > > <<File: ResolveGK.doc>> > 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

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