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

subscribe
by alexa 26 Aug '98

26 Aug '98

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

1 0

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

26 Aug '98

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

1 0

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

26 Aug '98

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

1 0

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

26 Aug '98

Dear Q.11-14/16 experts, Mr. Harasaki wrote: >I have put a delayed contribution to September SG16 meeting as >ftp://standard.pictel.com/avc-site/Incoming/Delayed_H323_ISDN.zip This document has been moved to ftp://standard.pictel.com/avc-site/9809_Gen/Delayed/Delayed_H323_ISDN.zip with the following two delayed contributions: ATT_nh_gkx2.zip from Mr. Roy H323_Annex_E.zip from Mr. Gurle (I hope my understanding is correct that this is a delayed contribution) Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

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

25 Aug '98

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

1 0

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

25 Aug '98

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

1 0

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

25 Aug '98

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

1 0

Re. Comments on AT&T proposal
by Vivian Liao 23 Aug '98

23 Aug '98

Hi, I just joined. I was wondering where I can get referrenced AT&T proposal. Please advise. Thanks a lot. BTW, what is back-end service? Vivian

2 1

Re: Comments on AT&T proposal
by HERSENT Olivier CNET/DSE/CAE 23 Aug '98

23 Aug '98

Some follow-on comments inserted below : > >simplest ways to do it was that the roaming terminal would send the ARQ, > >... > >to the visited network GK (discovered my broadcast/multicast). This GK > would > > If you are visiting another IP network, are you asking the GK for more > than > bandwidth and address resolution (absent BES-based AR). --- Yes, for instance if I dial an E164 number, or if I use a high level of QoS, I will be billed, probably based on the GK info. Maybe I also have a set of short numbers programmed in your home GK, and you would like to use them ... > >recognize from the calling party alias that the terminal si from an > external > >administation having an agreement with the visited administration. > >It would then forward the xRQs to the home gatekeeper of the terminal and > >get the xCFs in reply. > > This proposition requires the calling party alias to identify the "home" > administration, and the gatekeeper to be able to resolve the "home" > gatekeeper. --- Yes, this would be based on the domain name of an email alias. When completing a roaming agrement, each party would pass the other party a list of domains to include in the agreement. That could be *.francetelecom.fr, *.myprefferredcustomer.com, ... Then to identify the GK, the usual DNS TXT record lookup could be used, or the parties in agreement could also store some IP addresses. The home GK can find who is the visited domain GK from a token inserted in the relayed xRQs, or another comvention such as name mangling (source alias toto(a)francetelecom.com modified as toto(a)francetelecom.com!deutschetelecom.com ) This doesn't have to be standardized, it is just added value programming on top of the GK. > >This has many benefits : > >- The home GK knows where is the roaming teminal and can forward calls. > >- Any policy implemented at the home gatekeeper (restricted phone usage, > etc > >...) is still enforced in any visited domain > > So, bandwidth restrictions in the home zone would be enforced in a visited > zone?. --- Yes, and many more services. for instance you could be using a prepaid account that allows only to call some numbers (your company ...). This restriction would be enforced as well in the visited domain. Of course the visited domain can also enforce its own policy, because it relays the xCFs. For instance if the home GK allow to call a premium rate number, but the local policy does not allow this, then the visited GK would simply change the ACF into an ARJ. > >- It is simple > > I think we should be looking at Back-End Services, at least so we know > what > to expect of them, and don't make GK-GK break later, or make GK-BES > difficult/impossible. --- We are looking into this. So far the main restriction we see in existing toolkits for this type of GK/GK services is that they are sometimes unable to initiate RAS/Q931 messages (no API to send an xRQ). Hopefully this will be improved in future versions. We plan to bring this work to ITU/ETSI as soon as we have something that seems flexible enough to build most services. > >So roaming might be a good reason to forward xRQs ... just my FF.02. > > > > Best regards, > > > > Olivier HERSENT > > > >-- > >France Telecom CNET > >IP Telephony Technical Proj. Manager - TULIP > >

2 1

Availability of the latest version of Annex E
by David Gurle 22 Aug '98

22 Aug '98

From: David Gurle@VOCALTEC on 08/22/98 03:46 PM Dear All, You can find the latest version (3.3) of the H.323 version 3 annex E at the following directory: ftp://standards.pictel.com/avc-site/Incoming/H.323%20Annex%20E.zip Good reading and Best regards David. David Gurle Mobile: +972 53 870 464 ISDN: +972 99 525 802 Fax: +972 99 561 867 1 Maskit street Herzeliya, 46733 Israel mailto:david_gurle@vocaltec.com

1 0