- sg16-avd - lists.packetizer.com

terminalAlias or endpointAlias??
by Frank Derks 11 Feb '00

11 Feb '00

The RRQ and RCF messages may contain a field with the name "terminalAlias". The GRQ, URQ and IRR, contain an element with the name "endpointAlias". It would seem that these two differently named fields are actually referring to the same thing. Is there a distinction or is this just something that happened for no particular reason? Frank ----------------------------------------------------- Frank Derks |Tel +31 35 6893238 | Advanced Development |Fax +31 35 6891030 | Philips Business Communications|P.O. Box 32 | |1200 JD Hilversum | |The Netherlands | ----------------------------------------------------| E-mail: mailto:frank.derks@philips.com | WWW: http://www.sopho.philips.com | -----------------------------------------------------

1 0

Files in the PictureTel ftp site
by Sakae OKUBO 08 Feb '00

08 Feb '00

Dear Q12-14/16 experts, Please be advised that I have belatedly cleaned the /Incoming directory of the PictureTel ftp site. 1) All the mobility files have been moved to a new directory /avc-site/Mobility-adhoc. 2) All the documents for the current SG16 meeting in Geneva have been moved to /0002_Gen directory. 3) A list of documents in /0002_Gen directory is given by /0002_Gen/0002_Gen.html. Best regards, Sakae OKUBO *********************************************************** 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 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

Incorrect Source on COM16-D392
by Chip Sharp 05 Feb '00

05 Feb '00

Contribution COM16-D392 titled " Call linkage in H.323" currently lists Cisco Systems, Inc. as one of the sources. Cisco Systems, Inc. is not one of the sources of this contribution. This implies neither that we oppose the contribution nor that we support it. This can be discussed during the course of the meeting. I apologize for any confusion this may have caused. See ya' soon. Thanks, Chip Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. --------------------------------------------------

1 0

Unregistration procedure problem
by Henri M�enp�� 03 Feb '00

03 Feb '00

Hello, I'm having diffuculties understanding the correct behaviour of Unregistration procedure. H.225v3 states in URQ 7.10.1: "callSignalAddress - This is one or more of the transport call signalling addresses for this endpoint which are to be unregistered." Also, a registered endpoint must have always at least one callSignallingAddress. Right? Say, there's one callSignallingAddress and two endpointAliases registered for an endpoint. If this endpoint now wants to unregister one of the aliases, it has basically two options. 1) One would be to send URQ with only this one endpointAlias included (the one that is to be deleted). Because callSignallingAddress is mandatory in URQ message, the only callSignalAddress would become deleted also according to the standard quote above. This is an error, I think. 2) The other option would be to send a new RRQ that specifies only the endpointAlias that shall be kept "active". In this scenario the problem does not occur. Any comments? Henri Mäenpää, Nokia.

1 0

Draft H.450.9 Call Completion Supplementary Service
by Karl.Klaghofer＠ICN.SIEMENS.DE 02 Feb '00

02 Feb '00

I have uploaded the latest draft of the H.450.9 Call Completion Supplementary Service to the standard.pictel.com ftp site. ftp://standard.pictel.com/avc-site/Incoming/h450.9.zip Regards, Karl Klaghofer ------------------------------------------------ Karl Klaghofer, Siemens AG, Dpmt. ICN SIB NL D1 Hofmannstr. 51, D-81359 Munich, Germany Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 e-mail: karl.klaghofer(a)icn.siemens.de

1 0

[Robustness] Some Open Issues for Geneva meeting
by Maureen Stillman 31 Jan '00

31 Jan '00

Based on the robustness group teleconferences, RadVision has submitted a delayed contribution named: RV-Robustness.zip available at: http://standard.pictel.com/ftp/avc-site/Incoming/RV-Robustness.zip In addition to this submission, here is an incomplete list of open issues for robustness. Most of these have been discussed in teleconferences or on the mailing list. Please send any open issues to the mailing list and we can discuss them further in Geneva. Thank you. Open Issues 1) How does robustness interact with billing? There are concerns about keeping a call alive that can't be billed for properly. 2) Does an endpoint need to reregister with the gatekeeper after it crashes and comes back up? When does it perform this process? Suppose endpoint A and B are registered with the same gatekeeper. After B crashes and it comes back up should it initially try to recover a call that is in progress? Then, if no calls are in progress, should go ahead with gatekeeper discovery or perform gatekeeper discovery immediately? This scenario raises security issues.... 3) How does security interact with robustness? For example, does an endpoint need to re-authenticate when it (or a gatekeeper) crashes and comes back up? (answer should be "yes".) How? There are concerns that the robustness mechanism will introduce security holes. 4) What identifier (CALL ID???) will be used when H.225 and/or H.245 connections are reopened? RadVision's submission suggests we use the CALL ID. 5) How will the H.225 and H.245 connections be reopened? (This might belong in the implementers guide) 6) There has been considerable debate on whether or not we allow the H.225 connection to be closed during a call. Should we change the standard to say that it can't be closed? 7) The standard states that if the H.245 connection is closed then the call is terminated. How does this fit in with robustness procedures? Should we change this requirement in the standard? 8) (from the mailing list) If an endpoint fails to find a gatekeeper during gatekeeper discovery, it is permitted to assume that there is no gatekeeper around, and that it may therefore make calls without using a gatekeeper. It might be considered "polite", however, for an endpoint carrying on this way to periodically check up to see if there ARE any gatekeepers around. At least one well-known H.323 stack acts in this way if asked to handle RAS for its application. The question is what should it do if it should find a gatekeeper at this later stage? 9) Is support for robustness mechanisms in H.323v4 mandatory or optional? -- maureen Maureen Stillman Member of Scientific Staff Voice: (607)273-0724 x62 Nokia IP Telephony Fax: (607)275-3610 127 W. State Street Mobile: (607)227-2933 Ithaca, NY 14850 e-mail: maureen.stillman(a)nokia.com www.nokia.com

1 0

WP2 agenda and schedule
by Sakae OKUBO 31 Jan '00

31 Jan '00

Dear Q12-14/16 experts, I have placed the draft agenda and meeting schedule of WP2/16, which were received from Mr. Tosco, Chairman of WP2/16. ftp://standard.pictel.com/avc-site/Incoming/Draft_agenda_WP2_Feb_00.doc or http://standard.pictel.com/ftp/avc-site/Incoming/Draft_agenda_WP2_Feb_00.doc ftp://standard.pictel.com/avc-site/Incoming/Work_Plan_WP2_Feb_00.xls or http://standard.pictel.com/ftp/avc-site/Incoming/Work_Plan_WP2_Feb_00.xls Best regards, Sakae OKUBO *********************************************************** 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 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

Re: Delayed contributions
by Mike Nilsson 31 Jan '00

31 Jan '00

It has just been brought to my attention that this ftp site is not accessible outside of BT, and that files in this area are automatically copied to an external site overnight. So, I hope that these files will appear in the directory http://www.labs.bt.com/people/nilssome/APC tomorrow. Apologies for wasting your time and causing confusion. Mike ********************************************************************** * Mike Nilsson Tel: +44 1473 645413 * * Applications Technology Group Fax: +44 1473 645011 * * Internet and Multimedia Applications Email: mike.nilsson(a)bt.com * * BT Advanced Communications Technology Centre [B54 Room 94] * * Adastral Park * * Martlesham Heath * * Ipswich IP5 3RE * * UK * ********************************************************************** > -----Original Message----- > From: Mike Nilsson [SMTP:mike.nilsson@BT.COM] > Sent: Monday, January 31, 2000 10:00 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Delayed contributions > > I have been unable to upload our delayed contributions to the PictureTel > site. > > So instead I have put them on a BT server as detailed below. > > ISUP transport in H.225 using a Generic, Extensible Framework : > ftp://sss.info.bt.co.uk/people/nilssome/APC/extens%7E1.doc > > A Tutorial on the Extensible Package Framework : > ftp://sss.info.bt.co.uk/people/nilssome/APC/packag%7E1.doc > > Applying the Extensible Package Framework to Annexe G : > ftp://sss.info.bt.co.uk/people/nilssome/APC/packag%7E2.doc > > Object Profile for ISUP Transport in H.225 using the Generic Extensible > Framework : ftp://sss.info.bt.co.uk/people/nilssome/APC/revise%7E1.doc > > Security package for the Extensible Package Framework : > ftp://sss.info.bt.co.uk/people/nilssome/APC/securi%7E1.doc > > Best regards > > Mike > > > ********************************************************************** > * Mike Nilsson Tel: +44 1473 645413 * > * Applications Technology Group Fax: +44 1473 645011 * > * Internet and Multimedia Applications Email: mike.nilsson(a)bt.com * > * BT Advanced Communications Technology Centre [B54 Room 94] * > * Adastral Park * > * Martlesham Heath * > * Ipswich IP5 3RE * > * UK * > **********************************************************************

1 0

Delayed contributions
by Mike Nilsson 31 Jan '00

31 Jan '00

I have been unable to upload our delayed contributions to the PictureTel site. So instead I have put them on a BT server as detailed below. ISUP transport in H.225 using a Generic, Extensible Framework : ftp://sss.info.bt.co.uk/people/nilssome/APC/extens%7E1.doc A Tutorial on the Extensible Package Framework : ftp://sss.info.bt.co.uk/people/nilssome/APC/packag%7E1.doc Applying the Extensible Package Framework to Annexe G : ftp://sss.info.bt.co.uk/people/nilssome/APC/packag%7E2.doc Object Profile for ISUP Transport in H.225 using the Generic Extensible Framework : ftp://sss.info.bt.co.uk/people/nilssome/APC/revise%7E1.doc Security package for the Extensible Package Framework : ftp://sss.info.bt.co.uk/people/nilssome/APC/securi%7E1.doc Best regards Mike ********************************************************************** * Mike Nilsson Tel: +44 1473 645413 * * Applications Technology Group Fax: +44 1473 645011 * * Internet and Multimedia Applications Email: mike.nilsson(a)bt.com * * BT Advanced Communications Technology Centre [B54 Room 94] * * Adastral Park * * Martlesham Heath * * Ipswich IP5 3RE * * UK * **********************************************************************

1 0

FTP server unavailable?
by Euchner Martin 31 Jan '00

31 Jan '00

Dear Webmaster and administrator of the ftp://standard.pictel.com/avc-site/ <ftp://standard.pictel.com/avc-site/> a couple to people are having access problems to reach the FTP server of Q12-14 of Study Group 16 since several days now. Accessing the FTP server results in the following error message (see below). Would you please check you web/ftp server for any potential problems? Thank you! Martin Euchner. Error The URL could not be retrieved. The reasons possible are : The proxy can not login into ftp server. Please check you username and password and try again. When the proxy send the command: USER Server Reply: 530-The server standard.pictel.com is temporarily unavailable due to 530-the number of users currently connected. The limit is 50 anonymous 530-users at one time. Please try logging in again; if you believe 530-that there is an issue beyond number of users, please e-mail 530-webberr(a)pictel.com to report the problem. 530- 530 User anonymous access denied. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de | Intranet: http://zt-security.mchp.siemens.de/de/Competence/Standardization/SG16_.html | Otto-Hahn-Ring 6 Internet: http://www.siemens.de | D-81730 Muenchen | __________________ | Germany -----------------------------------------------------------------------

1 0