- sg16-avd - lists.packetizer.com

H.GCP / Megaco Audio call
by Bryan Hill 08 Jun '99

08 Jun '99

In order to continue the cooperation between SG16 and the IETF, there will be another Megaco/H.gcp conference call so that we have rough consensus on what Brian Rosen will put into megaco-protocol-02 (Internet-Draft cutoff date for IETF Oslo meeting is June 25/99). In Megaco we have agreed to produce a completed audio-only version of the megaco protocol for June 25th, but that this version would take into consideration the proposals for multimedia in SG16's H.gcpSantiago so that they can easily be added in a future version. We need to have an "implementable" version of the Megaco protocol by the July Oslo meeting, or we will have missed the boat. It is expected that the megaco-protocol-02 would be an implementable audio version of the Megaco/H.gcp protocol, and that SG16 would be able to add to the protocol syntax, in a backwards compatible way, all that is necessary for multimedia. Proposed discussion topics: 1) Termination naming - hierarchical or logical, or a combination with TerminationId + Bearer? 2) handling multplexing terminations - as in H.gcp? or as a new context type? 3) allowing one BearerDescriptor, and multiple MediaDescriptors per termination - acceptable? 4) decision on transport 5) proposal for tagging the MediaDescriptor with its encoding: SDP or H.GCP 6) proposal for text vs binary encoding of the protocol (draft-huitema-megaco-sdp-discuss-01.txt) 7) multimedia vs monomedia contexts (related to #3) Call Details Date: Wednesday, June 16th Time: 11amET for 2 hours Phone: 613-763-6338 PassCode: 131313# Problems getting on the bridge? call 613-765-CONF, and ask for the conference chaired by Nancy Greene. As before, minutes of the meeting will be posted ASAP after the call. Nancy Greene Bryan Hill ngreene(a)nortelnetworks.com <mailto:ngreene@nortelnetworks.com> bhill(a)videoserver.com <mailto:bhill@videoserver.com> -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

1 0

H.GCP is about gateway recomposition, not decomposition.. (attached)
by Boaz Michaely 06 Jun '99

06 Jun '99

Sorry about that attachement. (don't you love NOTES too ?) Hope this works : (See attached file: H.GCP composition.doc) - Boaz "John Talbot" <jptalbot(a)nortelnetworks.com> on 03/06/99 07:08:47 PM To: Boaz Michaely cc: Subject: RE: H.GCP is about gateway recomposition, not decomposition.. Michaely, Did you realy mean to send the image of the icon of the document rather than the document itself with your email? Anyway I read your document and have included my comments :-) <<pic10782.pcx>> Cheers John > -----Original Message----- > From: Boaz Michaely [SMTP:Boaz_Michaely@VOCALTEC.COM] > Sent: 03 June 1999 13:46 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: 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

1 0

Santiago meeting documents
by Sakae OKUBO 04 Jun '99

04 Jun '99

Dear Q.12-14/16 experts, All the files uploaded to the /Incoming directory of the PictureTel ftp site have been moved to the /9905_San directory. They include Mr. Ott's Annex F to H.323 and Mr. Duckworth's H.283. The index is given by the following: http://standard.pictel.com/ftp/avc-site/9905_San/9905_San.html For your convenience, the index file is attached to this message. Please Editors upload your Recommendations in charge as soon as your editing is completed. 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

Text Telephone support in megaco and H.gcp
by Gunnar Hellstrom 04 Jun '99

04 Jun '99

It seems to be useful to structure Text Telephone support in gateways in three levels: 1. Simple text-only support. ---------------------------- There is a simple way to use a textphone. That is to connect with the intention from the beginning to get a pure text call established and stay in the text-only mode during the whole call. Many users use this mode only, and it is also used in many cases in connection to relay services and emergency services. (relay services are services where the users get help to translate between different modes in the conversation, most commonly between voice telephony and text telephony. Relay services are usually manned services.) 2. Alternating text and voice support. -------------------------------------- Text telephone suppport can be quite advanced, with switching back and forth between text and voice during the call. This mechanism is used with current textphones that were created long before any simultaneous voice-data technologies were invented. Ideally, this support would also be wanted on any gateway termination, monitoring the line during voice operation for textphone tones and at that moment initiate text mode. 3. Simultaneous text and voice call. ------------------------------------ Alternative 2 is quite cumbersome for the users. A simple way to use simultaneous voice and text is eagerly needed. It is likely that the H.323 Annex G Text Conversation and Text SET will make this happen as the normal thing in the IP environment. But will it also eventually evolve in the PSTN? Within V.18 there is an opportunity to use V.61 for text telephony with voice and text. H.324 (especially without video) is also a possible environment. Market forces may tell if this enhancement is wanted in the PSTN. The Total Conversation terminals with simultaneous Video, Text and Voice should be placed in the simultaneous voice-text level when discussing text telephone interworking. Since Total Conversation terminals already exist in the H.320 invironment in ISDN, we have them in SCN as well as in IP networks. ----------- Termination arrangement for text telephone support. --------------------------------------------------- Level 1. -------- Level 1 can be achieved with a simple termination. On the SCN side it would contain V.18 modem support and terminate a T.140 text media stream. ( see eartlier message in the lists) Level 2. -------- If level 2 - alternating voice - text is going to be supported, it is advisable to have a model for how it should be viewed in terms of terminations, contexts and signaling. Multiplexor model: One model would be to regard the termination to contain a kind of multiplexor. It would then terminate two media streams - one T.140 text stream and one audio stream. The mechanisms to connect either stream to the line would be an internal mechanism in the termination. The need for external signaling in this case is low. Another model would be to regard the termination to terminate only one type of stream at a time. It would need to report events, e.g. about the carrier dropping, so that the voice mode can be started by an MGC command. A whole set of detailed interactions seems to be needed, between the MGC and the MG for the purpose of controlling the termination to follow the user's expectations for mode changes. I prefer the multiplexor model for the alternating voice - text mode. Some thoughts should be given to it, to verify if decent support of user requirements can be achieved. Level 3. -------- Level 3, simultaneous voice and text, is seen on the IP side as one T.140 TCP termination and one RTP audio termination. On the SCN side it is seen as a termination according to the kind of multiplexor it uses. Conclusions: ------------ I see no problem in mapping this structure within the H.gcp . I just want the mechanisms to be agreed on and the details around specific termination parameters and MG behaviour. It may be useful to take part of the discussion above into the megaco requirement spec in order to clarify what is meant with text telephone support and text conversation support. Regards Gunnar Hellström At 07:51 1999-06-04 -0600, Don Stanwyck wrote: >Gunnar Hellstrom wrote: >> >> Text Telephone support is very similar to FAX. If we let FAX into gateway >> specifications, we shall also include text telephony and text conversation >> in the same move. It saves a lot of efforts. > >Actually, text telephone (e.g., TDD) is quite a bit different from FAX, and >in the US, at least, mandated to be supported in every network (ADA >requirements). TDD conversations can be one-way modem one-way voice, >two-way modem, part-time modem (what TDD users call voice-over mode), etc. >My daughter is a TDD user, and we have become quite familiar with it. The >difficulties it presents to IP-telephony are considerable, but can be >solved by allowing that any line, any time, can be instantly converted to a >modem communication line without any prior notice or any promise that modem >tones will continue on the line for any particular duration. > >Don >Attachment Converted: "c:\_Omnitor\Attach\stanwyck.vcf" > ----------------------------------------------- Gunnar Hellstrom LM Ericsson E-mail gunnar.hellstrom(a)omnitor.se Tel +46 751 100 501 fax +46 8 556 002 06

1 0

Re: Decided and Determined texts
by Kumar, Vineet 04 Jun '99

04 Jun '99

I found H323AnnexF-decided.zip in http://standard.pictel.com/ftp/avc-site/9905_San/ vineet -----Original Message----- From: Kumar, Vineet [mailto:vineet.kumar@INTEL.COM] Sent: Friday, June 04, 1999 10:16 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Decided and Determined texts I was expecting to find H323AnnexF-decided.zip at http://standard.pictel.com/ftp/avc-site/Incoming/ but I don't see it there yet. vineet -----Original Message----- From: Greg Herlein [mailto:gherlein@HERLEIN.COM] Sent: Friday, June 04, 1999 2:12 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Decided and Determined texts > I have uploaded the decided clean text version of H.323 Annex F > into the Incoming directory of the PictureTel ftp site. The file > name is H323AnnexF-decided.zip Can someone give me a full URL for this document? I can't find it by browsing around... Thanks, Greg /************************************************************** Greg Herlein gherlein(a)herlein.com Herlein Engineering www.herlein.com Software Development - Communications - Networking - Linux/Unix ***************************************************************/

1 0

Re: Decided and Determined texts
by Kumar, Vineet 04 Jun '99

04 Jun '99

I was expecting to find H323AnnexF-decided.zip at http://standard.pictel.com/ftp/avc-site/Incoming/ but I don't see it there yet. vineet -----Original Message----- From: Greg Herlein [mailto:gherlein@HERLEIN.COM] Sent: Friday, June 04, 1999 2:12 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Decided and Determined texts > I have uploaded the decided clean text version of H.323 Annex F > into the Incoming directory of the PictureTel ftp site. The file > name is H323AnnexF-decided.zip Can someone give me a full URL for this document? I can't find it by browsing around... Thanks, Greg /************************************************************** Greg Herlein gherlein(a)herlein.com Herlein Engineering www.herlein.com Software Development - Communications - Networking - Linux/Unix ***************************************************************/

1 0

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

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

[Q] H.261 GOB packetizing
by Lee Hyoung soo 01 Jun '99

01 Jun '99

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: H.323v3 and Implementers Guide
by Sakae OKUBO 31 May '99

31 May '99

Dear Mr. Jones, PJ> Mr. Okubo, PJ> PJ> I have attached draft copies of the H.323v3 document and Implementers PJ> Guide to this e-mail. If you get an opportunity, I would like to ask PJ> that you post them to the AVC Santiago directory so that others may PJ> review the documents. The two files have been placed at the PictureTel ftp site as follows: ftp://standard.pictel.com/avc-site/9905_San/H323v3_990528.zip or http://standard.pictel.com/ftp/avc-site/9905_San/H323v3_990528.zip ftp://standard.pictel.com/avc-site/9905_San/H323_impguide_990528.zip or http://standard.pictel.com/ftp/avc-site/9905_San/H323_impguide_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

Quick report of the SG16 meeting in Santiago
by Sakae OKUBO 31 May '99

31 May '99

Dear Q.12-14 experts, This is to draw your attention to some items from the outcome of SG16 meeting in Santiago. 1. Draft Recommendations for Decision All have been decided as intended. Annex G to H.222.0 has received US reservation of up to 4 weeks (Annex G will become effective when US has returned a positive answer). 2. Draft Recommendations for Determination All have been determined as intended. Please note that the original H.450.8 (conference out of consultation) has been included in H.323 V3. 3. H.323 system Implementors Guide This has been approved. 4. Interim Rapporteur meetings We will have two experts group meetings as follows: - 2-6 August in Berlin - 1-5 November in New Jersey Detailed reports will follow soon in form of Mr. Tosco's WP2 report. 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: Assessing the Results Of Santiago
by Dale L. Skran 29 May '99

29 May '99

Thanks for a good summary of the work. As a matter of principle, as well as from a company point of view, you know I cannot accept backward compatibility with past MGCP drafts as a requirement. I hope the MEGACO group can be made to see that backward compatibility is unfair to all the companies (like mine) that implmented IPDC or whatever rather than some draft of MGCP. Dale At 07:54 AM 5/28/99 -0400, you wrote: >If the partnership between Megaco and Study Group 16 is to work, I need to >provide you with a detailed and honest description of the implications of >the Santiago results, so you can decide for yourselves whether we are moving >in the right direction. > >The latest H.GCP draft records three changes from the current Megaco draft. >One is the idea of what I will describe as the multiplane context. Another >is the idea of multiplex termination classes, on the packet as well as the >circuit side. The third is a list of most of the currently-known >termination attributes, grouped on a per-termination, per-plane, and >per-directed-media-flow basis as applicable. In addition, the idea of a >syntax for termination descriptors which expresses them as a termination >class (or template) ID plus a set of delta values was not recorded, but is >very interesting for the way it supports either SDP or H.245 signalling >between MGCs. I will explain each of these proposals in technical detail >below, followed by an assessment of their implications. > >First, an explanation of the multiplane (AKA multimedia) context. The first >part of the idea is that a single context is used to express all of the >media flow connections between a given set of terminations within the same >MG. Conceptually this context is equivalent to a stacked set of monomedia >contexts, but frees us from the need to represent the same termination in >multiple contexts and simplifies expression of lip-synch and other >inter-plane relationships. Conceptually also, the context provides one >bridge/mixer for each plane it contains, and the mode of bridge >operation/mixing has to be specified for each plane. The planeID can be an >optional parameter, and can certainly be omitted in the simple audio case. >Similarly the mixing type can be omitted in the simple audio case, as it is >in the current Megaco draft. > >For each termination in a multiplane context, the following has to be >specified in the most general case: >* the base termination attributes (which are by definition independent >of the media flows that termination currently supports) >* attributes which are needed to describe it in each plane in which it >participates, but which are common to both directions of media flow >* attributes which are unique to a particular direction of media flow >within a given plane. >In the simple audio case this degenerates into the current organization of >common attributes (TerminalState) plus per-flow-direction attributes >(LTDescriptor and RTDescriptor). > >The positive aspect of the multiplane context is that this offers a >marvellously flexible tool for expressing pretty well anything we need to, >regarding multipoint, multimedia conferencing within a single MG. It has >benefits even if we are talking only about audio: I could describe to you >how to apply it to support a main conference plus side-conferences between >subsets of participants, all within a single context. The negative aspect >of this proposal is that it forces, even in the audio case, at least a minor >rearrangement of termination attributes. In particular, for multiplane >contexts to be effective, the send-receive aspect has to be extracted from >the current Mode parameter and stated on a per-plane rather than a >per-termination basis. Moreover, the current breakout of terminal >descriptors in our commands into terminal state, LTDescriptor, and >RTDescriptor parts has to be augmented (for conciseness) by a >planeDescriptor part. This is not essential: the planeDescriptor could also >be distributed into both the LTDescriptor and the RTDescriptor parts. > >Next, the idea of multiplex termination classes has already been described >in previous discussions of H.320 operation. The basic idea as developed in >Santiago is that the termination descriptor includes a multiplex type >attribute. For a circuit-side multiplex, the common terminal parameter set >includes a list of the individual circuits included in the multiplex. The >idea of packet-side multiplexes was introduced for two reasons: to provide a >simple and implicit way to indicate synchronization requirements between >media flows relating to the same user, and to accommodate the need for >control channel interworking in the H.320-to-H.323 case. The syntax for >relating individual packet streams to the multiplex of which they are a part >is natural and implicit in the listing of per-directed-media-flow components >of the multiplex termination description. With the control channels comes >the need for unique event packages to support them. > >As already stated, the idea of multiplex termination classes on both the >packet and the circuit side solves the H.320/H.324 multilink problem. It >also allows all media flows relating to a given user session to be grouped >in a natural way so that relationships such as lip-synch can be easily >expressed. further, it provides a way to relate an H.245 control channel >terminating in the MG (because of interworking with H.320/H.324) to the >video flows for which that channel will carry commands and indications. The >negative side of this must be the need to extend our repertoire of >termination classes and attributes -- not, I believe, a significant >consideration in our decision to adopt the idea, since support of the >mechanism is not required for simple audio operation. > >The tabulation of individual termination attributes and their grouping on a >per-termination, per-plane, and per-directed-media-flow basis is the >scariest part of the whole exercise. I will provide that tabulation in a >separate message. The positive aspects of this work are that it detaches >the discussion of termination attribute syntax from the H.245/SDP debate, >and it allows a careful analysis of how we have to organize the content of >our protocol. It also provides a starting point for rapid development of >the detailed description of termination classes, to the extent that the >descriptions in the current Megaco draft need to be fleshed out. The >negative aspect is that it puts the current description of command >parameters into jeopardy and potentially sets back any parser development >which has been carried out based on the "unreviewed" portion of the current >Megaco draft. We also have to resist the impression that the list of >attributes is now closed; it should remain extensible to accommodate the >definition of new termination classes, even if the basic logical >organization remains unchanged. > >Finally, there is the idea of using thermination classIDs to carry major >amounts of information. The basic concept is that our termination classes >would be and their associated classIDs would be standardized and registered. >Each termination class would imply a list of attributes, ranges of values >for those attributes, a list of supported event packages, and a set of >default attribute values (which could include a list of which event packages >are active upon instantiation of a member of the class). Because the >classes are standardized, the classID by itself can carry a lot of >information between the MG and MGC. > >The idea of transmitting termination descriptors as the combination of a >classID (which connotes a predefined attribute list and a bunch of preset >default values) and a delta list of attribute values has several benefits. >The most obvious is more compact expression of termination descriptors in >the most common cases. Secondly, it is a means to make MG-MGC signalling >independent of MGC-MGC signalling: the MGC can carry pre-coded templates in >its favourite language, to which it can add the delta attribute values >before sending the whole thing off to the other end. Even more radically, >MGC-MGC signalling could itself carry the classIDs and deltas, but that is a >topic for another discussion. The negatives of this proposal are the >evident impact on command syntax in the current draft, plus the need to have >a way to provide unique identification of every attribute which could appear >in a delta list (including an indication of which plane and which flow >direction it applies to, as applicable). > >Well, that's the story. Now we need a political debate on whether the >relationship with SG 16 is workable based on the fruits of the meeting just >concluding, and a technical debate on the merits of each of the proposals I >have outlined. I'm sure you are aware that the two debates are >inter-related, in that SG 16 will feel let down if we reject their proposals >for grounds other than technical inadequacy (e.g. because some of us are >already committed to parsers based on the current Megaco draft). I've >stated the situation honestly, I hope, and I also hope that you find that >good things were done in Santiago. Let the discussion begin. > >Tom Taylor >E-mail: taylor(a)nortelnetworks.com (internally Tom-PT Taylor) >Tel.: +1 613 736 0961 (ESN 396-1490) >FAX: same number by prior arrangement (manual answer). >

1 0

Re: Assessing the results of
by Jerry Scharf 28 May '99

28 May '99

I had a hard time with classIDs issue as presented by Tom. I am somewhat neutral on the idea of using a two levels to send termination descriptions. I am not sure that this will be more efficient to implement in the real world, but that was not my objection. My objection was to the idea of standardizing these classIDs. If the rationale for these is the efficient transmitting of termination descriptions, then they should be modeled to the set of descriptions that will be in use by the MG in question. Since there is a strong relationship between MG and MGC (or between MGCs), these can be sent once at either the time of relationship formation or of classID creation, and get all the efficiency benefits that are proposed. Does anyone believe that there will be any restrictions on creating specific classIDs to meet specific MG needs? If not, that seems sufficient to handle the purpose being proposed with no loss in generality. Every time we put something in a standard, we create a legacy issue that all future systems are forced to deal with. I do not see any specific advantage in codifying what these classIDs shall contain. jerry

1 0