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

H.323 text conversation contributions
by Gunnar Hellstrom 27 Jan '99

27 Jan '99

Dear Mr. Okubo, I would like to register two contributions for the upcoming meeting. - H.323 Annex "Text", Text Conversation Capable SUD. (First proposal) - Text conversation in H.323. (Proposed structure ) Please assign two APC numbers. Both are proposals, I suggest that both are discussed under "point 3, discussion of new SUDs, even if the second is of a more general nature even valid for full Multimedia systems and gateway implementations. Best regards, Gunnar Hellström SWEDEN _____________________________________ Gunnar Hellström Omnitor Alsnögatan 7, 4 tr S-116 41 Stockholm SWEDEN Tel +46 751 100 501 Fax +46 8 556 002 06 Text: (V.21) +46 8 556 002 02 e-mail gunnar.hellstrom(a)omnitor.se www: http://www.pi.se/~omnitor Video +46 8 556 002 05 -------------------------------------

2 2

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

27 Jan '99

Santo, Well let's forward it to the implementers' list and see if that adds to the breadth of the discussion. I may be being naive in expecting a large intersection of subscribers... More comments of mine inline. Regards, Chris > -----Original Message----- > From: Santo Wiryaman [mailto:swiryaman@VIDEOSERVER.COM] > Sent: 26 January 1999 4:18 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Multiple aliases in ARQ destinationInfo > > > 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)? I'll agree with all of those. > 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. I would prefer to standardise what happens in 2, because of problems across multiple zones/sites/administrative domains. > 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? There's only one way of finding out! > 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. What I meant was that if a user's home AND work numbers are specified in an ARQ, a sufficiently clever, sufficiently configured gatekeeper may be able to work out that they refer to the same people and work out what best to do with the request (if, for instance, it knows that currently the only way to get hold of this person is via their mobile phone, this is what it will return in an ACF). If on the other hand two numbers in an ARQ specify different people (Fred and Joe's separate work phone numbers) I would consider the most sensible behaviour to be to reject the request with a useful (TBD) error code. There are arguments against this: What do you do with an ARQ containing one number you've heard of and one you haven't? If you accept this (which seems sensible with regard to gateways for example), there is the problem of what happens when the number you used not to have heard of suddenly appears on the system? The answer is that now the user who used to get a sensible result when he tried to make a call from his address book doesn't any more. Is this acceptable? Maybe best would be to specify in the implementer's guide that only one alias is to be used in the ARQ? I don't like this though, because I'd like to be able to use gateways without complicated prefixes (maybe this is never going to be possible). Regards, Chris > > > 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

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 26 Jan '99

26 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