- sg16-avd - lists.packetizer.com

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

Re: H.323 Annex E and H.225.0 Annex G Upload
by Sakae OKUBO 02 Jun '99

02 Jun '99

Dear Mr. Moscovici, LM> I have uploaded the decided texts of H.323 Annex E and H.225.0 Annex G to LM> the PictureTel site. LM> The files are named accordingly. They have been moved to the following place: ftp://standard.pictel.com/avc-site/9905_San/H.225.0_Annex_G_990528.zip or http://standard.pictel.com/ftp/avc-site/9905_San/H.225.0_Annex_G_990528.zip ftp://standard.pictel.com/avc-site/9905_San/H.323_Annex_E_990528.zip or http://standard.pictel.com/ftp/avc-site/9905_San/H.323_Annex_E_990528.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

Re: SG16 Q13
by Lior Moscovici 02 Jun '99

02 Jun '99

Some comments: 1. The reference points naming is confusing: either TIPHON B, CA, CB, DA, DB, or SG11 i IFx. I would stick to the second one, to have common language. 2. Although we talked about it, Ed, I don't remember the point in IF7, between the MGC and the SCP via SC GF, bypassing the GK. The main path has to go through the GK anyway, and reasoning for that has to be given: the GK is the service manager and co-ordinator for the IP network. It decides whether a trigger can be handled inside or has to be diverted to the external SCP. 3. You refer to "peering SCPs". Purely SS7-wise, INAP is not peer-to-peer, so the GK is both SCP client (i.e. SSF) and server (i.e. SCF towards the SCN SSFs), but not at the same time. 4. The statement on the PINT server is a bit vague. I would rather say: "the PINT server is merely a web interface for controling SCN calls, thus has less relevance to H.323 that deals with multimedia over IP (packetized networks). 5. Direct routed call model has to be reflected in figure 3, or on a separate figure. Note that the fact that the GW is decomposed implies GRC, since the signaling and media pass on two different nodes, so the example has to be of a client terminal, rather than a GW. Lior -------- On 05/28/99 10:40 PM GMT "Edgar Martinez [1]" <martinze(a)CIG.MOT.COM> wrote: Dear SG16 Q13, I am sending this out for comments. On a proposed response to SG11. -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 TIPHON & Other Stds -- http://www.cig.mot.com/~martinze/

1 0

Re: [Q] H.261 GOB packetizing
by Roni Even 02 Jun '99

02 Jun '99

There is no limitation of one GOB per packet. The limitation is that a GOB will not break between packets unless the macro block is longer then the MTU, in that case you can break the GOB. There is no specific structure for a packet with more then one GOB, it is as defined in H.261. The only important information is that all packets of the same frame will have the same time stamp. ********************************************** Roni Even VP Product Marketing Accord Video Telecommunication Email: roni_e(a)accord.co.il Tel: +972-3-9251412 Fax: +972-3-9211571 *************************************************** > -----Original Message----- > From: Lee Hyoung soo [SMTP:soo@DESKVIEW.NADA.CO.KR] > Sent: Wednesday, June 02, 1999 2:52 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: [Q] H.261 GOB packetizing > > Dear All, > > I have some problem to packetize H.261 GOB into RTP packet. There are > too many GOB's to packetize only one GOB into one RTP packet. > > Can I pack two or more H.261 GOB's in one RTP packet? > And I want to know the structure of packet which includes two or more > H.261 GOB's. > > Any comment will be appreciated. > > soo. > > > > -- > Nada Research Co., Ltd. Korea > TEL : 82-2-525-3941 > > Lee Hyoung soo. > > mailto:soo@DeskView.nada.co.kr

1 0

Re: Quick report of the SG16 meeting in Santiago
by Sakae OKUBO 01 Jun '99

01 Jun '99

Dea Mr. Audet, FA> > Dear Q.12-14 experts, FA> > FA> > This is to draw your attention to some items from the outcome of SG16 FA> > meeting in Santiago. FA> > FA> > 1. Draft Recommendations for Decision FA> > FA> > All have been decided as intended. Annex G to H.222.0 has received US FA> FA> Do you mean H.225.0 instead of H.222.0? Thank you for your advice. Yes, it should read Annex G to H.225.0. 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