- sg16-avd - lists.packetizer.com

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 20 Sep '97

20 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

Re: reRouteIndication
by Joerg Ott 20 Sep '97

20 Sep '97

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

1 0

Re: REH.225.0 protocol identifier
by Joerg Ott 20 Sep '97

20 Sep '97

Gary, I suspect that this is the *only* save way to do so. Also with respect to version numbers: do not forget to update the "References" section in all documents to point to H.245 version 3 (indicating 1998)... Joerg ---------------------------------------------------------------------- Joerg Ott jo(a)tzi.org Universitaet Bremen, Germany voice +49 421 218-2085 TELES AG fax +49 421 218-7000 > > Glen, > > Will you be changing the protocolIdentifier value for version 2 to: > {itu-t (0) recommendation (0) h (8) 2250 version (0) 2} > > And is this the prefered method to detect the difference between a version > 1 and a version 2 terminal??? >

1 0

FW: Octet-aligned encoding for H.450.x ?
by Klaghofer, Karl PN M BT 19 Sep '97

19 Sep '97

Sorry, In the meantime I found the H.225 section telling about basic aligned variant of X.691 to be used for H.225.0 User-user information element ASN.1 encoding. The same of course shall apply for H.450 Supplementary service APDUs (which are carried in User-user information element) Regards, Karl Klaghofer Siemens AG ---------- From: Klaghofer, Karl PN M BT Sent: Thursday, September 18, 1997 6:15 PM To: 'itu-sg16List' Subject: Octet-aligned encoding for H.450.x ? Importance: High The H.450 Supplementary Services make use of the Packed Encoding Rules (PER) according to X.691 (inline with H.225, H.245). X.691 specifies four encoding rules: BASIC-PER, CANONICAL-PER, both in two variants the ALIGNED variant, and the UNALIGNED variant. Are all of these encodings mandatory in H.323 (H.225, H.245) to support ? Should we limit the X.691 variants in H.450.x (clause 9 of H.450.1) to ALIGNED only ? Regards, Karl Klaghofer Siemens AG karl.klaghofer(a)mch.pn.siemens.de

1 0

review copy of H.225.0 version 2 available
by Glen Freundlich 19 Sep '97

19 Sep '97

Fellow H.323ers, I have posted 2 H.225.0 V2 files to the incoming directory of the gctech ftp site for early review. h2250v2b.doc indicates the changes from the Sunriver meeting. h225bdif.doc shows the changes between H.225.0 version 1 and h2250v2b. Note that these documents are not in their desired final state, but I think they are close. I have posted these now to allow review to be sure that I have included material from Sunriver. Please let me know if you see any omissions or errors, or if you have any suggestions. I have a few issues to resolve yet, and I have received a few comments which I have not had a chance to incorporate. Please get your comments to me by the end of the day Wednesday, September 24, so that I can forward the final documents to the Rapporteur by September 25. Best Regards, Glen Freundlich (editor H.225.0) -- 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

TD-27 text for h.323
by gthom 19 Sep '97

19 Sep '97

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

Re: reRouteIndication
by Pete Cordell 19 Sep '97

19 Sep '97

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

New draft of H.245
by Mike Nilsson 19 Sep '97

19 Sep '97

Dear Colleagues, I have put the latest draft of H.245 (Version 3) at ftp://www.labs.bt.com/pub/H245/h245_010.zip I will be out of the office until 29 September, and will have to submit this to the ITU very soon after my return. Therefore please review this draft as soon as possible, and as thoroughly as possible, so that we can minimise the number of corrections that we may need to make in January. Best regards Mike Nilsson ********************************************************************** * Mike Nilsson Tel: +44 1473 645413 * * Video Processing Unit Fax: +44 1473 643791 * * Centre for Human Communications E-mail: nilssome(a)boat.bt.com * * BT Laboratories [MLB3/16] * * Martlesham Heath * * Ipswich IP5 7RE * * UK * **********************************************************************

1 0

New draft of H.245
by Mike Nilsson 19 Sep '97

19 Sep '97

Dear Colleagues, I have put the latest draft of H.245 (Version 3) at ftp://www.labs.bt.com/pub/H245/h245_010.zip I will be out of the office until 29 September, and will have to submit this to the ITU very soon after my return. Therefore please review this draft as soon as possible, and as thoroughly as possible, so that we can minimise the number of corrections that we may need to make in January. Best regards Mike Nilsson ********************************************************************** * Mike Nilsson Tel: +44 1473 645413 * * Video Processing Unit Fax: +44 1473 643791 * * Centre for Human Communications E-mail: nilssome(a)boat.bt.com * * BT Laboratories [MLB3/16] * * Martlesham Heath * * Ipswich IP5 7RE * * UK * **********************************************************************

1 0

H.332 white paper for review in the Incoming directory
by Vineet Kumar 19 Sep '97

19 Sep '97

Dear H.323 Colleagues, I have uploaded the H.332 white paper (h332.doc in word 6) to the Incoming directory of the gctech.co.jp ftp site. Please review and email your comments by September 24. I will forward this document to the tsb in Geneva by September 25. Thanks. vineet -------------------------------------------------------------------- Vineet Kumar email: vineet_kumar(a)ccm.jf.intel.com Intel Corporation, JF3-212 phone: +1 503 264-3439 2111 NE 25th Avenue fax: +1 503 264-3375 Hillsboro, OR 97124-5961 -------------------------------------------------------------------- Opinions expressed are not necessarily shared by Intel --------------------------------------------------------------------

1 0

Re: reRouteIndication
by Ernst Horvath 19 Sep '97

19 Sep '97

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

TD-13a, TD-28a, TD-29a
by Scott Petrack 19 Sep '97

19 Sep '97

Okubo-san, You may remember that there were last minute changes to VocalTec's three TD's that were made to facilitate consensus. I have uploaded the final versions of these three TDs to the Incoming directory of the gctech.co.jp ftp site, in case they are of interest. Each final version has the letter "a" appended to the number: TD-13a.doc TD-28a.doc TD-29a.doc Yours sincerely, Scott

1 0

Q9 documents from Sunriver meeting
by Gunnar Hellstrom 19 Sep '97

19 Sep '97

The documents from Q9-Accessability from the Sunriver Meeting are available from http://www.pi.se/~omnitor/standd.htm Among them the determined draft recommendations for text chatting in multimedia. Gunnar Hellström ------------------------------------------------ Gunnar Hellström Omnitor Alsnögatan 7, 4tr S-116 41 Stockholm SWEDEN Tel +46 701 100 501 Fax +46 8 556 002 06 E-mail: gunnar.hellstrom(a)omnitor.se WWW: public-www.pi.se/~omnitor ------------------------------------------------

1 0

reRouteIndication
by Pete Cordell 18 Sep '97

18 Sep '97

Dear All, 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, 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. Any comments? Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 =================================

1 0

TD19 and TD20
by Sakae Okubo 18 Sep '97

18 Sep '97

Dear Mr. Kajos, >>I tried to upload the above TDs last night. It doesn't seem to have >>worked. They are enclosed in this mail, instead. I have uploaded your TD-19 and TD-20 to the Incoming 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

Call for Joint Researches
by Doohyun Kim 18 Sep '97

18 Sep '97

Dear Sir/Madam, We are very pleased to contact you in terms of cooperation in the teleconferencing area you are very actively involved in in terms of creation of international standards. Electronics and Telecommunications Research Institute(ETRI) in Korea has been on the development of not only T.120 but also H.323 during recent three years. This project is planned to finish at the end of this year and the technology transfer to industries will be started two months before the end of the project. Now we find that we need more study and development on T.130 which is now being documented by the international standard body. Korean government lately announced the plan for supporting of international research with the fund of at most 1 million US$ per year for the domestic organization participated in the project. The project may continue three years. In this background we are looking for partnership who would like to join this new project and share the idea and technologies. However, each organization should search for their own fund, but the technologies developed are going to be shared between participants. Our activities may include the development of the standard specifications, the design and development of the software, and the interoperability test. We hope you to join this T.130 development project and share idea and technologies. We appreciate you in advance. Sincerely Yours, Sanghwan Kung Head of Distributed Multimedia Research Section Multimedia Department Computer Research Division ETRI Tel : +82-42-860-6634 Fax : +82-42-860-6671 Email : shkung(a)hama.etri.re.kr

1 0

Draft meeting report and TDs
by Sakae Okubo 17 Sep '97

17 Sep '97

Dear SG16 colleagues, The following files have been uploaded to the Incoming directory: APC-1327 draft meeting report (please return comments, corrections, additions in a week time) TD-01 TD-02 TD-03 TD-04 TD-06 TD-08 TD-17 TD-18 TD-22 TD-24 TD-25 TD-30 TD-31 TD-32 TD-33 TD-34 TD-39 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 ******************************************************************** 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: TDs from Sunriver
by gthom 17 Sep '97

17 Sep '97

Simao, >Gary, > >are you sure you want TD20? - that was for Q.11 (Annex E to H.324). I >have it, so if that the one you need, please let me know. > >Simao > I am sorry, I was refering to the Q11, 12, 13 Rapporteur meeting TDs. 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/17/97 Time: 15:29:22 -------------------------------------

1 0

Re: Call ID
by gthom 17 Sep '97

17 Sep '97

Mark, > >Hi, > >In the strict sense ... doesn't this change imply that a version 1 endpoint >"shall" do this in a call between two version 1 endpoints? I realize that >is not the intent .... but without the version numbers as in the first >paragraph it is not clear. > > Mark > > >APC-1315 indicates the following change: >"When a version 1 endpoint calls a version 2 endpoint, it is the >responsibility >of the version 2 endpoint to generate a callIdentifier prior to sending ARQ >to >its gatekeeper." >Can this be generalized to: >"An endpoint receiving a Setup message which does not contain a >callIdentifier shall generate one and use it when sending RAS or Q.931 >messages related to this call." >Comments, clarifications??? >Thanks >Gary > I was trying to avoid using version numbers, because they are not used anywhere else in the document. Since this text is only in the Version 2 document, it should not be a requirement for Version 1 endpoints ??? 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/17/97 Time: 08:29:27 -------------------------------------

2 1

REH.225.0 protocol identifier
by gthom 17 Sep '97

17 Sep '97

Glen, Will you be changing the protocolIdentifier value for version 2 to: {itu-t (0) recommendation (0) h (8) 2250 version (0) 2} And is this the prefered method to detect the difference between a version 1 and a version 2 terminal??? 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/17/97 Time: 11:12:20 -------------------------------------

1 0

RSVP and CloseLogicalChannel
by gthom 17 Sep '97

17 Sep '97

In the H.323 appendix on RSVP it states: "Before sending out a CloseLogicalChannel message for a given traffic stream, an endpoint should send a PathTear message if it is a sender or ResvTear message if it is a receiver, if an RSVP session has been previously created for that stream. When an endpoint , whether sender or receiver, receives a CloseLogicalChannel for a given traffic stream, it should also send a PathTear if it is a sender or ResvTear message if it is a receiver, if an RSVP session has been previously created for that stream." Isn't it true that only the sender can issue a CloseLogicalChannel ??? If that true, should the text read: "Before sending out a CloseLogicalChannel message for a given traffic stream, a sending endpoint should send a PathTear message if an RSVP session has been previously created for that stream. When a receiving endpoint , receives a CloseLogicalChannel for a given traffic stream, it should send a ResvTear message if an RSVP session has been previously created for that stream." 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/17/97 Time: 09:42:18 -------------------------------------

1 0

Brief report from ITU-T Q9/16 - Accessability, Sunriver meeting.
by Gunnar Hellstrom 16 Sep '97

16 Sep '97

This is a brief report from the events in Sunriver seen from the Accessability view. A full report and the documents will show up in http://www.pi.se/~omnitor/index.html ITU - Telecommunication Standardization Sector Temporary Document 28 r2-E JOINT WORKING PARTIES 1 & 2/16 Original: English _______________________________ Sunriver , 12 September 1997 Question: 9/16 SOURCE: Gunnar Hellstrom, Swedish Administration, Rapporteur Q9/16 TITLE: Summary report from Q9/16 - Accessability to Multimedia for People with Disabilities The question has the following main items on its workplan: · Maintain the Text Telephone Automoding Recommendation V.18 · Develop recommendations for text conversation protocols in the Multimedia environment. · Provide information on Sign Language and Lip-reading use of Video communication for optimisation of videocoding for that application. A lot of work in the question is done in close collaboration with other questions and we are grateful for the excellent support we have got. Achievements since March 1997. 1. V.18 text telephone automoding Recommendation The text telephone automoding Recommendation V.18 is lab tested in more than 3000 successful connections with 11 different types of text telephones including V.18 itself. The experience of the testing is reflected in a revision of V.18 now proposed for determination, including support for the only known missing terminals - the plain V.23 (Minitel and Prestel). Accepted! A V.18 test specification was introduced by BT. It is a working document that can be developed into a Recommendation. 2. V.CHAT universal text conversation presentation level protocol. A presentation protocol V.CHAT for text conversation is developed together with Q3/16 and Q11/16. It is intended to be used in connection with all Multimedia protoocols and with V.18 text telephony. It is based on characterwise transmission of Unicode characters. It is now proposed for determination. Accepted! 3. T.CHAT= text conversation application protocol entity in data conferencing environment. A simple protocol for text conversation in the T.120 environment is developed in collaboration with Q3/16. With that, text chatting can be implemented in a uniform way in all multimedia environments supporting T.120. T.CHAT is now proposed for determination. Accepted as T.134! 4. H.CHAT= text conversation in H.324 terminals For implementations of H.324 not catering for T.120 protocols, procedures for carrying the V.CHAT protocol in a logical H.245 channel has been established in H.245 and H.324 now proposed for determination. Accepted! They have been developed in collaboration with Q11. Similar work also started in Q13/16 and Q14/16 for H.323. 5. Videocoding for sign language and lip-reading In collaboration with Q15/16, an informative appendix to H.263 has been drafted. It covers characteristics and requirements from Sign language and lip-reading application of video telephony and gives advice on optimisation for this application. Work will continue. The goals of H.263L has accepted to have Sign language and lip-reading as one application area. Plan for the time up to next SG16 meeting. Any feedback on the Draft Recommendations for determination will be handled. Q9 will continue developing the sign language documents and test sequences. The group asks for permission to hold one rapporteurs meeting in Europe late 1997 provided contributions are received. Accepted. Alistair Farquharson of BT is appointed editor of V.18. ------------------------------------------------ Gunnar Hellström Omnitor Alsnögatan 7, 4tr S-116 41 Stockholm SWEDEN Tel +46 701 100 501 Fax +46 8 556 002 06 E-mail: gunnar.hellstrom(a)omnitor.se WWW: public-www.pi.se/~omnitor ------------------------------------------------

1 0