- sg16-avd - lists.packetizer.com

Voice stream multiplexing
by Ronen Goory 27 Jan '99

27 Jan '99

I would like to know if the VoIP forum decided on a standard for voice stream multiplexing? Is there any proposals except the Hitachi proposal? IETF AVT working group proposed at least 4 drafts to implement it, does the VoIP forum intend to corporate with IETF on that issue? Ronen Goory RAD Data Communications 31 Habarzel st. Tel-Aviv, Israel Tel 972-3-6455433 Fax 972-3-6455305

1 0

Re: APC request
by Sakae OKUBO 27 Jan '99

27 Jan '99

Dear Mr. Hill, In response to your request, APC-1500 has been allocated to your draft Recommendation "Gateway Control Protocol H.GCP." 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 *********************************************************** ---------------------------------------------------------------------- APC- Source Title ---------------------------------------------------------------------- 1486 SG11 Q.20/11 DSS2 protocol provision of adaptive timing recovery used for transmitting clock 1487 SG9 Q.31/9 Progress report on Webcasting 1488 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q 11, 12, 13 and 14 on MPEG-4 Systems on H.32X 1489 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q11, 12, 13, and 14 on MPEG-4 Audio on H.32X 1490 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q12 on Common Text Recommendations 1491 Nokia GSM in H.323 1492 AT&T H.323 Differentiated Services and Their Protocol Architectures 1493 AT&T Viewgraphs presentation for "H.323 Differentiated Services and Their Protocol Architectures" 1494 AT&T TIA/EIA IS-641 Enhanced Full-Rate Speech Codec for H.323 1495 Editor (G Kajos) Changes to H.341 Annexes 1496 Editors (D Gurle, G Kimchi) Editorial changes to H.323 Annex E text 1497 TIPHON Requirements for a Protocol at Reference Point N: Media Gateway Controller to Media Gateway 1498 VTEL H.323 QoS (Quality of Service) in the Policy Based Network 1499 VTEL Slides Presentation for H.323 QoS (Quality of Service) in the Policy Based Network 1500 Editor (B Hill) Gateway Control Protocol H.GCP ----------------------------------------------------------------------

2 2

Re: Multiple aliases in ARQ destinationInfo
by Santo Wiryaman 26 Jan '99

26 Jan '99

Hi Chris, Yes, we do need an agreement. On the WHAT part, may I suggest the following: how should a GK treat multiple aliases in an ARQ? The answer should consider the following (and some others which I might have missed): 1. ARQ from the caller (this is the main topic for the question) 2. SETUP. In a GK-routed, pre-granted situation, the GK does not get the ARQ so the SETUP may contain multiple aliases 3. ARQ from the callee. Would this ARQ contain multiple alias, too? If so, what does it mean? 4. ARQ from the caller contain multiple aliases and destCallSignalAddress What ought the GK do? 5. What should be returned in the ACF? 6. What to do with LRQ's (rules for sending, receiving)? Here is my vote: 1. At a minimum, a GK shall do interpretation #1: use the first alias and ignore the rest 2. The GK may optionally look at the other aliases. The interpretation of these multiple aliases shall be determined by the particular site / administrative domain. Incidentally, I just realized that these discussions were on the SG-16 mailing list and not on the h323Implementors list. I wonder if that might be a reason for not hearing from other folks? I also have a question on what you mean by consistency check of the GK dbase during the ARQ. What are you trying to detect in this case? I re-read your previous email and got the following: >Hence what I believe SHOULD happen is that the gatekeeper >1. If it can match anything within its zone, should ensure that different >aliases in the ARQ do not point to different destinations within the zone. >If there is such disagreement, the GK should return ARJ. It seems that the above check would prevent Paul Long from doing what he was suggesting, i.e. call "#@home, #@work, #@mobile_phone, #ofFaxMachine", because more than one of those devices may be in the same zone. Regards, -santo > -----Original Message----- > From: Chris Purvis [SMTP:CPurvis@MADGE.COM] > Sent: Tuesday, January 26, 1999 5:05 AM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Multiple aliases in ARQ destinationInfo > > > From the various views expressed in this thread, I think it > > is clear that > > until at least a consensus is formed on the semantics of > > multiple aliases in > > ARQ's destinationInfo, an EP had better send a single alias > > if the user has > > any hope of predictable--not necessarily > > deterministic--behavior. As with many > > things H.323, _caveat transmittor_. > > Do we really think this is acceptable? Frankly I'll happily ensure that > the > Madge gatekeeper does any of the sensible options in the interests of > predictable behaviour! My vote would be for checking consistency of > aliases > within the GK's database (because it really ought to enable endpoints to > give the user more meaningful error messages than a wrong number), but we > can go with first past the post if we can reach concensus that way. > > We COULD make it configurable, but I have a bad feeling about that. > 1. What does it gain anybody over specifying something (except even more > user-confusion)? > 2. Assuming we want to define the same behaviour for LRQs in a multiple > gatekeeper environment (which seems sensible), people may get results that > surprise them due to different gatekeepers being differently configured. > > Can we start by agreeing over whether we need agreement (I say we do), and > then, if we DO think we need agreement, agree on WHAT? > > 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

Re: Multiple aliases in ARQ destinationInfo
by Chris Purvis 26 Jan '99

26 Jan '99

> From the various views expressed in this thread, I think it > is clear that > until at least a consensus is formed on the semantics of > multiple aliases in > ARQ's destinationInfo, an EP had better send a single alias > if the user has > any hope of predictable--not necessarily > deterministic--behavior. As with many > things H.323, _caveat transmittor_. Do we really think this is acceptable? Frankly I'll happily ensure that the Madge gatekeeper does any of the sensible options in the interests of predictable behaviour! My vote would be for checking consistency of aliases within the GK's database (because it really ought to enable endpoints to give the user more meaningful error messages than a wrong number), but we can go with first past the post if we can reach concensus that way. We COULD make it configurable, but I have a bad feeling about that. 1. What does it gain anybody over specifying something (except even more user-confusion)? 2. Assuming we want to define the same behaviour for LRQs in a multiple gatekeeper environment (which seems sensible), people may get results that surprise them due to different gatekeepers being differently configured. Can we start by agreeing over whether we need agreement (I say we do), and then, if we DO think we need agreement, agree on WHAT? 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

APC numbers
by Sakae OKUBO 25 Jan '99

25 Jan '99

Dear Mr. Gur Kimchi, Dear Mr. Reinhard Scholl, Dear Mr. Joon Maeng, GK> May I request an APC number for the latest H.323 Annex E text, GK> which is based on the Annex E white-paper with minor editorial GK> changes. APC-1496 has been allocated to your contribution. The source is understood as Editors (D Gurle, G Kimchi), please advise me if this is not the case. RS> attached is a contribution from TIPHON, "Requirements for a RS> Protocol at Reference Point N: Media Gateway Controller to RS> Media Gateway," for the forthcoming ITU SG 16 meeting. The RS> document will be presented by Gur Kimchi. Could you please RS> assign an APC-number ? Does the format of the document RS> have to be changed ? APC-1497 has been allocated to your contribution. The format can be unchanged; I will place the file at the ftp site. JM> Please allocate APC numbers for the documents I am going to JM> submit to Q13/SG16 at Monterey meeting. I may need two numbers JM> since I have a MS Word document and a set of PowerPoint slides. APC-1498 and APC-1499 have been allocated to your 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 *********************************************************** ---------------------------------------------------------------------- APC- Source Title ---------------------------------------------------------------------- 1486 SG11 Q.20/11 DSS2 protocol provision of adaptive timing recovery used for transmitting clock 1487 SG9 Q.31/9 Progress report on Webcasting 1488 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q 11, 12, 13 and 14 on MPEG-4 Systems on H.32X 1489 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q11, 12, 13, and 14 on MPEG-4 Audio on H.32X 1490 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q12 on Common Text Recommendations 1491 Nokia GSM in H.323 1492 AT&T H.323 Differentiated Services and Their Protocol Architectures 1493 AT&T Viewgraphs presentation for "H.323 Differentiated Services and Their Protocol Architectures" 1494 AT&T TIA/EIA IS-641 Enhanced Full-Rate Speech Codec for H.323 1495 Editor (G Kajos) Changes to H.341 Annexes 1496 Editors (D Gurle, G Kimchi) Editorial changes to H.323 Annex E text 1497 TIPHON Requirements for a Protocol at Reference Point N: Media Gateway Controller to Media Gateway 1498 VTEL H.323 QoS (Quality of Service) in the Policy Based Network 1499 VTEL Slides Presentation for H.323 QoS (Quality of Service) in the Policy Based Network ----------------------------------------------------------------------

1 0

register
by Owens, Peter 25 Jan '99

25 Jan '99

register Abatis Systems Corporation Suite 200 -8900 Nelson Way Burnaby, B.C. V5A 4W9 Canada Tel: +1 604 294 8828 ext. 4721

1 0

Re: Multiple aliases in ARQ destinationInfo
by Paul Long 25 Jan '99

25 Jan '99

>From the various views expressed in this thread, I think it is clear that until at least a consensus is formed on the semantics of multiple aliases in ARQ's destinationInfo, an EP had better send a single alias if the user has any hope of predictable--not necessarily deterministic--behavior. As with many things H.323, _caveat transmittor_. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Jim Toga [SMTP:jim.toga@INTEL.COM] Sent: Friday, January 22, 1999 4:15 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Multiple aliases in ARQ destinationInfo At 06:40 PM 1/22/99 -0500, Dr SantoW wrote: >[SNIP] >2. Jim Toga envisions an endpoint that would send a call request, specifying >MULTIPLE aliases to the GK. These aliases all match to a single device. >The GK would find the device and the call would get connected. The two >devices would then negotiate what kind of call it is (audio only vs. >multimedia) by way of evaluating the aliases in the order they were >specified. > Note quite what I meant to imply..... The client _MAY_ present multiple aliases to the GK. These aliases MAY or _MAY-NOT_ match to a single device. The question point is: a) Does the GK return the first match? b) If not, what happens on an exhaustive search that returns different transport addresses? In either case the GK can only return one address in the ACF. In either case the EP cannot tell what happend from a protocol point of view. There may be a _big_ difference from a service point of view however. It should definitely be a policy/configuration widget on the GK. The question in my mind is should the EP explicitly request one behavior or the other? (similar to the GK-routing flag) jimt. +1-503-264-8816(voice) Intel - Hillsboro, OR mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41

1 0

FW: Internet Telephony
by Callaghan, Robert 25 Jan '99

25 Jan '99

-----Original Message----- From: Mohammed Atiquzzaman [mailto:atiq@engr.udayton.edu] Sent: Monday, January 25, 1999 9:35 AM To: iptel(a)lists.research.bell-labs.com Subject: CFP: Internet Telephony Call for Papers Special Issue of IEEE COMMUNICATION MAGAZINE on Internet Telephony Due to the potential economic advantages, the integration of several media is desirable and very attractive. Today, however, voice over IP remains somewhat of a technical novelty, hindred by a number of existing problems to provide an assured voice quality. The likely prognosis is that over the next year or two, the advent of Resource Reservation Protocol (RSVP) and increased enterprise network bandwidth (achieved with ATM WAN services) could give a boost to voice over IP. This special issue is to bring experts in the field to share with IEEE COMMUNICATION MAGAZINE readers the current problems, components, and experiments in "Internet Telephony". Desirable features of a voice-over-IP system include: * Optimal use of bandwidth. * Capacity management. * Support of speech quality. * Flexible integration into voice environment (e.g., PBX). * Enterprise network ready (support LAN/WAN/Internet protocols for direct attachment). * System-level scalability: must be easy to add PBX-side interfaces to support growth in requirements and appropriate links. * Network-level scalability: must be able to support mapping of a sufficient number of extensions (perhaps several thousands) to the respective IP addresses of the destination gateway. A master database with distributed upgrade may be desirable. IEEE COMMUNICATION MAGAZINE announces a forthcoming issue on "Internet Telephony". Prospective authors should follow IEEE COMMUNICATION MAGAZINE guidelines and submit an electronic (PDF file or a PostScript file viewable by Ghostview) copy of the manuscript to one of the Guest Editors listed below. Articles addressing both traditional and innovative products will be given preference. Topics include, but are not limited to: * Voice over IP/ATM * IP over ATM/FR for Multimedia * Traffic Control for Multimedia/Internet Telephony * QoS Control of Voice over IP * Evolution of the VPN and PBX environment * Traffic Capacity Management and Routing Algorithms for Multimedia. Full manuscript submission deadline June 30, 1999 Notification of acceptance October 30, 1999 Publication Schedule April 2000 Mohsen Guizani Ammar Rayes Mohammed Atiquzzaman Elec. & Comp. Engr. Director, Solution Arch. Elec. & Comp. Engr. Univ. of Missouri-Columbia Traffic Capacity Manag. 300 College Park 5605 Troost Avenue & Planning University of Dayton Kansas City, Bellcore, 444 Hoes Lane Dayton, MO 64110-2823, USA. Piscataway, NJ 08854, USA. Ohio 45469-0226, USA. Tel: (816) 235-1550 Tel: (732) 699-3669 Tel. (937) 229 3183 Fax: (816) 235-1260 arayes(a)notes.cc.bellcore.com Fax. (937) 229-4529 guizanim(a)umkc.edu atiq(a)engr.udayton.edu --------- This message came from the IETF IPTEL Working Group Mailing List.

1 0

Re: apc number for moterey meeting
by Sakae OKUBO 25 Jan '99

25 Jan '99

Dear Mr. Kajos, > Please allocate an APC number for changes to H.341 Annexes. APC-1495 has been allocated to your contribution as attached. I indicated the source as Editor, but please advise me if it is otherwise. 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 *********************************************************** ---------------------------------------------------------------------- APC- Source Title ---------------------------------------------------------------------- 1486 SG11 Q.20/11 DSS2 protocol provision of adaptive timing recovery used for transmitting clock 1487 SG9 Q.31/9 Progress report on Webcasting 1488 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q 11, 12, 13 and 14 on MPEG-4 Systems on H.32X 1489 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q11, 12, 13, and 14 on MPEG-4 Audio on H.32X 1490 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q12 on Common Text Recommendations 1491 Nokia GSM in H.323 1492 AT&T H.323 Differentiated Services and Their Protocol Architectures 1493 AT&T Viewgraphs presentation for "H.323 Differentiated Services and Their Protocol Architectures" 1494 AT&T TIA/EIA IS-641 Enhanced Full-Rate Speech Codec for H.323 1495 Editor Changes to H.341 Annexes (G Kajos) ----------------------------------------------------------------------

1 0

Monterey meeting - hotel cutoff date and document list
by Sakae OKUBO 25 Jan '99

25 Jan '99

Dear Q.12-14/16 experts, This is to remind you that the hotel reservation cutoff date is Wednesday, 27 January 1999. ftp://standard.pictel.com/avc-site/9902_Mon/Notice_Monterey.txt ftp://standard.pictel.com/avc-site/9902_Mon/Invitation_Monterey.zip Please directly contact Embassy Suites on Monterey Bay using the form included in the host's invitation. Participants are requested to book at the Embassy Suites, as its "conference arrangement" price is very reasonable, paying also for the conference facilities including beverages. Your cooperation helps the meeting host. Attached please find the current list of registered documents for the meeting. Early registration of your documents is requested to justify holding the meeting. 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 *********************************************************** ---------------------------------------------------------------------- APC- Source Title ---------------------------------------------------------------------- 1486 SG11 Q.20/11 DSS2 protocol provision of adaptive timing recovery used for transmitting clock 1487 SG9 Q.31/9 Progress report on Webcasting 1488 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q 11, 12, 13 and 14 on MPEG-4 Systems on H.32X 1489 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q11, 12, 13, and 14 on MPEG-4 Audio on H.32X 1490 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q12 on Common Text Recommendations 1491 Nokia GSM in H.323 1492 AT&T H.323 Differentiated Services and Their Protocol Architectures 1493 AT&T Viewgraphs presentation for "H.323 Differentiated Services and Their Protocol Architectures" 1494 AT&T TIA/EIA IS-641 Enhanced Full-Rate Speech Codec for H.323 ----------------------------------------------------------------------

1 0

complete solutions
by MIRRORCOM DUPLICATION 23 Jan '99

23 Jan '99

We at MIRRORCOM DUPLICATION would like to thank you for opening and reading this E-mail. The purpose of it is to introduce our selfÕs to you or your company as the complete solution to your VIDEO DUPLICATION needs. Our goal is to provide our clients with the best rates possible for VHS dubs, Custom package design, and fulfillment of product. Please visit our web site at: www.together.net/~dawnc for more information about us. Or contact us at: 819-868-0428 . Once again thank you for your time.

1 0

Re: Multiple aliases in ARQ destinationInfo
by Santo Wiryaman 22 Jan '99

22 Jan '99

As a GK developer, I share Paul Long's desire to arrive at some concensus on how a GK (or a collection of GK's) should treat multiple aliases in an ARQ. Several suggestions had been offered such as interpretation 1, interpretation 4, interpretation 4 plus Chris' refinements, and so on. Before we define how the GK should interpret multiple aliases, I think we need to find out what the endpoints (or users of those endpoints) mean when they send multiple aliases in a call. In this short email discussion of 4 people, there seemed to be multiple opinions on what this means: 1. Paul Long envisions an endpoint that would send a call request, specifying MULTIPLE aliases to the GK. These aliases match to different systems (e.g. #@work, #@home, cellphone#, fax#, etc.). The GK would find a match to one of these devices and the call would get routed to one of them. 2. Jim Toga envisions an endpoint that would send a call request, specifying MULTIPLE aliases to the GK. These aliases all match to a single device. The GK would find the device and the call would get connected. The two devices would then negotiate what kind of call it is (audio only vs. multimedia) by way of evaluating the aliases in the order they were specified. 3. Chris Purvis suggested an endpoint that would send a call request, specifying MULTIPLE aliases to the GK. The first alias would be the GW of choice. Subsequent alias(es) would contain the address of the "ultimate" destination. 4. Chris Purvis described an endpoint that would send a call request, specifying ONE alias to the GK. This alias is assigned to a person who may be in different places (i.e different endpoints) at different times. S/he somehow notifies the system where to route the call. At the time of the call, the GK would consult a dBase and route the call to the endpoint where the person is. This scenario is not really relevant to the issue at hand because the endpoint sends ONE alias in the ARQ. It is mentioned here to show as an example for how the objectives of scenario 1 can be accomplished without sending multiple aliases. 5. Santo knows of systems out there (MCU's) that register multiple aliases, each corresponding to a conference. Say, MCU1 registers "CONF_A", "CONF_B", "CONF_C" as its aliases. When EP1 calls "CONF_A", the GK would return the address of MCU1. The SETUP from EP1 would later arrive at MCU1 and the destination is "CONF_A". Becuase of this, MCU1 knows that the endpoint wants to joint "CONF_A" and the call is accepted. However, if MCU1 receives a SETUP with multiple destinations such as "CONF_A", "CONF_B", "CONF_C" it might get confused and drop the call (or use interpretation 1 and therefore use the first alias only). This is an example of a potential problems that can result from multiple aliases, not at the GK but at the destination endpoint (e.g. an MCU). I am sure the list above is not comprehensive. If 3 or more people join in the discussion they may have half a dozen more uses for multiple aliases. Some of the multiple alias interpretations (such as #1 - #3 described above) may all have valid and good reasons behind them. Since there can be many interpretations for multiple aliases from the users' point of view (some perhaps conflicting, e.g. #1 conflicts with #3) , it would be hard to specify a rule on the GK which can satisfy all the users' requirement. Some comments to Jim Toga's posting are within the enclosed text. -santo > -----Original Message----- > From: Jim Toga [SMTP:jim.toga@INTEL.COM] > Sent: Friday, January 22, 1999 12:46 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Multiple aliases in ARQ destinationInfo > > At 10:50 AM 1/22/99 -0500, Santo wrote: > [SNIP] > > >Of course I am not saying that if it hasn't been done it is a bad thing. > I > >am merely suggesting that there may be a better way of doing it (such as > the > >system in the UK described by Chris). It was not a rethoric question > >either; I truly wanted to know if Paul knows of any system out there > where > >you can "blast" dial with multiple numbers and hope to get connected to > one > >of them. > > I would offer as a model both DNS (which allows multiple 'aliases' to > point > to a single host) and 'hunt groups' as mentioned by ChrisP which are very > useful in situations other than call centers. To Chris's point, I also > believe that this functionality should be partially (if not completely) > implemented by a Gatekeeper - the multiple aliases simply gives the GK an > effiecient start. [Santo Wiryaman] The DNS analogy is done today by e.g. an MCU registering multiple aliases for the same CallSignalAddress. Even if a machine has multiple DNS names (aliases) such as in: 140.242.112.1 pj , PaulJ, pJones, Paul_Jones when user applications would "connect" to that system, they would typically use one of them, e.g. : ping pj telnet Paul_Jones.XYZ.com ftp PaulJ What we are dealing here is specifying multiple destinations all at once. It is like saying: ftp m1,m2,m3,m4 Which machine should the system connect to? Perhaps m3 because m1 and m2 are on a different domain? I fully agree with Jim and Chris that routing and hunt-group functionality should be implemented partly if no completely in the GK. I am still having problem seeing how multiple aliases helps the process. Unless, of course the GK is setup to use the same interpretation rules as specified by the site. Then this becomes a site configuration issue doesn't it? Another facet to this is if the aliases have some implied (agreement > between calling and called parties) functionality to them. For example I > might have both and rfc822 alias and an E.164 alias. The implications > might be that they are associated with a multimedia recipient and an > audio-only client respectively. Depending on what the caller wants to do > they might put one 'higher' in the alias array. Note that these are (or > might be) _service_ level capabilities, not the same thing as offered by > H.245.... > > > With respect to 'errror' conditions or inconsistencies on the GK database > when doing look-ups, it seems as though that would really be a policy > issue. The usual behaviour of 'least astonishment' should be the default. > > Comments? > > jimt. > > > > > >I share Chris' concern about such a "blast" dial system which is > >non-determinism. > > > > > > > > >Regards, > > > >-santo > > > >> -----Original Message----- > >> From: Chris Purvis [SMTP:CPurvis@MADGE.COM] > >> Sent: Friday, January 22, 1999 5:33 AM > >> To: ITU-SG16(a)mailbag.cps.intel.com > >> Subject: Re: Multiple aliases in ARQ destinationInfo > >> > >> Time for me to wade in on a couple of points here too, I'm afraid... > >> > >> First let me say what we've implemented so far: > >> 4. Respond with ACF if at least one alias is registered, starting > >> with > >> the first one. > >> > >> Having said that, I'm not certain that's how things should be. I > believe > >> the "right" answer is none of those Paul suggests. My starting point, > >> though, is that at this stage of placing a call, line-hunting is the > job > >> of > >> the gatekeeper, not the endpoint. If one wants to do line-hunting at > the > >> endpoint, one should be sending a number of ARQs - note that there's no > >> reason an endpoint can't have multiple ARQs outstanding at the same > time, > >> so > >> this should not add significantly to call setup latency. > >> Hence what I believe SHOULD happen is that the gatekeeper > >> 1. If it can match anything within its zone, should ensure that > different > >> aliases in the ARQ do not point to different destinations within the > zone. > >> If there is such disagreement, the GK should return ARJ. > >> Either: > >> 2a. Repeat the same policy at any other levels of search that it > engages > >> in > >> (LRQs etc). > >> or (probably "better" from the point of view of call setup times, > although > >> less deterministic): > >> 2b. If a search procedure needs to be done outside of the zone, use the > >> first positive reply you get > >> > >> One use I see for these multiple aliases, is to avoid the abomination > of > >> dial-prefixes for dialing out through gateways. The first alias should > >> point to a gateway (probably by name rather than number), subsequent > >> aliases > >> in a setup message should tell the gateway what to do. Clever > gatekeepers > >> may want to have policy on what outside lines are permitted to certain > >> users, and therefore need to see this information at this stage. > >> Unfortunately nobody seems to use multiple aliases like this... > >> > >> In answer to a couple of other specific points: > >> > >> [Santo] > >> >In practice, could you tell us an example of a widely deployed > >> communication > >> >system where you can "dial" multiple destinations (e.g. home phone, > work > >> >phone, cell phone, fax number, emailID) at once and "it" will get you > the > >> >most suitable destination? I can imagine a smart phonebook/dialer > which > >> >would take the addresses and "dial" one number at a time until it gets > >> >connected. But the smarts is in the application, not in the "switch" > (in > >> >our case the GK). > >> Are you suggesting that if such a thing hasn't been done before it is > not > >> a > >> "good" thing to do? > >> Incidentally the start of such a thing does exist, at least in the UK. > I > >> have friends for whom I can dial a single number. They tell the server > >> for > >> this number where they are at any given time, and when I dial their > >> "personal numebr" I talk to the person, whether they happen to be at > home > >> (on their home number), at work (on their work number) or elsewhere (on > >> their mobile phone). We have a huge opportunity to improve users' > >> experience. > >> > >> [Paul] > >> >Is an EP required to use the exact same alias list in the Setup that > it > >> used > >> >in the ARQ? I don't think so. Sounds like it should use the alias list > >> sent > >> >back in the ACF's destinationInfo field, which would presumably > contain > >> only > >> >the alias(es) that resolved into the provided transport address. Good > >> point, > >> >though. Needs more thought. What if more than one alias resolved into > the > >> same > >> >address and the GK returned all of the resolved aliases? But then, > maybe > >> we're > >> >trying to over-engineer the problem. Maybe it just makes good sense to > >> the > >> >users in these situations to provide a single alias, and everything > just > >> >works... :-) > >> The ACF's destinationInfo field only appears in version 2, but yes this > is > >> certainly what you should use where present (if it's absent, you can't > do > >> anything other than use what you used in the setup message). Do any > >> endpoints complain when they see extra, superfluous aliases in setup > >> messages addressed to them? I doubt it. Even gateways should surely > use > >> what they can make sense of and ignore anything else. The question > mark > >> is > >> how the destinationInfo, destExtraCallInfo and remoteExtensionAddress > >> fields > >> in ACF should be mapped to the various fields in the setup message > >> (CalledPartyNumber, CalledPartySubAddress, destinationAddress, > >> DestExtraCallInfo, remoteExtensionAddress). I seem to remember hearing > at > >> some point that they should be mapped into the fields of the same name, > >> except that the first destinationInfo that is a phone number is moved > into > >> CalledPartyNumber, and CalledPartySubAddress. I believe if implemented > >> this > >> is a potential source of incompatibility with TIPHON however, because > >> (again > >> from memory - no doubt I'll be corrected if I'm wrong!) TIPHON > equipment > >> is > >> instructed to ignore CalledPartyNumber. Whatever "correct" procedure > is, > >> though, it should be agreed and documented. > >> > >> [Paul] > >> >Simple, return the transport address of the first resolved alias. > What's > >> wrong > >> >with that? > >> Possible non-determinism (see 2b above). > >> > >> 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-503-264-8816(voice) Intel - Hillsboro, OR > mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int > PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41

2 1

Re: Multiple aliases in ARQ destinationInfo
by Paul Long 22 Jan '99

22 Jan '99

-----Original Message----- From: Jim Toga [SMTP:jim.toga@INTEL.COM] Sent: Friday, January 22, 1999 9:46 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Multiple aliases in ARQ destinationInfo With respect to 'errror' conditions or inconsistencies on the GK database when doing look-ups, it seems as though that would really be a policy issue. The usual behaviour of 'least astonishment' should be the default. Comments? I agree that it should be a policy issue. An administrator might not want to delay the call setup by having to look up all aliases in its registration database before responding to an ARQ. I know that one GK vendor I spoke to at the interop had this concern. Plus, what's the danger in not having all aliases resolve to the same transport address? The caller gets a wrong number? Not like that hasn't happened before. I still like good old #4. Paul Long Smith Micro Software, Inc.

1 0

complete solution to your VIDEO DUPLICATION needs
by dawnc＠TOGETHER.NET 22 Jan '99

22 Jan '99

We at MIRRORCOM DUPLICATION would like to thank you for opening and reading this E-mail. The purpose of it is to introduce our self's to you or your company as the complete solution to your VIDEO DUPLICATION needs. Our goal is to provide our clients with the best rates possible for VHS dubs, Custom package design, and fulfillment of product. Please visit our web site at: http://www.together.net/~dawnc for more information about us. Or contact us at: 819-868-0428 . Once again thank you for your time.

1 0

Re: Multiple aliases in ARQ destinationInfo
by Santo Wiryaman 22 Jan '99

22 Jan '99

Paul, Chris: First, a thank you to Paul for correcting my mistake. You are absolutely right that the extra phone numbers are to be placed in the destExtraCallInfo in the ARQ. I apologise for my lapse of memory and for not double checking the standard. Second, I agree with Chris that a single "number" that can follow a person is a very good thing. In the example that Chris gave, though, the user of the endpoint "dials" a single number. The "network" (in our case the GK) may provide a dBase search on how to route this number at that particular time based on some rules consistent with the service being provided. In this case the ARQ would contain one "number". Of course I am not saying that if it hasn't been done it is a bad thing. I am merely suggesting that there may be a better way of doing it (such as the system in the UK described by Chris). It was not a rethoric question either; I truly wanted to know if Paul knows of any system out there where you can "blast" dial with multiple numbers and hope to get connected to one of them. I share Chris' concern about such a "blast" dial system which is non-determinism. Regards, -santo > -----Original Message----- > From: Chris Purvis [SMTP:CPurvis@MADGE.COM] > Sent: Friday, January 22, 1999 5:33 AM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Multiple aliases in ARQ destinationInfo > > Time for me to wade in on a couple of points here too, I'm afraid... > > First let me say what we've implemented so far: > 4. Respond with ACF if at least one alias is registered, starting > with > the first one. > > Having said that, I'm not certain that's how things should be. I believe > the "right" answer is none of those Paul suggests. My starting point, > though, is that at this stage of placing a call, line-hunting is the job > of > the gatekeeper, not the endpoint. If one wants to do line-hunting at the > endpoint, one should be sending a number of ARQs - note that there's no > reason an endpoint can't have multiple ARQs outstanding at the same time, > so > this should not add significantly to call setup latency. > Hence what I believe SHOULD happen is that the gatekeeper > 1. If it can match anything within its zone, should ensure that different > aliases in the ARQ do not point to different destinations within the zone. > If there is such disagreement, the GK should return ARJ. > Either: > 2a. Repeat the same policy at any other levels of search that it engages > in > (LRQs etc). > or (probably "better" from the point of view of call setup times, although > less deterministic): > 2b. If a search procedure needs to be done outside of the zone, use the > first positive reply you get > > One use I see for these multiple aliases, is to avoid the abomination of > dial-prefixes for dialing out through gateways. The first alias should > point to a gateway (probably by name rather than number), subsequent > aliases > in a setup message should tell the gateway what to do. Clever gatekeepers > may want to have policy on what outside lines are permitted to certain > users, and therefore need to see this information at this stage. > Unfortunately nobody seems to use multiple aliases like this... > > In answer to a couple of other specific points: > > [Santo] > >In practice, could you tell us an example of a widely deployed > communication > >system where you can "dial" multiple destinations (e.g. home phone, work > >phone, cell phone, fax number, emailID) at once and "it" will get you the > >most suitable destination? I can imagine a smart phonebook/dialer which > >would take the addresses and "dial" one number at a time until it gets > >connected. But the smarts is in the application, not in the "switch" (in > >our case the GK). > Are you suggesting that if such a thing hasn't been done before it is not > a > "good" thing to do? > Incidentally the start of such a thing does exist, at least in the UK. I > have friends for whom I can dial a single number. They tell the server > for > this number where they are at any given time, and when I dial their > "personal numebr" I talk to the person, whether they happen to be at home > (on their home number), at work (on their work number) or elsewhere (on > their mobile phone). We have a huge opportunity to improve users' > experience. > > [Paul] > >Is an EP required to use the exact same alias list in the Setup that it > used > >in the ARQ? I don't think so. Sounds like it should use the alias list > sent > >back in the ACF's destinationInfo field, which would presumably contain > only > >the alias(es) that resolved into the provided transport address. Good > point, > >though. Needs more thought. What if more than one alias resolved into the > same > >address and the GK returned all of the resolved aliases? But then, maybe > we're > >trying to over-engineer the problem. Maybe it just makes good sense to > the > >users in these situations to provide a single alias, and everything just > >works... :-) > The ACF's destinationInfo field only appears in version 2, but yes this is > certainly what you should use where present (if it's absent, you can't do > anything other than use what you used in the setup message). Do any > endpoints complain when they see extra, superfluous aliases in setup > messages addressed to them? I doubt it. Even gateways should surely use > what they can make sense of and ignore anything else. The question mark > is > how the destinationInfo, destExtraCallInfo and remoteExtensionAddress > fields > in ACF should be mapped to the various fields in the setup message > (CalledPartyNumber, CalledPartySubAddress, destinationAddress, > DestExtraCallInfo, remoteExtensionAddress). I seem to remember hearing at > some point that they should be mapped into the fields of the same name, > except that the first destinationInfo that is a phone number is moved into > CalledPartyNumber, and CalledPartySubAddress. I believe if implemented > this > is a potential source of incompatibility with TIPHON however, because > (again > from memory - no doubt I'll be corrected if I'm wrong!) TIPHON equipment > is > instructed to ignore CalledPartyNumber. Whatever "correct" procedure is, > though, it should be agreed and documented. > > [Paul] > >Simple, return the transport address of the first resolved alias. What's > wrong > >with that? > Possible non-determinism (see 2b above). > > Regards, > Chris > -- > Dr Chris Purvis - Senior Development Engineer, WAVE CC Software > Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. > ENGLAND > Phone: +44 1753 661 359 email: cpurvis(a)madge.com

2 1

Re: Relationship of H.323 and H.245 versions
by Paul Long 22 Jan '99

22 Jan '99

Chris, In ASN.1-speak, being able to pass an ASN.1 value, typically transparently, is called "relaying" [1]. Luckily, the PER encoding used by both H.245 and H.225.0 are relay-safe [2]. An H.323 entity is therefore technically able [3] to route a message originally encoded using an abstract syntax other than the one it uses itself. Frankly, I don't see how it could be otherwise. Are you saying, for example, that a v4 EP and a v5 EP routed via a v2 GK are both relegated to using v2? Will the GK modify all protocol identifiers to indicate this reduction, or will the EPs continue to think they can use v4 signaling? It's a real shame if the GK becomes the weakest link when there is no normative reason for this. Our stack can support relaying, but then I wrote it myself... :-) Maybe you should have a talk with your stack vendor. [1] 3.8.23/X.691(1994): "relay-safe encoding: A complete encoding of an abstract syntax value which can be decoded (including any embedded encodings) without knowledge of the presentation layer defined context set that formed the environment in which the encoding was performed." [2] 7.3/X.691(1994): "PER encodings are always relay-safe provided the abstract values of the types EXTERNAL, EMBEDDED PDV and CHARACTER STRING are constrained to prevent the carriage of presentation context identifiers." [3] C.2(Non-normative)/X.691(1994): "Where an abstract syntax value contains embedded material that is encoded using a transfer or abstract syntax different from that associated with the abstract syntax value, it is strongly recommended that the embedded material be encoded in a relay-safe manner." Paul Long Smith Micro Software, Inc. -----Original Message----- From: Chris Purvis [SMTP:CPurvis@MADGE.COM] Sent: Friday, January 22, 1999 1:55 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Relationship of H.323 and H.245 versions Paul, The problem with this is that with the way certain stacks work an application (such as a gatekeeper) can not necessarily get hold of things that weren't fully decoded ASN.1-wise, and therefore can not relay them onwards. What would happen when, for instance, the Madge gatekeeper (H.323v2), received a message from (say) a v4 endpoint containing "new" mandatory fields, is that it would be able to forward only that part of the message which is understood in the (v2) ASN.1 of which it is aware. To do anything different for future versions may or may not be possible (my understanding of PER encoding isn't quite up to being definitive on this) but if it is possible it would require many stack vendors and people with their own stacks to do some significant rewriting. I think Jim's right, much as it would be nice to be cleverer. Chris > -----Original Message----- > From: Paul Long [mailto:Plong@SMITHMICRO.COM] > Sent: 21 January 1999 10:21 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Relationship of H.323 and H.245 versions > > > From: Jim Toga [SMTP:jim.toga@INTEL.COM] > This is getting close. One potential > problem surrounds > intermediaries > (for example GKs in a GK-routed call). We > need to indicate > what exactly is > the expected behaviour of 'M' entities when > they get 'N' type > messages > (that look like 'M' messages with extentions.) > > I would contend that the reality of the > situation is that all > we can > stipulate, is that the 'M' entities don't crash in the > presense of 'N' > messages. We can't mandate that 'M's pass new > (uninterpreted/not-understood) data on. > Obviously if there is > an existing > opaque field defined, this _shall_ be forwarded. > > comments? > > I thought I addressed this in the last sentence, "In > addition, if a >product > is relaying an ASN.1 value, it shall encode the same value > that it >decoded, > regardless of its own version or the version of the value's > sender." This is > for intermediate entities such as gatekeepers that relay, or > route, call > signaling and control messages between entities. My company > is not in the > gatekeeper business, so with my lack of familiarity I could > be off base here, > but I believe this statement is necessary to mitigate the > earlier statement, > "Each product shall _encode_ and decode the H.245 and H.225.0 > ASN.1 syntax > trees defined in their respective version of H.323." The last sentence > sanctions, for example, a v1 gatekeeper relaying v2 messages. > I assume this is > a requirement and that we can indeed mandate it. > > Was I not clear, or did I simply not address your concern? > > Paul Long > Smith Micro Software, Inc. >

1 0

Re: Multiple aliases in ARQ destinationInfo
by Paul Long 22 Jan '99

22 Jan '99

-----Original Message----- From: Santo Wiryaman [SMTP:swiryaman@VIDEOSERVER.COM] Sent: Friday, January 22, 1999 7:51 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Multiple aliases in ARQ destinationInfo I truly wanted to know if Paul knows of any system out there where you can "blast" dial with multiple numbers and hope to get connected to one of them. No, I don't know of any. I share Chris' concern about such a "blast" dial system which is non-determinism. My primary interest is in raising awareness of this issue among GK vendors. As primarily an EP vendor, we don't want our users to experience the kind of variance in behavior that I experienced at the last interop. My secondary interest is in having a normative or at least consensus-based agreement about what is the right thing to do in light of the ambiguity in the Recommendations. Lastly, I believe that interpretation 4 or possibly Chris' improvement makes the most sense. Paul Long Smith Micro Software, Inc.

1 0

Re: Multiple aliases in ARQ destinationInfo
by Chris Purvis 22 Jan '99

22 Jan '99

Time for me to wade in on a couple of points here too, I'm afraid... First let me say what we've implemented so far: 4. Respond with ACF if at least one alias is registered, starting with the first one. Having said that, I'm not certain that's how things should be. I believe the "right" answer is none of those Paul suggests. My starting point, though, is that at this stage of placing a call, line-hunting is the job of the gatekeeper, not the endpoint. If one wants to do line-hunting at the endpoint, one should be sending a number of ARQs - note that there's no reason an endpoint can't have multiple ARQs outstanding at the same time, so this should not add significantly to call setup latency. Hence what I believe SHOULD happen is that the gatekeeper 1. If it can match anything within its zone, should ensure that different aliases in the ARQ do not point to different destinations within the zone. If there is such disagreement, the GK should return ARJ. Either: 2a. Repeat the same policy at any other levels of search that it engages in (LRQs etc). or (probably "better" from the point of view of call setup times, although less deterministic): 2b. If a search procedure needs to be done outside of the zone, use the first positive reply you get One use I see for these multiple aliases, is to avoid the abomination of dial-prefixes for dialing out through gateways. The first alias should point to a gateway (probably by name rather than number), subsequent aliases in a setup message should tell the gateway what to do. Clever gatekeepers may want to have policy on what outside lines are permitted to certain users, and therefore need to see this information at this stage. Unfortunately nobody seems to use multiple aliases like this... In answer to a couple of other specific points: [Santo] >In practice, could you tell us an example of a widely deployed communication >system where you can "dial" multiple destinations (e.g. home phone, work >phone, cell phone, fax number, emailID) at once and "it" will get you the >most suitable destination? I can imagine a smart phonebook/dialer which >would take the addresses and "dial" one number at a time until it gets >connected. But the smarts is in the application, not in the "switch" (in >our case the GK). Are you suggesting that if such a thing hasn't been done before it is not a "good" thing to do? Incidentally the start of such a thing does exist, at least in the UK. I have friends for whom I can dial a single number. They tell the server for this number where they are at any given time, and when I dial their "personal numebr" I talk to the person, whether they happen to be at home (on their home number), at work (on their work number) or elsewhere (on their mobile phone). We have a huge opportunity to improve users' experience. [Paul] >Is an EP required to use the exact same alias list in the Setup that it used >in the ARQ? I don't think so. Sounds like it should use the alias list sent >back in the ACF's destinationInfo field, which would presumably contain only >the alias(es) that resolved into the provided transport address. Good point, >though. Needs more thought. What if more than one alias resolved into the same >address and the GK returned all of the resolved aliases? But then, maybe we're >trying to over-engineer the problem. Maybe it just makes good sense to the >users in these situations to provide a single alias, and everything just >works... :-) The ACF's destinationInfo field only appears in version 2, but yes this is certainly what you should use where present (if it's absent, you can't do anything other than use what you used in the setup message). Do any endpoints complain when they see extra, superfluous aliases in setup messages addressed to them? I doubt it. Even gateways should surely use what they can make sense of and ignore anything else. The question mark is how the destinationInfo, destExtraCallInfo and remoteExtensionAddress fields in ACF should be mapped to the various fields in the setup message (CalledPartyNumber, CalledPartySubAddress, destinationAddress, DestExtraCallInfo, remoteExtensionAddress). I seem to remember hearing at some point that they should be mapped into the fields of the same name, except that the first destinationInfo that is a phone number is moved into CalledPartyNumber, and CalledPartySubAddress. I believe if implemented this is a potential source of incompatibility with TIPHON however, because (again from memory - no doubt I'll be corrected if I'm wrong!) TIPHON equipment is instructed to ignore CalledPartyNumber. Whatever "correct" procedure is, though, it should be agreed and documented. [Paul] >Simple, return the transport address of the first resolved alias. What's wrong >with that? Possible non-determinism (see 2b above). 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

Re: Relationship of H.323 and H.245 versions
by Chris Purvis 22 Jan '99

22 Jan '99

Paul, The problem with this is that with the way certain stacks work an application (such as a gatekeeper) can not necessarily get hold of things that weren't fully decoded ASN.1-wise, and therefore can not relay them onwards. What would happen when, for instance, the Madge gatekeeper (H.323v2), received a message from (say) a v4 endpoint containing "new" mandatory fields, is that it would be able to forward only that part of the message which is understood in the (v2) ASN.1 of which it is aware. To do anything different for future versions may or may not be possible (my understanding of PER encoding isn't quite up to being definitive on this) but if it is possible it would require many stack vendors and people with their own stacks to do some significant rewriting. I think Jim's right, much as it would be nice to be cleverer. Chris > -----Original Message----- > From: Paul Long [mailto:Plong@SMITHMICRO.COM] > Sent: 21 January 1999 10:21 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Relationship of H.323 and H.245 versions > > > From: Jim Toga [SMTP:jim.toga@INTEL.COM] > This is getting close. One potential > problem surrounds > intermediaries > (for example GKs in a GK-routed call). We > need to indicate > what exactly is > the expected behaviour of 'M' entities when > they get 'N' type > messages > (that look like 'M' messages with extentions.) > > I would contend that the reality of the > situation is that all > we can > stipulate, is that the 'M' entities don't crash in the > presense of 'N' > messages. We can't mandate that 'M's pass new > (uninterpreted/not-understood) data on. > Obviously if there is > an existing > opaque field defined, this _shall_ be forwarded. > > comments? > > I thought I addressed this in the last sentence, "In > addition, if a >product > is relaying an ASN.1 value, it shall encode the same value > that it >decoded, > regardless of its own version or the version of the value's > sender." This is > for intermediate entities such as gatekeepers that relay, or > route, call > signaling and control messages between entities. My company > is not in the > gatekeeper business, so with my lack of familiarity I could > be off base here, > but I believe this statement is necessary to mitigate the > earlier statement, > "Each product shall _encode_ and decode the H.245 and H.225.0 > ASN.1 syntax > trees defined in their respective version of H.323." The last sentence > sanctions, for example, a v1 gatekeeper relaying v2 messages. > I assume this is > a requirement and that we can indeed mandate it. > > Was I not clear, or did I simply not address your concern? > > Paul Long > Smith Micro Software, Inc. >

1 0

Re: APC Numbers: ITU-T Q.11-15 Meeting
by Sakae OKUBO 21 Jan '99

21 Jan '99

Dear Mr. Roy, > Kindly issue APC numbers for the following three contributions for the > upcoming meeting: The follwoing APC numbers have been allocated to your three contributions: APC-1492 H.323 Differentiated Services and Their Protocol Architectures APC-1493 Viewgraphs presentation for "H.323 Differentiated Services and Their Protocol Architectures" APC-1494 TIA/EIA IS-641 Enhanced Full-Rate Speech Codec for H.323 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

Re: Multiple aliases in ARQ destinationInfo
by Paul Long 21 Jan '99

21 Jan '99

From: Santo Wiryaman [SMTP:swiryaman@VIDEOSERVER.COM] Personally, my preference is for #1. Keep it simple. The reason is that an ACF from a GK does not necessarily mean that the endpoint is registered with the GK. In other words, when a GK receives an ARQ and does not find the alias registered, it has to look somewhere else: other GK's (using LRQ), some GK's lookup in ILS servers, DNS, etc.. When the ARQ has an ordered list of aliases, what should the GK do? What if alias #1 is found in a different zone2, alias #2 is found in zone3, and alias #3 is registered locally in zone1? Which IP address should the GK return in the ACF? Further more, the LRQ process (and other address lookup procedures) are asynchronous. The LCF for alias #2 might come back before the LCF from alias #1. Having the LCF for alias #2, does the GK have to wait around for the LCF of alias #1 (which may never arrive). Simple, return the transport address of the first resolved alias. What's wrong with that? The ordered list of aliases indicates a _preferred_ search order. In practice, I doubt whether users will consciously place aliases in a particular order, so returning the address of any alias will most likely be satisfactory. This could be a quality-of-implementation issue, too. A GK could be configured to delay admission a bit in an attempt to return the address of the earliest-possible alias in the list. In practice, could you tell us an example of a widely deployed communication system where you can "dial" multiple destinations (e.g. home phone, work phone, cell phone, fax number, emailID) at once and "it" will get you the most suitable destination? Hey, it's a brave new world out there. :-) How about a universal mailbox? I think having multiple types of aliases (e164, h323-ID, url-ID, transportID, email-ID, partyNumber(publicNumber, privateNumber,nationalStandardPartyNumber) ) is confusing enough. Placing multiple aliases in an ARQ would further complicate matters. The facility is already in the Recommendation for this. We can't take it out. EP and GK vendors can decide what makes sense to them. If you only want to look at the first alias, go ahead. If I am not mistaken, the original reason for defining destinationInfo in ARQ as a sequence of aliases is to convey two (or more) phonenumbers to use for a single call. For example, to make an H.323 to an H.320 call via an ISDN GW using 2B lines, there can be two aliases: "918005551212" and "918005551213". Therefore, all aliases in the field are used for the same call; it is not a list of alternative aliases in prefered order. I believe you are mistaken. The second alias goes in the ARQ's destExtraCallInfo field: 7.11.1/H.225.0v2: "destExtraCallInfo - contains external addresses for multiple calls." The field of the same name in the Setup message is used for the same thing: 7.3.10/H.225.0v2: "destExtraCallInfo - needed to make possible additional channel calls, i.e. for a 2*64 Kbps call on the WAN side. Shall only contain E.164 addresses and shall not contain the number of the initial channel." As a side note, some H.323 systems (e.g. an MCU, a GK-routed GK) look into the destinationAddress field in the SETUP message to see where to further route the call. Presumably, if there is a list of aliases in the ARQ, there would also be a list of aliases in the SETUP. How should these systems interpret the list of aliases? Is an EP required to use the exact same alias list in the Setup that it used in the ARQ? I don't think so. Sounds like it should use the alias list sent back in the ACF's destinationInfo field, which would presumably contain only the alias(es) that resolved into the provided transport address. Good point, though. Needs more thought. What if more than one alias resolved into the same address and the GK returned all of the resolved aliases? But then, maybe we're trying to over-engineer the problem. Maybe it just makes good sense to the users in these situations to provide a single alias, and everything just works... :-) Paul Long Smith Micro Software, Inc.

1 0

Re: Multiple aliases in ARQ destinationInfo
by Santo Wiryaman 21 Jan '99

21 Jan '99

Hi Paul, Thanks for bringing up this interesting subject. The original reason for having multiple aliases may have been forgotten by many (more on this). Personally, my preference is for #1. Keep it simple. The reason is that an ACF from a GK does not necessarily mean that the endpoint is registered with the GK. In other words, when a GK receives an ARQ and does not find the alias registered, it has to look somewhere else: other GK's (using LRQ), some GK's lookup in ILS servers, DNS, etc.. When the ARQ has an ordered list of aliases, what should the GK do? What if alias #1 is found in a different zone2, alias #2 is found in zone3, and alias #3 is registered locally in zone1? Which IP address should the GK return in the ACF? Further more, the LRQ process (and other address lookup procedures) are asynchronous. The LCF for alias #2 might come back before the LCF from alias #1. Having the LCF for alias #2, does the GK have to wait around for the LCF of alias #1 (which may never arrive). In practice, could you tell us an example of a widely deployed communication system where you can "dial" multiple destinations (e.g. home phone, work phone, cell phone, fax number, emailID) at once and "it" will get you the most suitable destination? I can imagine a smart phonebook/dialer which would take the addresses and "dial" one number at a time until it gets connected. But the smarts is in the application, not in the "switch" (in our case the GK). I think having multiple types of aliases (e164, h323-ID, url-ID, transportID, email-ID, partyNumber(publicNumber, privateNumber,nationalStandardPartyNumber) ) is confusing enough. Placing multiple aliases in an ARQ would further complicate matters. If I am not mistaken, the original reason for defining destinationInfo in ARQ as a sequence of aliases is to convey two (or more) phonenumbers to use for a single call. For example, to make an H.323 to an H.320 call via an ISDN GW using 2B lines, there can be two aliases: "918005551212" and "918005551213". Therefore, all aliases in the field are used for the same call; it is not a list of alternative aliases in prefered order. As a side note, some H.323 systems (e.g. an MCU, a GK-routed GK) look into the destinationAddress field in the SETUP message to see where to further route the call. Presumably, if there is a list of aliases in the ARQ, there would also be a list of aliases in the SETUP. How should these systems interpret the list of aliases? Currently, GW's interpret the multiple aliases as the phone numbers to dial out to the ISDN network (to be more precise, the first number is usually in the CalledPartyNumber and the second in the destExtraCallInfo, but that's a different story). It would be interesting to hear opinions from other implementors. Regards, Santo wiryaman VideoServer Inc. > -----Original Message----- > From: Paul Long [SMTP:Plong@SMITHMICRO.COM] > Sent: Thursday, January 21, 1999 2:39 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Multiple aliases in ARQ destinationInfo > > Hello, > > At the last interop I noticed that when an endpoint is placing a call, > gatekeepers treated the presence of multiple aliases in the ARQ > destinationInfo field in the following, different ways. > > 1. Always use the first, ignore the rest. > 2. Respond with ARJ if more than one alias. > 3. Respond with ACF only if all aliases are registered to the same > endpoint. > 4. Respond with ACF if at least one alias is registered, starting > with > the first one. > > While the Recommendations are silent on the semantics of multiple aliases, > and > vendors are therefore free to do whatever they want in this regard, I > believe > that the 4th interpretation is what was intended and should be encouraged. > A > "should" clause might be added to a future version of H.225.0. The reason > that > the first two don't make sense is that destinationInfo is after all a > _list_ > of aliases. That implies there is _some_ meaning to multiple aliases-if > only > one alias was intended, the ASN.1 component would have been defined as a > single alias. The 3rd interpretation is questionable because > destinationInfo > is a sequence-of and not a set-of aliases. Consider 3.8.46/X.680: > > "...each value in the sequence-of type is an _ordered_ list of zero, one > or > more values of the component type. [emphasis mine]" > > I take this to mean that not all aliases in destinationInfo are to be > treated > equal, and it is obvious to me that the order indicates search order. To > reinforce the choice of the 4th interpretation, consider 7.11.1/H.225.0v2: > > "destinationInfo - sequence of alias addresses for the destination, such > as > E.164 addresses or H323_IDs. When sending the ARQ to answer a call, > destinationInfo indicates the destination of the call (the answering > endpoint). ... > "srcInfo - sequence of alias addresses for the source endpoint, such as > E.164 > addresses or H323_IDs. When sending the ARQ to answer a call, srcInfo > indicates the originator of the call." > > This means that srcInfo and destinationInfo are swapped when answering a > call, > relative to placing a call, and that they are therefore probably > constructed > similarly. Since srcInfo often has multiple aliases with which the caller > wishes to be associated (one at a time, not as a single aggregate alias as > in > #3, above), it makes sense that destinationInfo also contains multiple > aliases > with which the callee may be associated. > > In practice, let's say I want to call someone who has a couple of E.164 > aliases, an email alias, and an H.323-id alias, not all of which may be > registered at any one time. My phonebook has all four aliases listed for > this > person, possibly in some meaningful order. As a user, the only thing I'm > interested in when I place the call, is that I want the gatekeeper to find > the > person. It makes sense to me for the gatekeeper to search the aliases in > order > until it finds one that is registered and then return a call-signaling > transport address to which I can connect to establish the call. > > I believe that the 4th interpretation is preferred but also that a > gatekeeper > may allow the administrator to configure this aspect in any number of > ways, > including the other three presented above. > > Paul Long > Smith Micro Software, Inc.

2 1

Re: Relationship of H.323 and H.245 versions
by Paul Long 21 Jan '99

21 Jan '99

From: Jim Toga [SMTP:jim.toga@INTEL.COM] This is getting close. One potential problem surrounds intermediaries (for example GKs in a GK-routed call). We need to indicate what exactly is the expected behaviour of 'M' entities when they get 'N' type messages (that look like 'M' messages with extentions.) I would contend that the reality of the situation is that all we can stipulate, is that the 'M' entities don't crash in the presense of 'N' messages. We can't mandate that 'M's pass new (uninterpreted/not-understood) data on. Obviously if there is an existing opaque field defined, this _shall_ be forwarded. comments? I thought I addressed this in the last sentence, "In addition, if a >product is relaying an ASN.1 value, it shall encode the same value that it >decoded, regardless of its own version or the version of the value's sender." This is for intermediate entities such as gatekeepers that relay, or route, call signaling and control messages between entities. My company is not in the gatekeeper business, so with my lack of familiarity I could be off base here, but I believe this statement is necessary to mitigate the earlier statement, "Each product shall _encode_ and decode the H.245 and H.225.0 ASN.1 syntax trees defined in their respective version of H.323." The last sentence sanctions, for example, a v1 gatekeeper relaying v2 messages. I assume this is a requirement and that we can indeed mandate it. Was I not clear, or did I simply not address your concern? Paul Long Smith Micro Software, Inc.

1 0

Multiple aliases in ARQ destinationInfo
by Paul Long 21 Jan '99

21 Jan '99

Hello, At the last interop I noticed that when an endpoint is placing a call, gatekeepers treated the presence of multiple aliases in the ARQ destinationInfo field in the following, different ways. 1. Always use the first, ignore the rest. 2. Respond with ARJ if more than one alias. 3. Respond with ACF only if all aliases are registered to the same endpoint. 4. Respond with ACF if at least one alias is registered, starting with the first one. While the Recommendations are silent on the semantics of multiple aliases, and vendors are therefore free to do whatever they want in this regard, I believe that the 4th interpretation is what was intended and should be encouraged. A "should" clause might be added to a future version of H.225.0. The reason that the first two don't make sense is that destinationInfo is after all a _list_ of aliases. That implies there is _some_ meaning to multiple aliases-if only one alias was intended, the ASN.1 component would have been defined as a single alias. The 3rd interpretation is questionable because destinationInfo is a sequence-of and not a set-of aliases. Consider 3.8.46/X.680: "...each value in the sequence-of type is an _ordered_ list of zero, one or more values of the component type. [emphasis mine]" I take this to mean that not all aliases in destinationInfo are to be treated equal, and it is obvious to me that the order indicates search order. To reinforce the choice of the 4th interpretation, consider 7.11.1/H.225.0v2: "destinationInfo - sequence of alias addresses for the destination, such as E.164 addresses or H323_IDs. When sending the ARQ to answer a call, destinationInfo indicates the destination of the call (the answering endpoint). ... "srcInfo - sequence of alias addresses for the source endpoint, such as E.164 addresses or H323_IDs. When sending the ARQ to answer a call, srcInfo indicates the originator of the call." This means that srcInfo and destinationInfo are swapped when answering a call, relative to placing a call, and that they are therefore probably constructed similarly. Since srcInfo often has multiple aliases with which the caller wishes to be associated (one at a time, not as a single aggregate alias as in #3, above), it makes sense that destinationInfo also contains multiple aliases with which the callee may be associated. In practice, let's say I want to call someone who has a couple of E.164 aliases, an email alias, and an H.323-id alias, not all of which may be registered at any one time. My phonebook has all four aliases listed for this person, possibly in some meaningful order. As a user, the only thing I'm interested in when I place the call, is that I want the gatekeeper to find the person. It makes sense to me for the gatekeeper to search the aliases in order until it finds one that is registered and then return a call-signaling transport address to which I can connect to establish the call. I believe that the 4th interpretation is preferred but also that a gatekeeper may allow the administrator to configure this aspect in any number of ways, including the other three presented above. Paul Long Smith Micro Software, Inc.

2 1

Re: Relationship of H.323 and H.245 versions
by Paul Long 21 Jan '99

21 Jan '99

Dave, Pete, et al., We need to be very clear about how products of different versions can be interoperable. Terms such as "compatible," "backward compatible," and "supports" are too ambiguous to be useful in normative text. Here's my attempt at splitting hairs. The first paragraph is taken straight from Dave's email. Products claiming compliance with Version 2 of H.323 shall comply with all of the mandatory requirements of this document, H.323 (1998), which references H.225.0 (1998) and H.245 (1998). The protocol identifiers used in messages defined in H.225.0 (1998) and H.245 (1998) are specified in those recommendations. Interoperability between products of possibly different versions is assured by the following. Note that what is commonly referred to as a "message" is an ASN.1 component of a choice type of typically the first or second level of an ASN.1 syntax tree. Therefore, in the following paragraph, a "message" that is not a component of the extension root is treated the same as any other choice extension addition. Assume that an H.323vM product and an H.323vN product are in communication with each other, where M and N are version numbers and M <= N. The H.323 version number shall be taken to be the same as the version number indicated in the H.225.0 protocolIdentifier field. Each product shall encode and decode the H.245 and H.225.0 ASN.1 syntax trees defined in their respective version of H.323. The H.323vM product shall behave according to H.323vM and shall assume that the H.323vN product also behaves according to H.323vM, with these two exceptions: * the H.323vN product encodes values for the protocolIdentifier fields for H.323vN, not H.323vM, and * the H.323vN product encodes ASN.1 sequence and choice extension additions defined in H.323vN that may not be defined in H.323vM. Although the H.323vM product shall parse extension additions defined in later versions of H.323 (as prescribed by ASN.1), it shall not recognize or otherwise act upon them. Therefore, the H.323vN product shall not rely on behavior in the H.323vM product that is based on the value or presence of extension additions defined in H.323vN but not H.323vM. This in effect forces the H.323vN product to behave like an H.323vM product. In addition, if a product is relaying an ASN.1 value, it shall encode the same value that it decoded, regardless of its own version or the version of the value's sender. Paul Long Smith Micro Software, Inc.

2 1