- sg16-avd - lists.packetizer.com

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 *******************************************************************… [View More]

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 *******************************************************************… [View More]

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: … [View More]

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 … [View More]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 ================================ [View Less]

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 … [View More]

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-… [View More]

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 … [View More]

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. … [View More]

1 0