September 1997 - sg16-avd - lists.packetizer.com

Re: H.450.x ASN.1 Modules
by Corey Gates 22 Sep '97

22 Sep '97

Karl, > There is one remaining error on line 142 in a module copied from original > X.880. For some reason the ASN.1 compiler complains that the "opcode" is > not defined, even though the same construct does not have an error on line > 109. > In order to get the H.450 ASN.1 code to compile we commented this reference > temporarily. > In order to test the code take the comment on line 142 out. > If somebody has an idea what causes this problem please report to me as > soon as possible. Did you apply to corrigendum to X.880 first? The syntax you attached did not contain the X.880 syntax you used, so I couldn't tell. One of the changes is the following: < ({Operations} {@opcode} --- > ({Operations} {@.opcode} which should fix your problem. The corrigendum is available at http://www.itu.ch/itudoc/itu-t/rec/x/x500up/x880c1_31931.html (it's free to download). If you could run the syntax by Bancroft Scott, the ASN.1 editor, he can double check any issues that you have with the syntax. He can be contacted at baos(a)oss.com. Corey Gates corey(a)fvc.com Tel: +1.408.567.7214 Fax: +1.408.988.7077

1 0

Re: New draft of H.245
by Corey Gates 22 Sep '97

22 Sep '97

Dear Colleagues, Below are some comments on the latest draft H.245, ordered by page number, not importance: - (Page 8) Should we add some clarification about extension to the description of the Capability Exchange? Here is some text that could be added to the end of the first paragraph: "When a capability is received which contains extensions not understood by the terminal, the capability shall be accepted as if it did not contain the extensions." What do people think? - (Page 29) Since we are importing elements from H.235 that are required to compile the syntax, should we not put the IMPORTS statement at the beginning of the syntax? Or at least at the beginning of the Encryption section? This is not a big issue, but it is kind of buried in the syntax and an implementor needs to know that the imported types are required to build a correct implementation. - (Page 39 and 92) Should there be "cause" codes in the OpenLogicalChannelReject message for bad "encryptionSync", "transportCapability" and "redundancyEncoding"? It seems that there should be more information about why the channel is being rejected. - (Page 88, 3rd paragraph, 3rd sentence) "logical channel" should be capitalized to "Logical channel" because it starts the sentence. - (Page 91) In the text concerning "FlowControlToZero", it indicates that the transmitter should not transmit on a logical channel until receiving a subsequent "FlowControlToZero" message. However, this message is only contained in the OpenLogicalChannelAck. Shouldn't this be a subsequent "FlowControl" command? - (Pages 96 and 43) In the text concerning ModeElement, it refers to an element called "EncryptedMode"; however, in the ASN.1 syntax there is only an element called "h235Mode". I think the text needs to be changed to say "h235Mode". - (Page 113) RequestForFloor is described twice, the first one should be removed. - (Page 237) In Appendix IV, regarding the extension procedure, should we add some text clarifying the capability issue? Here is some proposed text that could be added to the fourth paragraph: "Specifically, when an H.245 Capability is extended, the extension shall not change the meaning of the original capability in such a way that a terminal which does not understand the extension would need to modify its operation to use the capability without the extension." What to people think? Corey Gates corey(a)fvc.com Tel: +1.408.567.7214 Fax: +1.408.988.7077

2 1

Re: reRouteIndication
by Pete Cordell 22 Sep '97

22 Sep '97

Joerg, Scott, To clarify, dummy is a Hertzliya addition and nothing to do with reRouteIndication. It's needed because if you send a supplementary service message in a FACILITY you may not want to invoke the Facility-UUIE. The optimum case would be to make the UUIE h323-body-message part OPTIONAL, but this is not possible at this stage. Hence adding the dummy field. As to the name.... dummy, empty, emptyChoice, noChoice, blankChoice, void,... would be OK with me (I'm sure we have bigger sins than this!). As for text to describe the field, maybe... empty - This option is used when a FACILITY message is sent, but the Facility-UUIE is not to be invoked. This may occur when transporting supplementary service messages. reRouteIndication is a different issue. As re-routing can take place independent of supp services, it seems reasonable that an endpoint should be able to get notification of this event independent of supp services. Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Joerg Ott[SMTP:jo@TZI.ORG] >Sent: 20 September 1997 08:54 >To: ITU-SG16(a)mailbag.jf.intel.com >Subject: Re: reRouteIndication > >Pete and all, > >two comments on this mail: >> >> It has been mentioned that when a gatekeeper performs a re-route it >> would be good for the client to know about it. After much >> investigation, there seems to be no message in Q.931 that handles this >> case. In the text that I proposed in Sunriver I suggested that a >> Facility message with a H.450 ctComplete should be sent. However, this >> is not much use to an entity that does not support supplementary >> services. Therefore it might be useful to add can extra case to the >> H323-UU-PDU to cover this, e.g.: >> >> H323-UU-PDU ::= SEQUENCE >> { >> h323-message-body CHOICE >> { >> setup Setup-UUIE, >> callProceeding CallProceeding-UUIE, >> connect Connect-UUIE, >> alerting Alerting-UUIE, >> userInformation UI-UUIE, >> releaseComplete ReleaseComplete-UUIE, >> facility Facility-UUIE, >> ..., >> progress Progress-UUIE, >> dummy NULL, > >First: > >I must have missed the "dummy" parameter before. I assume the need for >an empty parameter comes from supplementary services, and I suggest to >call >it "empty NULL" (this is not an implementation but a standard after >all) >and to describe it somewhere in H.225.0. Searching through the >document, >the ASN.1 was the only place where "dummy" was used. >(Should I be saying something about puzzles right now? :-) >> reRouteIndication ReRouteIndication >> }, >> nonStandardData NonStandardParameter OPTIONAL, >> ..., >> h4501SupplementaryService SEQUENCE OF H4501SupplementaryService >OPTIONAL >> } >> >> ReRouteIndication ::= SEQUENCE >> { >> display IA5String (SIZE( 0..255) ), >> endpointInfo EndpointType, >> ... >> } >> >> This could then be sent by a gatekeeper when a re-route has been done. >> > >Second: > >Overall, I agree with the mail from Ernst Horvath on this issue: we >should >not add such functionality to H.225.0, not even to version two. > >Joerg >

3 2

H.323V2 draft
by gthom 22 Sep '97

22 Sep '97

All, H323v2i.doc has been uploaded to the gctech ftp site. It is complete except for the text on empty capability sets (TD-27) and Annex C on H.323 over ATM. Let me know if any of your changes have been missed, or have not been incorporated properly. Gary ------------------------------------- Name: Gary Thom Company: Delta Information Systems, Inc. Phone: +1-215-657-5270 x23 Fax : +1-215-657-5273 E-mail: gthom(a)delta-info.com Date: 09/22/97 Time: 08:57:14 -------------------------------------

1 0

Re: TD-27 text for h.323
by Pete Cordell 22 Sep '97

22 Sep '97

Gary, Generally I think your editorial intervention has been good. However, the state reset to when an non-empty capability set is received should be the state that H.245 is in after H.245 is originally established, NOT the state before the pause is invoked. This flushes out any H.245 state so that you have a known state to which to connect to a new endpoint. Some attempt at words is: On reception of a non-empty capability set in this paused state an endpoint shall reset its H.245 state to that which it is in just after the H.245 transport connection is made at call establishment time (i.e. the beginning of phase B). Hope this helps, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: gthom[SMTP:gthom@DELTA-INFO.COM] >Sent: 19 September 1997 19:47 >To: ITU-SG16(a)mailbag.jf.intel.com >Subject: TD-27 text for h.323 > >Pete and others, > >I took some editorial liberty with the text of TD-27. It is contained >below. I expect >to put this in 6.2.8.1 Capability Exchange. Alternatively, I could put >it into 8.2. >Any suggestions, changes, clarifications??? > >Thanks > Gary > >****************************************** > >"To allow gatekeepers to re-route connections from endpoints that do >not support >supplementary services, endpoints shall support the reception of empty >capability >sets (i.e. Terminal Capability sets that indicate that the endpoint >sending the >message has no receive capabilities). This feature also allows >'network' elements >such as PBXs, call centers, and IVR systems to re-route connections >independent >of supplementary services and facilitates pre-connect announcements. >It can also >be used to delay H.245 media establishment when features such as >Gatekeeper >based user location is being used. It is also highly recommended that >Version 1 >endpoints support this feature. > >On reception of an empty capability set an endpoint shall enter a >paused state. If >media stream or data logical channels were previously opened by the >endpoint, >they should be closed. In this state an endpoint shall accept the >opening of logical >channels from the remote end based on the usual rules and continue to >receive >media from open logical channels from the remote end. This allows >endpoints to >receive announcements (e.g. pre-connect call progress) where the >announcing >entity does not wish to receive media from the endpoint. > >On reception of a non-empty capability set in this paused state an >endpoint shall >reset its H.245 state to that which it was in prior to entering the >paused state. >This allows an endpoint to be connected to a different endpoint when it >is >released from the paused state. Note that the non-empty capability set >shall not >be sent to an endpoint until all its transmit and receive logical >channels have been >closed. A switching entity should also send an H.450 redirection >indication Facility >message if the endpoint is being re-routed. The endpoint shall then >proceed with >normal H.245 connection establishment signalling. When leaving the >paused state >an endpoint shall take part in master/slave determination signalling, >and may >proceed with normal open logical channel signalling procedures. When >an MC >receives a release from the paused state it shall act as if a new >endpoint has >entered the conference. > >Unless its capabilities have changed, an endpoint need not resend a >capability set >as the gatekeeper will have supplied this to remove any paused state in >the >remote endpoint. This option of not sending a capability set enables >faster >reconnection. > >------------------------------------- >Name: Gary Thom >Company: Delta Information Systems, Inc. >Phone: +1-215-657-5270 x23 >Fax : +1-215-657-5273 >E-mail: gthom(a)delta-info.com >Date: 09/19/97 >Time: 11:47:19 >------------------------------------- >

1 0

List of Sunriver meeting participants
by Sakae Okubo 21 Sep '97

21 Sep '97

Dear Q.12-14/16 Sunriver meeting participants, Attached please find the list of participants for the Q.12-14/16 Rapporteur meeting in Sunriver. This has been made according to the sheet left at the meeting site and my recollection. Please advise me if your name is missing or anything is wrong with your entry. It will be included in the meeting report APC-1327. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ******************************************************************** Country Company Name E-Mail Germany Siemens Robert robert.callaghan(a)siemenscom.co Callaghan m Germany Siemens Istvan istvan.sebestyen(a)mch.pn.siemen Sebestyen s.de Germany Siemens Karl karl.klaghofer(a)mch.pn.siemens. Klaghofer de Germany Siemens Wolfgang Wofgang.Klasen@mchp. Klasen siemens.de Germany Siemens Markku korpim(a)scn.de Korpi Germany Siemens Martin.Euch martin.euchner(a)mchp.siemens.de ner Germany Teles Joerg Ott jo(a)teles.de Canada Mitel Terry Tam tamt(a)software.mitel.com Canada Mitel Dave Walker dave_walker(a)mitel.com Canada Nortel Nancy ngreenet(a)nortel.ca Greene Canada Nortel Tom Taylor taylor(a)nortel.com Canada Nortel Vahe balabani(a)nortel.ca Balabanian Korea ETRI Dong-Bum dbjung(a)winky.etri.re.kr Jung Korea Korea Sang-Gil sgk(a)ktweb.kotel.co.kr Telecom Kim Korea Korea Jung-Ja Roh jjroh(a)rcunix.kotel.co.kr Telecom USA 8*8 Hardish hardish(a)8x8.com Singh USA Ascend Dale Skran Dale.Skran(a)ascend.com USA AT&T Baldine- baldine(a)reserach.att.com Brunel Paul USA Cisco Greg ggoodkni(a)cisco.com Systems Goodknight USA DataBeam Bill Quinn bquinn(a)databeam.com USA DataBeam Pat Galvin pgalvin(a)DataBeam.com USA Delta Inf. Gary Thom GTHOM(a)DELTA-INFO.COM Systems USA FVC Corey Gates corey(a)fvc.com USA Intel Narjala narjala-bhasker@ Bhaske ccm.jf.intel.com USA Intel Chris Chris_Hansen@ ccm.jf.intel.com Hansen USA Intel Vineet vineet_kuman(a)ccm.jf.intel.com Kumar USA Intel Jim Toga jtoga(a)ibeam.intel.com USA Intel John H. john_h_wilson(a)ccm.jf.intel.com Wilson USA Lucent Andy adfranklin(a)lucent.com Technologies Franklin USA Lucent Glen ggf(a)lucent.com Technologies Freundlich USA Lucent Li Yan lyan(a)lucent.com Technologies USA Lucent Zhongjin zjyang(a)lucent.com Technologies Yang USA Microsoft Toby Nixon tnixon(a)microsoft.com USA PictureTel Kaynam knedayat(a)pictel.com Hedayat USA PictureTel Mark Reid reid(a)pictel.com USA STARVISION Don Piercy dpiercy(a)starvision.com USA VideoServer George gkajos(a)videoserver.com Kajos USA VTEL Michael cpchen(a)vtel.com Chen Finland Nokia Frank Fu frank.fu(a)nmp.nokia,com France Alcatel Bahman Mobasser France France Isabelle haiqnere(a)cnet.francetelecom.fr Telecom/CNET Haiqnere France France Jean-Pierre jean.pierre.blin@ Telecom/CNET Bin cnet.francetelecom.fr France France Christian christian.wipliez@ Telecom/CNET Wipliez cnet.francetelecom.fr Israel Accord Roni Even roni_e(a)accord.co.il Israel RADVision Amotz Shemi amotz(a)radvision.rad.co.il Israel RADvision Orit Levin orit(a)radvision.ard.co.il Israel Vocaltec Scott petrack(a)vocaltec.com Petrack Israel Vocaltec Gur Kimchi gur(a)vocaltec.com Japan Fujitsu Yoshitsugu yn(a)marvel.ts.fujitsu.co.jp Nishizawa Japan GCL Sakae Okubo okubo(a)gctech.co.jp Japan KDD R&D Labs Shigeyuki sakazawa(a)lab.kdd.co.jp Sakazawa Japan KDD R&D Labs Hideaki hd-yamada(a)kdd.co.jp Yamsda Japan NEC Hidenobu harasaki(a)dsp.cl.nec.co.jp Corporation Harasaki Japan NTT Hiroshi koyano(a)nttvdt.hil.ntt.co.jp Koyano Netherl KPN Jeroen de j.h.demuijnck(a)research.kpn.com ands Muijnck Norway Telenor Helge Helge.Sandgrind(a)fou.telnor.no Sandgrind UK BT Labs John J.boucher(a)bt-web.bt.co.uk Boucher UK BT Labs Pete Pete.Cordell(a)bt-sys.bt.uk Cordell UK BT Labs Mike nilsson_m_e(a)BT-WEB.BT.CO.UK Nilsson Sweden Ericsson Anders anders.svennevik(a)ebc.ericsson. Svennevik se Switzer IBM H. Linh hlt(a)zurich.ibm.com land Truong

1 0

New draft of H.245
by Sakae Okubo 21 Sep '97

21 Sep '97

Dear SG16 colleagues, Mr. Nilsson's latest draft of H.245 (Version 3) h245_010.zip has been placed at the GCL ftp site. ftp://itu-t:sg15!avc@ftp.gctech.co.jp/Incoming/h245_010.zip Please note TDs of the Sunriver meeting have been moved to /9709_Sun directory. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ********************************************************************

1 0

Re: reRouteIndication
by Scott Petrack 21 Sep '97

21 Sep '97

*If* there are some new fields in the h323-message-body structure, like "dummy" (or "empty") and "Notify". then I would ask the following: 1. The Notify structure be called "Notify-UUIE" (like all the other elements). The definition of this UUIE is of course whatever is agreed upon. I guess that the "empty" structure can stay NULL. (Even this group wouldn't define an "empty-UUIE" with just three dots ;-).) 2. Both the Notify and the dummy/empty UUIE should be added to the UUIEsRequested structure of TD-28a. All of the then-present UUIEs were listed there; obviously these are part of the same story. I am not taking any stand on Pete's stuff. I just want to say if ...., then ..... (trying to harmonize things). Thanks, Scott pete.cordell(a)BT-SYS.BT.CO.UK on 09/19/97 08:17:12 PM Please respond to ITU-SG16(a)mailbag.jf.intel.com To: ITU-SG16(a)mailbag.jf.intel.com cc: (bcc: Scott Petrack) Subject: Re: reRouteIndication Ernst, Glen, I was working on a TD in Sunriver to suggest that Notify should be used, but I was advised that this was not the right message. It may be that Notify is the closest message to what is required and so I have no objections to it being used. Glen has also suggested that additional fields such as reRouteReason, endpointAlias, originalDestination, and reRouteCounter should be added. The first two I agree with. The second one I'm not sure of what it means so don't know whether I agree with it or not. On reRouteCounter, I'm not sure what it would be counting. For the Facility-UUIE based re-route this is used so that the endpoint can check for infinite loops. As this would be used as a notify that a re-route had already been done, then the usefulness of this information is limited. As to whether we include an indication of this sort, I am very wary of feature creep also. However, to me this seems such a fundamental call control feature that it shouldn't require supplementary service support. It should also be emphasized that this is not a replacement for anything in H.450.2, and ctComplete should be used when H.450.2 is in use. It is also light weight to implement; endpoints would not have to process it on reception, and re-routers should generate it, but it shouldn't be mandatory for them to generate it (for reasons such a anonymity in security and things like that). Given these suggestions, a revised PDU might be: H323-UU-PDU ::= SEQUENCE { h323-message-body CHOICE { setup Setup-UUIE, callProceeding CallProceeding-UUIE, connect Connect-UUIE, alerting Alerting-UUIE, userInformation UI-UUIE, releaseComplete ReleaseComplete-UUIE, facility Facility-UUIE, ..., progress Progress-UUIE, dummy NULL, notify CHOICE { reRouteIndication ReRouteIndication, ... } }, nonStandardData NonStandardParameter OPTIONAL, ..., h4501SupplementaryService SEQUENCE OF H4501SupplementaryService OPTIONAL } ReRouteIndication ::= SEQUENCE { -- display no longer needed as this is in Notify message reRouteReason CHOICE { h4502Proxy NULL, thirdPartyService NULL, secondaryDialling NULL, qSIGInterworking NULL, ... } endpointAlias SEQUENCE OF AliasAddress, endpointInfo EndpointType, ... } Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Ernst Horvath[SMTP:Ernst.Horvath@SIEMENS.AT] >Sent: 19 September 1997 10:40 >To: ITU-SG16(a)mailbag.jf.intel.com >Subject: Re: reRouteIndication > >Dear Pete, > >some observations on your mail: > >> It has been mentioned that when a gatekeeper performs a re-route it >> would be good for the client to know about it. After much >> investigation, there seems to be no message in Q.931 that handles this >> case. > >The Notify message could be used for that purpose (as an alternative to >Facility), but again, its use is supplementary-service specific (and >was >removed from H.450.1). In QSIG we use Facility whenever the information >is to be processed by the endpoint, which is nearly always the case. >Notify is restricted to situations where (less important) information >is >passed to the user without acting on it, and loss of the information >would not be of great concern for the overall working of a feature. > >> In the text that I proposed in Sunriver I suggested that a >> Facility message with a H.450 ctComplete should be sent. >> However, this is not much use to an entity that does >> not support supplementary services. > >The same situation can arise in the ISDN and QSIG case. But that does >not prevent the re-routing from taking place, it only means that this >terminal cannot display the information. > >> Therefore it might be useful to add can extra case to the >> H323-UU-PDU to cover this, e.g.: >> >> H323-UU-PDU ::= SEQUENCE >> { >> h323-message-body CHOICE >> { >> setup Setup-UUIE, >> callProceeding CallProceeding-UUIE, >> connect Connect-UUIE, >> alerting Alerting-UUIE, >> userInformation UI-UUIE, >> releaseComplete ReleaseComplete-UUIE, >> facility Facility-UUIE, >> ..., >> progress Progress-UUIE, >> dummy NULL, >> reRouteIndication ReRouteIndication >> }, >> nonStandardData NonStandardParameter OPTIONAL, >> ..., >> h4501SupplementaryService SEQUENCE OF H4501SupplementaryService >OPTIONAL >> } >> >> ReRouteIndication ::= SEQUENCE >> { >> display IA5String (SIZE( 0..255) ), >> endpointInfo EndpointType, >> ... >> } >> >> This could then be sent by a gatekeeper when a re-route has been done. >> > >Your proposal does not say which message you would use. If it is >Facility, then the Facility-UUIE could be enhanced instead. > >However, I have a more general concern with this new proposal: >An endpoint would still have to be upgraded to understand this coding. >The only advantage compared to your original proposal (i.e. using an >operation) might be slightly less complex coding. However, it goes >against the intention of H.450.x. The idea behind the approach in H.450 >is *not* to add new coding in H.225.0 whenever new functionality is >created, but to use the *generic* container 'H4501 Supplementary >Service >APDU' and confine all new functionality plus coding to the >supplementary >service recommendation. This allows a neat modular approach where you >tailor your system by choosing the right building blocks. >Therefore I prefer using operations wherever possible. > >Kind Regards, >Ernst >================================ >Ernst Horvath >Siemens AG >Tel: +43 1 1707 45897 >Fax: +43 1 1707 56992 >Email: ernst.horvath(a)siemens.at >================================ >

1 0

H.450.x ASN.1 Modules
by Markku Korpi 20 Sep '97

20 Sep '97

Pete,Glen,Dave & others For your convinience I have attached a file with the ASN.1 modules, that we used for verification of the H.450.x ASN.1 syntax. But Note: There is one remaining error on line 142 in a module copied from original X.880. For some reason the ASN.1 compiler complains that the "opcode" is not defined, even though the same construct does not have an error on line 109. In order to get the H.450 ASN.1 code to compile we commented this reference temporarily. In order to test the code take the comment on line 142 out. If somebody has an idea what causes this problem please report to me as soon as possible. Markku Korpi Editor of H.450.x Siemens Munich

1 0

ITU-T H.450.1, H.450.2 and H.450.3 Drafts for white papers
by Markku Korpi 20 Sep '97

20 Sep '97

Dear all, attached are the final drafts for issuing the white papers for the ITU-T recommendations H.450.1, H.450.2 and H.450.3. Please provide your final comments ASAP on tuesday at latest so that I can release the white papers on wednesday 24 Sept 97. Markku Korpi Editor of H.450.x SIEMENS Munich

1 0