June 1999 - sg16-avd - lists.packetizer.com

Decided and Determined texts
by Sakae OKUBO 04 Jun '99

04 Jun '99

Dear Editors, Please upload integrated texts for the subject Recommendations to the PictureTel ftp site Incoming directory at the earliest occasion. 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 ***********************************************************

3 2

Re: unsubscribe
by NieXiuYing 03 Jun '99

03 Jun '99

unsubscribe

2 1

Re: List Of Termination Prop... Text Telephone Support
by Gunnar Hellstrom 03 Jun '99

03 Jun '99

In order to give an example of why it is of importance for the MGC to know what type of modem connection that was activated, I provide a first draft of how text telephone support can be explained in H.gcp . In this case the modem will indicate V.18 usage, and that means that the media stream will be a T.140 text stream. In the T.38 case it will be some kind of fax data stream, while for the V.90 case, I hope that the idea would be to use it for a PPP session to access the Internet. So, these three modem types need quite different actions from the gateway and it need to be reflected in the MGC interface. Please look in the attached proposed new section to H.gcp for further discussion and explanation. Can anyone look into how to structure alternating between voice and text on the SCN side during a call and leading text to the text stream and voice to the audio stream on the IP side? ( called "voice over" in USA ) Can we support it? Regards Gunnar Hellström At 11:05 1999-06-03 -0700, you wrote: >At 12:19 PM 6/3/99 -0500, Nancy-M Greene wrote: >>> > >Modem type: none, V.90, T.38, V.18, ... as applicable. >>>> Why is this passed from MGC to MG? What does the MG do with it? Isn't >>>> this an MG capability? Maybe this is only useful for audit. >> >>>[[TomT]] This information is probably only useful for H.324 calls, although >>>maybe it also applies to NAS operation. The MGC knows which modem type to >>>assign based on dialled number, and passes the information to the MG to act >>>upon. >> >> >>Yes, this information is useful for NASes. In the SS7 case, the MGC knows >>which physical circuit the call will be completed on, and based on the >>dialled number, may have modem characteristics that need to be given to the >>NAS (MG) before that call is completed. > >As has been discussed quite a bit before, this is AAA info and NAS's >already have a protocol for that. We don't need to reinvent the wheel. > > ----------------------------------------------- Gunnar Hellstrom LM Ericsson E-mail gunnar.hellstrom(a)omnitor.se Tel +46 751 100 501 fax +46 8 556 002 06

1 0

H.GCP is about gateway recomposition, not decomposition..
by Boaz Michaely 03 Jun '99

03 Jun '99

Dear Brian, I am documenting a piece on the "minimal interoperability" issue, which I will forward to you next week. (if there is interest I can post it to the list) The basic idea is that while the motivation for H.GCP was gateway decomposition, the actual standard deals with composing rather than decomposing. Thus I propose to introduce some terms, such as "composite gateway", while adhering to H.323 current definitions, and work on the call setup procedures, closely following the actual H.323 text. This will lead to the resolution of transfering call signalling between the MGC and the MG in the various compositions. One thought that crossed my mind was to explicitly deal with all the gateway categories that H.323 defines ( H.310 (H.320 on B-ISDN), H.320 (ISDN), H.321 (ATM), H.322 (GQOS-LAN), H.324 (GSTN), H.324M (Mobile), and V.70 (DSVD)). We may also need to modify H.323v3, at least to some extent, in order to better cover gateway sub-components. A sample of the text is attached (Word 97) (Embedded image moved to file: pic10782.pcx) Boaz. Boaz Michaely Senior Program Manager, Advanced Technologies VocalTec Communications Ltd e-mail boaz(a)vocaltec.com Tel +972 (9) 970-7869

1 0

Re: [VideoPhone:2545] [wg5-3: 2996] H.GCP is about gateway recomp osition, not decomposition..
by Liang, William 03 Jun '99

03 Jun '99

please drop me from your distribution list. WL > -----Original Message----- > From: Boaz Michaely [SMTP:Boaz_Michaely@VOCALTEC.COM] > Sent: Friday, June 04, 1999 2:46 AM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: [VideoPhone:2545] [wg5-3: 2996] H.GCP is about gateway > recomposition, not decomposition.. > > Dear Brian, > I am documenting a piece on the "minimal interoperability" issue, which I > will forward to you next week. (if there is interest I can post it to the > list) > > The basic idea is that while the motivation for H.GCP was gateway > decomposition, the actual standard deals with composing rather than > decomposing. > > Thus I propose to introduce some terms, such as "composite gateway", while > adhering to H.323 current definitions, and work on the call setup > procedures, closely following the actual H.323 text. This will lead to the > resolution of transfering call signalling between the MGC and the MG in > the > various compositions. One thought that crossed my mind was to explicitly > deal with all the gateway categories that H.323 defines ( H.310 (H.320 on > B-ISDN), H.320 (ISDN), H.321 (ATM), H.322 (GQOS-LAN), H.324 (GSTN), H.324M > (Mobile), and V.70 (DSVD)). > > We may also need to modify H.323v3, at least to some extent, in order to > better cover gateway sub-components. > > A sample of the text is attached (Word 97) > > (Embedded image moved to file: pic10782.pcx) > > Boaz. > > Boaz Michaely > Senior Program Manager, Advanced Technologies > VocalTec Communications Ltd > e-mail boaz(a)vocaltec.com > Tel +972 (9) 970-7869 << File: pic10782.pcx >>

1 0

Interoperabilit with H.323 [Re: Priorities and Relevance]
by Boaz Michaely 03 Jun '99

03 Jun '99

Dear Tom and all, I fear that the most important aspect of our work is somewhat neglected : interoperability. Specifically, any working "decomposed" gateway today is obvisouly based on one of the ancestors of MGCP. On the other hand, the vast majority of VoIP traffic generating systems are pure H.323. Clearly, interoperability in this sense means that a MEGACO compliant MGC will also be a H.GCP compliant MGC. We must make sure that implementing MGC's this way is trivial, while concentrating on audio-only aspects, *as a guideline*, may make this target more difficult to achieve. On the other hand, adhering to the concepts agreed upon in Santiago should not slow down the megaco work, which in my mind is really at the detail level. In parallel, megaco expert participation is required in refining H.GCP, to ensure the very same target. (Tom, hope you had a nice vacation at your daughter's :-) Boaz. Boaz Michaely VocalTec Communications Ltd e-mail boaz(a)vocaltec.com Tom-PT Taylor <taylor(a)NORTELNETWORKS.COM> on 02/06/99 04:49:47 PM Please respond to Tom-PT Taylor <taylor(a)NORTELNETWORKS.COM> To: MEGACO(a)STANDARDS.NORTELNETWORKS.COM cc: (bcc: Boaz Michaely) Subject: Priorities and Relevance The feeling I get is that it won't hurt to focus our efforts for the next few weeks on creating a draft which provides a consistent, implementable audio-only version of the protocol, while preserving compatibility with multimedia contexts. Then we can spend July getting a joint H.GCP/Megaco draft ready for the SG 16 Berlin meeting. The items that need change to ensure compatibility with the ultimate H.GCP/Megaco solution are: - associating send/receive status with the medfia flows rather than the whole termination, to allow finer control - using MIME encapsulation when reporting capabilities in response to audits, as Christian has suggested. I'd like this to be present because I think MMUSIC may eventually come up with a better solution to reporting capabilities than SDP, yet one which maps easily to the latter or to H.245. I'm assuming that for circuit terminations the bearer name is used as the termination name (as it is now). The bearer list is only needed if you introduce the circuit multiplex termination class. That should be a routine extension of the basic protocol, without implications for MGs which don't support it.

1 0

ITU-T Q9/16 "Accessibility" report
by Gunnar Hellstrom 03 Jun '99

03 Jun '99

Attached you can find the report from ITU-T Q9/16 "Accessibility to MultiMedia for people with Disabilities" meeting in Santiago, May 17-28 1999. Highlights: In good co-operation with many other Questions, the following was achieved. ---------------------------------------------------------------------------- ----------------------------------------- -An IP Text Telephone and IP Text Conversation Annex to H.323 was determined. (H.323 Annex G) -A document about Sign Language and Lip Reading application of low bit rate video coding was approved for publication. -A Text Conversation addition to ISDN video telephony was determined as a new codepoint for T.140 in H.224. -The concepts Total Conversation and Text Telephony were introduced in a draft MultiMedia Conversation Service Specification. Total Conversation is the combination of Video, Text and Voice in a real time conversation. -A work item on Text Telephony and Text Conversation through MultiMedia Gateways was initiated. -Minor corrections to the text telephone modem Recommendation V.18 was introduced in an Implementers guide. -Idéas for next study period ( 2000-2004 ) were documented. ---------------------------------------------------------------------------- ----------------------------------------- Next important deadline is short after September 30, when white documents for decision in February should be entered. A Q11-14/16 Meeting in Berlin on August 2-6 is a good opportunity to prepare the Q11-Q14 related documents. Best regards Gunnar Hellström ------------------------------------- Gunnar Hellström Ericsson Home Systems Tel +46 751 100 501 Fax +46 8 556 002 06 e-mail gunnar.hellstrom(a)omnitor.se Video +46 8 556 002 05 -------------------------------------

1 0

H.245 V5 decided
by Sakae OKUBO 03 Jun '99

03 Jun '99

Dear Q.12-14/16 experts, MN> I have uploaded the approved version 5 of H.245 to the ftp site ... Mr. Nilsson's file has been moved to the following place: ftp://standard.pictel.com/avc-site/9905_San/h245_i.zip or http://standard.pictel.com/ftp/avc-site/9905_San/h245_i.zip 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

Mr. Tosco's WP2 report of the SG16 Santiago meeting
by Sakae OKUBO 03 Jun '99

03 Jun '99

Dear Q.12-14 colleagues, The following set of WP2 meeting reports has been placed at the PictureTel ftp site: ftp://standard.pictel.com/avc-site/9905_San/Tosco_WP2_report_9905.zip or http://standard.pictel.com/ftp/avc-site/9905_San/Tosco_WP2_report_9905.zip It will expand into the following 8 files: 1) Report_Part_I.doc - General 2) Decision.doc - Recommendations to Resolution 1 at the SG16 Plenary Meeting 3) Report_Part_IIA1.doc - Recommendations for Determination 4) Report_Part_IIB.doc - Texts for approval 5) LiaisonStat.doc - Liaison Statements from WP 2/16 6) Status_report_5.99.doc - Status of ongoing draft Recommendations 7) Meetings_Rep.doc - Planned Rapporteurs meetings 8) Annex_SG16.doc - Proposed Organisation going forward to new Study Period 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.245 Version 5
by mike.nilsson＠BT.COM 03 Jun '99

03 Jun '99

I have uploaded the approved version 5 of H.245 to the ftp site (ftp://standard.pictel.com/avc-site/Incoming/) as file H245_I.zip. Best regards Mike Nilsson *********************************************************************** * Mike Nilsson Tel: +44 1473 645413 * * Real Time Internet Group Fax: +44 1473 645011 * * Applications and Middleware Email: mike.nilsson(a)bt-sys.bt.co.uk * * BT Laboratories [B54 Room 94] * * Martlesham Heath * * Ipswich IP5 3RE * * UK * ***********************************************************************

1 0