- sg16-avd - lists.packetizer.com

Re: H.323 AnnexD & mandatory fax OpenLogicalChannel elements
by Kumar, Vineet 06 May '99

06 May '99

Joachim, I think you have a draft version of Annex D and not the decided version. I can't find the sentence you mentioned in your email in my copy of Annex D. vineet -----Original Message----- From: joachim.fabini(a)SEA.ERICSSON.SE [mailto:joachim.fabini@SEA.ERICSSON.SE] Sent: Thursday, May 06, 1999 2:20 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: H.323 AnnexD & mandatory fax OpenLogicalChannel elements Hi all, >From H.323 AnnexD, D.7: "The H.323 AnnexD gateway shall send both a voice and a fax OpenLogicalChannel element in the setup message". Could anyone envolved in the development of AnnexD please outline the facts behind the _mandatory_ voice _and_ fax OpenLogicalChannel elements? Does this really mean that a H.323 gateway needs to open (or, at least offer) a fax channel beside each voice call if it intends to be also AnnexD compliant? The gateway can decide on the type (voice, fax) of the connection anyhow only _after_ the end-to-end voice channels are connected. Thanks in advance, Regards --Joachim Fabini --------------------------------------- Joachim Fabini Ericsson Austria AG Pottendorfer Strasse 25-27 A-1121 Vienna, Austria voice: +43 1 81100-5127 fax: +43 1 81100-4686 email: Joachim.Fabini(a)ericsson.com ---------------------------------------

1 0

Re: caller ID and implementer's guide
by Paul Long 06 May '99

06 May '99

Glen, Yes, this would definitely be a problem. As you know, 7.2.2.1/H.225.0v2 says, "Information transfer capability (octet #3) - The extension bit (bit 8) shall be set to '1'." Our EP expects the remote entity to set it correctly. If it's not, we assume that the SETUP is "bad" and clear the call by sending RELEASE COMPLETE. This goes for all changes being considered: a new Recommendation revision can augment and clarify but never modify the behavior defined by the previous revision. There is so much development effort in the H.323 world that you can't make a change simply because nobody responded to your query on the reflector. Please do not risk breaking implementations by modifying the Recommendation, no matter how obscure those modifications seem. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Glen Freundlich [SMTP:ggf@LUCENT.COM] Sent: Thursday, May 06, 1999 3:11 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: caller ID and implementer's guide At the Monterey meeting we discussed the possibility of an addition to the Implementer's Guide to support caller ID features (APC-1527). H.225.0 V2 (and V1) forbids the use of octet 3a in the Calling Party Number IE (and also specifies that the octet 3 extension bit shall be set to 1). The proposal calls for removing the restriction through the Implementer's Guide. (See also the meeting report in APC-1554b.) Fixing this brings up the possibility of interoperability problems with existing products. Please respond if you think this change will be a problem. You can respond to me individually, rather than to the entire list, if you prefer. Thanks, Glen -- 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

caller ID and implementer's guide
by Glen Freundlich 06 May '99

06 May '99

At the Monterey meeting we discussed the possibility of an addition to the Implementer's Guide to support caller ID features (APC-1527). H.225.0 V2 (and V1) forbids the use of octet 3a in the Calling Party Number IE (and also specifies that the octet 3 extension bit shall be set to 1). The proposal calls for removing the restriction through the Implementer's Guide. (See also the meeting report in APC-1554b.) Fixing this brings up the possibility of interoperability problems with existing products. Please respond if you think this change will be a problem. You can respond to me individually, rather than to the entire list, if you prefer. Thanks, Glen -- 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

Drafat H.450.8
by Sakae OKUBO 06 May '99

06 May '99

Dear Q.12-14/16 experts, The following document for the SG16 Santiago meeting has been placed at the PictureTel ftp site: ftp://standard.pictel.com/avc-site/9905_San/ or http://standard.pictel.com/ftp/avc-site/9905_San/ Source: Editor Title: Draft new Recommendation H.450.8 (for determination) Conference out of Consultation Supplementary Service for H.323 (SS-CoC) Type: TD File: DraftH.450.8.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: flowControlCommand and packet overhead
by Paul Long 06 May '99

06 May '99

Steve, But H.323, the referencing document via H.225.0 of RFC 1889, says that bandwidth for the open logical channel bitrate and ARQ is calculated _without_ headers. We cannot change this, because it would break existing implementations. Are you suggesting that flowControlCommand should do it differently, i.e., include at least the RTP header? The value in consistently using the same, although arguably flawed, bandwidth calculations outweighs the benefit of having a mix of calculations. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Stephen Casner [SMTP:casner@CISCO.COM] Sent: Wednesday, May 05, 1999 10:20 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: flowControlCommand and packet overhead On Wed, 28 Apr 1999, Paul Long wrote: > Therefore, clarification text to the following effect should be added to > 6.2.11.2 (in v2) of H.323: > > "flowControlCommand applies to the information streams which are the > content of logical channel(s), not including RTP headers, RTP payload headers, > network headers and other overhead." I'm mostly a lurker on this list, but I thought I would offer another perspective. The RTP spec, RFC 1889, says the following: Bandwidth calculations for control and data traffic include lower- layer transport and network protocols (e.g., UDP and IP) since that is what the resource reservation system would need to know. The application can also be expected to know which of these protocols are in use. Link level headers are not included in the calculation since the packet will be encapsulated with different link level headers as it travels. At a minimum, I would expect the RTP payload header to be included because that is specific to the encoding and would not be known by lower layers. The difficulty in pushing this problem off to lower layers is that they need to know the packet rate in order to know how much overhead the additional headers will add. -- Steve

1 0

H.323 AnnexD & mandatory fax OpenLogicalChannel elements
by joachim.fabini＠SEA.ERICSSON.SE 06 May '99

06 May '99

Hi all, >From H.323 AnnexD, D.7: "The H.323 AnnexD gateway shall send both a voice and a fax OpenLogicalChannel element in the setup message". Could anyone envolved in the development of AnnexD please outline the facts behind the _mandatory_ voice _and_ fax OpenLogicalChannel elements? Does this really mean that a H.323 gateway needs to open (or, at least offer) a fax channel beside each voice call if it intends to be also AnnexD compliant? The gateway can decide on the type (voice, fax) of the connection anyhow only _after_ the end-to-end voice channels are connected. Thanks in advance, Regards --Joachim Fabini --------------------------------------- Joachim Fabini Ericsson Austria AG Pottendorfer Strasse 25-27 A-1121 Vienna, Austria voice: +43 1 81100-5127 fax: +43 1 81100-4686 email: Joachim.Fabini(a)ericsson.com ---------------------------------------

1 0

Mr. Tosco's WP2 workplan
by Sakae OKUBO 06 May '99

06 May '99

Dear Q.12-14/16 experts, Attached please find Mr. Tosco's draft workplan received some weeks ago (apologies for this delayed distribution). Please note that it is a draft subject to change according to the need identified. 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

Useful information from Mr. Campos-Neto via Mr. Sullivan
by Sakae OKUBO 06 May '99

06 May '99

Date: Tue, 27 Apr 1999 11:12:27 -0400 From: garys(a)python.pictel.com (Gary Sullivan) To: itu-adv-video(a)standard.pictel.com Subject: [wg5-3: 2824] Q15: Amd. Administratrivia II Santiago May 99 Sender: owner-wg5-3(a)inetserv.ttc.or.jp Precedence: bulk ITU-T Advanced Video Coding Experts Group (Q.15/SG16) Email from garys(a)python.pictel.com (Gary Sullivan): A forwarded message from our Working Party Chairman: -Gary S. >----------------------------------------- >From: Simao Campos <simao(a)ctd.comsat.com> >Subject: [Q.20/16] Amd. Administratrivia II Santiago May 99 >Date: Sat, 17 Apr 1999 09:52:00 -0400 Dear colleagues, Fixing an error and a clarification on my previous messgae. Simao -- A quick update for the upcoming SG 16 meeting: - the workshop has been confirmed for the 17th May, for those interested in attending. Also, please notice that there will be a SG 16 Welcome dinner on Wed May 19 and a farewell lunch on Sat May 29. - now you can submit contributions to the ITU via a WEB browser. Fill in the form at http://www.itu.int/ITU-T/edh/ . See http://www.itu.int/ITU-T/edh/ for a Q&A on submission methods, and TSB Circular Letter 182 as well (a must-see) -- check at http://www.itu.int/itudoc/itu-t/circ/circ4/182.html. - Also, please be sure to use the appropriate ITU-provided templates (see http://www.itu.int/itudoc/itu-t/template/index.html) and A4 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ paper size when composing you documents. Also, be aware that documents prepared with Word 97, even if saved in the Word 6/95 format, may loose information when read by Word 95 [aka Word 7] (even though it may *look* OK in Word 97!!!). This is especially true if you try to use the Word 97 embedded drawing tools. DON'T! INSTEAD, use an external drawing package and import the picture into the document. And always provide them as individual files to the ITU, when you submit the document. When in doubt, also provided the ITU with a printable version of your document, e.g. postscript or Acrobat .PDF files. I had this grief many times, not to mention that it took me time to make sure some other people's documents had their missing figures recovered. So please, be careful, or your document may show up not exactly as you hoped for ... :-) NOTE on templates: ^^^^^^^^^^^^^^^^^^^ If they look funny on your screen, try the following in Windows95/NT: exit Word, then open Control Panel, double-click Regional Settings, select the tab "Number". Go to the last item in the menu ("LIst Separator") and change whatever character is in there (probably a comma ",") to a semi-colon (";"). Click OK, reopen the template; it should look "familiar" now. That's what I had for the moment. Any questions or problems, drop me a line. Best regards, Simao Campos-Neto ---------------------------------------------------------------------------- ---- *** ITU-T Advanced Video Coding Experts Group (Q.15/SG16) Email List Message *** To send messages, address them to "itu-adv-video(a)standard.pictel.com". To subscribe or unsubscribe, send email to "majordomo(a)standard.pictel.com". Note: Only people whose exact email address is subscribed to the list can post. Subscriptions: "subscribe itu-adv-video YOUR-EMAIL-ADDRESS" in message body. Unsubscriptions: "unsubscribe itu-adv-video YOUR-EMAIL-ADDRESS" in message body. ---------------------------------------------------------------------------- ----

1 0

flowControlCommand and packet overhead
by Paul Long 05 May '99

05 May '99

In response to a private query, I discovered that there is a minor oversight in H.323 regarding whether the flowControlCommand includes packet overhead. Here's what it says about the open logical channel bitrate and ARQ bandwidth parameters, respectively, which can be used to determine the intent for FlowControlCommand: 6.2.11.2/H.323v2: "The limit applies to the information streams which are the content of the logical channel(s), not including RTP headers, RTP payload headers and network headers and other overhead." 7.2.4/H.323v2: "This is an upper limit on the aggregate bitrate for all transmitted and received, audio and video channels excluding any RTP headers, RTP payload headers, network headers, and other overhead." Therefore, clarification text to the following effect should be added to 6.2.11.2 (in v2) of H.323: "flowControlCommand applies to the information streams which are the content of logical channel(s), not including RTP headers, RTP payload headers, network headers and other overhead." Practically speaking, though, it appears that most vendors violate H.323 by ignoring this command altogether, so one is doing very well indeed at least attempting to obey it with or without counting overhead. Note that in H.324 the limit includes packet overhead when applied to the entire mux but not when applied to an individual channel; however, in H.323 the limit never includes overhead. IMO, H.324 makes more sense, but I suppose in H.323 one may not know exactly how much overhead is added by a lower layer, e.g., the UDP/IP headers added by the sockets layer, and also because H.323 is ostensibly transport-layer independent. Paul Long Smith Micro Software, Inc.

2 1

RTP MIB status
by Stephen Casner 05 May '99

05 May '99

I expect that the MIB for RTP has been discussed in SG16 already as part of H.341, but I wanted to let you know that the draft is now in last call for comments in the AVT working group of IETF. Comments from participants here are welcome (send to rem-conf(a)es.net or the authors listed in the draft). The draft is available at http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mib-05.txt The next step after working group comments are resolved is to submit for publication as an RFC, which results in an IETF-wide last call. Steve Casner, AVT co-chair

1 0

Documents for the Santiago meeting
by Sakae OKUBO 05 May '99

05 May '99

Dear Q.12-14/16 experts, I have placed the following files at the ftp site. ftp://standard.pictel.com/avc-site/9905_San/ or http://standard.pictel.com/ftp/avc-site/9905_San/ SOURCE: United States of America TITLE: Correction of problems related to MCV in the white draft of H.230 TYPE: Delayed Contribution FILE: Delayed_H230.zip SOURCE: Toshiba, NEC, NTT DoCoMo TITLE: Proposed editorial revisions on H.245 version 5 regarding MPEG-4 visual codepoints and the generic capability TYPE: Delayed Contribution FILE: h245v5decision-correction.zip SOURCE: Motorola, Cisco TITLE: Comments upon H.323 Annex E TYPE: Delayed Contribution FILE: WG16_comm_annexE.zip SOURCE: LM Ericsson TITLE: DRAFT NEW ANNEX C FOR THE H.246 RECOMMENDATION TYPE: Delayed Contribution FILE: h246_annex_c_v_0-1.zip SOURCE: Q.13 Rapporteur TITLE: Editorial Changes to H.225.0 Annex G TYPE: TD FILE: annexg_editor_contribution2.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 ***********************************************************

2 1

Implementers Guide Edits
by Jim Toga 05 May '99

05 May '99

Greetings, Attached is the updated text from the Implementers guide that incorporates the comments that I got back from the previous posting. Specifically it includes elements from Espen Skjaeran, Dave Walker and Karl Klaghofer. Any final comments ASAP to me. Best Regards, jimt. MetaTel - Boston, MA mailto:jim.toga@metatel.com +1-781-891-9000 PGP keyID E746 1CE4 CEC0 C91E 7190 65CA 70B1 B1D2 6A1E A2B7

3 4

Re: Annex G & big messages (and TPKT and Annex E)
by Andrew Draper 05 May '99

05 May '99

At 09:35 1999-05-04 +0200, ETO wrote: >When an Annex G message will exceed max packet size (typically a >DescriptorConfirm) on UDP, a Reject might be sent, and the session is >repeated on TCP. > >But, isn't our PDU size on TCP also limited? When using TPK, the max pdu >size is 65k too, as seen in RFC-1006.... I don't think this is a problem for Annex G. First, a sensible implementation is probably sending DescriptorRequests over TCP anyway since it expects a large (well larger than MRU) answer anyway so the UDP step described above won't happen (only AccessRequest and ValidationRequest is likely to be sent over UDP). Secondly, the only message likely to run into the maximum message size limit is the DescriptorConfirm (if a descriptor is more than 64K). I don't expect anyone to have a descriptor of 64K or more, but if they do it can be broken down into multiple descriptors, and each one transmitted separately. For call signalling over annex E the message size limit isn't a problem either. Annex E will be transmitting the same call signalling messages as would be sent over TPKT over TCP, so messages of more than 64K aren't allowed (since they wouldn't fit within TPKT), even if anyone can create a plausible one. Regards, Andy -- Andrew Draper -- Principal Development Engineer -- WAVE Software Madge Networks, Wexham Springs, Framewood Road, Wexham, Berks, UK. mailto:adraper@madge.com = = = = = = = = = phone:+44 1753 661329 pgp fingerprint 8776 1F5F DD1B F37E BEF7 1E52 924D F6B7 34CB EFA9

1 0

Re: Paper on multimedia contexts in H.gcp/megacoP (pdf format)
by Roni Even 05 May '99

05 May '99

John, I would like to clarify the distributed multi media functionality. If you take an H.323 MCU instead of implementing T.120 in the same physical equipment you can use an external T.120 MP and using the option of opening a logical channel to it using a different IP/Port address. The MGC still has to know that it is one call, if the end points does a disconnect, the MGC should also disconnect the T.120 part. Another point about H.323/H.320 gateway is that in H.320 you open an mlp/hmlp channel that can be used for T.120 but may also serve for H.281 FECC, if an H.281 FECC data comes the MG should tell the MGC to start an H.282/283 FECC termination on the H.323 side. Regards Roni ********************************************** 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: John Segers [SMTP:jsegers@LUCENT.COM] > Sent: Monday, May 03, 1999 6:19 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Paper on multimedia contexts in H.gcp/megacoP (pdf > format) > > > Attached you'll find a document explaining how multimedia contexts > could > work. The document is still evolving (see notes on the last page), > but > I thought I'd better get it out in time for people to be able to look > at > it before tomorrow's conference call. > > Regards, > > John Segers > -- > John Segers email: jsegers(a)lucent.com > Lucent Technologies Room HE 344 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > << File: mm-hgcp.pdf >>

2 1

Re: Annex G & big messages (and TPKT and Annex E)
by Gur Kimchi 05 May '99

05 May '99

Douglas , Espen: You are right, both TPKT and Annex E limit each segment within a message to a max of 64K bytes - and both allow you to aggregate - place multiple payloads, each sized at (or less) 64K in a single message - this is of course relevant only to Annex E over TCP (which is not really used as this time for anything). I don't see this is a serious limitation - unless the information exchange between GKs is going to contain many pictures... seriously, you will need to divide up your large transactions into 64K segments. If any of you think this is a real problem - speak up - - gur -------- On 05/04/99 09:15 AM GMT Douglas Clowes <dclowes(a)OZEMAIL.COM.AU> wrote: No, I had reached the same conclusion - the packet size is, indeed, limited to 65K bytes. If the message size exceds the UDP MTU, it hould be sent by TCP. What I am still wondering is, will we exceed the 65K on TCP? Subtly, this raises a similar question for Annex E which has the same limitation. Should Annex E have a larger size field, and Annex G use Annex E for a larger message size? Does the TPKT size limitation affect anything else which uses it? Douglas At 09:35 1999-05-04 +0200, ETO wrote: >Hi all, > >When an Annex G message will exceed max packet size (typically a >DescriptorConfirm) on UDP, >a Reject might be sent, and the session is repeated on TCP. > >But, isn't our PDU size on TCP also limited? When using TPK, the max pdu >size is 65k too, as seen in RFC-1006.... > >Hope I'm wrong here. > >Espen > >

2 1

Re: Megaco/H.gcp call - Minutes
by Matt Holdrege 04 May '99

04 May '99

At 02:27 PM 5/4/99 -0400, Nancy-M Greene wrote: >Here are the minutes for the call today - if I have gotten anything wrong, >or missed anything, please let me know. I think that you missed the discussion we had on the MGC knowing the capabilities of the MG. Also if that would have an effect on call processing efficiency. I believe that Gur and I made the point that it would improve efficiency (not to mention applications). Others had concerns. Those of us who are at the ETSI TIPHON meeting this week will discuss this in person and we can all discuss it more during the next conference call.

1 0

Annex G Editorial Comments
by Lior Moscovici 04 May '99

04 May '99

Hello All, Attached are editorial changes to Annex G. I intend to submit them as a Rapporteur TD to the Santiago meeting. If anyone has some additional comments, please forward to me, so I can incorporte them in the decided version. Thanks, Lior (See attached file: annexg_editor_contribution2.doc) Lior Moscovici Program Manager, Servers Group R&D VocalTec Communications Ltd. Voice: +972 9 9707767 E-mail: liorm(a)vocaltec.com Fax: +972 9 9561867

1 0

subscribing to the Megaco mailing list
by Nancy-M Greene 04 May '99

04 May '99

The IETF Megaco mailing list switched list servers last month. If you want to join the megaco(a)standards.nortelnetworks.com mailing list, here is how: To subscribe to this list, send a message to listserv(a)standards.nortelnetworks.com containing the line subscribe megaco To unsubscribe, send a message to listserv(a)standards.nortelnetworks.com containing the line unsubscribe megaco Archive of messages: http://standards.nortelnetworks.com/archives/megaco.html Note: you can always find out about mailing lists associated with IETF WGs by going to the www.ietf.org web page, following the IETF Working Groups link, finding the Megaco WG in the Transport Area. All WG internet-drafts are also listed there. Here is the URL: http://www.ietf.org/html.charters/megaco-charter.html Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

1 0

Megaco/H.gcp call - Minutes
by Nancy-M Greene 04 May '99

04 May '99

Here are the minutes for the call today - if I have gotten anything wrong, or missed anything, please let me know. Nancy Minutes of the Megaco/H.gcp call held May 4/99, 10-12 ET ---------------------------------------------------------------------------- ----------- Attendees: Participants from both the IETF Megaco WG, and ITU SG16 were present on the call. A total of 27 people called in. Results are summarized here, and are open for discussion on the mailing lists. (Actions are prefaced by **.) Results: ----------- 1: Multimedia/H.320 discussion - John Seger presented his paper on multimedia contexts - More detailed call flows are needed for the multimedia context and the monomedia context cases. - criteria: - protocol needs to be optimized for the most common case - for multimedia contexts, need to distinguish between media streams for applying events to the right stream, and mode is per media stream - for monomedia contexts, need to specify the media of the context, and which terminations are linked across contexts, there are more objects to handle, but they are simpler ** Tom Taylor will provide the signalling for one or more call flows ** John Seger and Brian Rosen (and anyone else who wants to!) will work through the multimedia context and the monomedia context call flows using the signalling Tom provides. 2: Context Parameter for "mixing" the media - there was agreement that, independent of whether a context is mono or multimedia, we need a context parameter indicating how media is to be mixed within a context. For audio it would default to simple mixing, but other choices might be offered, for video it could be based on current speaker, etc. In any case, there needs to be a context parameter to hold this information. 3: H.245 vs SDP - Agree that both H.245 and SDP can provide the same degree of expressiveness. - Neither is complete as it is - we are not using SDP headers, just SDP syntax + additions - H.245 already has a way to express capabilities such as MG resource constraints described as " I can support 4 G.723 codes, or 7 G.726 codes, or some particular mix of the two" - we can take this and use it to write the same thing in SDP syntax. ** Gur Kimchi will write up an email on capability exchanges and send it to the Megaco mailing list. With his method, he does not think it is hard for the MGC to track resource usage in the MG. - discussed whether the MGC would need to look inside the SDP/H.245 syntax before shipping it off to the next MGC or MG. Most said, yes, the MGC would need to look into it - need to verify it, perhaps need to modify it. Then the MGC tells the MG what to do. Do we need to allow some flexibility here for MGs that want to decide some of this information themselves? - Issue then becomes: - is SDP or is H.245 better for making the MGC scaleable and fault tolerant? - What is the load on an MGC depending on the protocol choice? Need concrete comparisons of H.245 syntax and SDP syntax. 1) what is the info the MG must tell the MGC 2) how to encode the info the MG must tell the MGC (i.e. Audit) 3) how to encode the info an MGC tells an MG (i.e. Add, Modify) ** How will we advance? There is interest in seeing what Christian Huitema is working on in this area. Will anyone else prepare syntax comparisons? - H.245 in the MG There is a contribution into SG16 for an H.320 MG to contain H.245. This contribution (as well as other SG16 contributions) will be made available to the Megaco mailing list. Issues with this: How does the MGC remain aware of the resources the MG is committing? Is the H.245 backhauled to the MGC or does the MG make decisions and notify the MGC of its decisions? 4: Scripting - briefly discussed: if an MG wants to run using Java scripts and notifications, they can be written up in a Java scripting package. No need to add anything new to the protocol. MGC finds out if an MG has that scripting package using an Audit. 5: Logical names for terminations - related to mono vs multi media contexts discussion - if a context is multimedia, a physical termination need only live in one context, if a context is monomedia, a physical termination may need to be virtually present in more than one context. - structure of the termination name can be duplicated using parameters 6: Handling stereo in monomedia contexts - if all terminations involved are stereo, only need one context. If some are mono and some are stereo, then need one context for left, and one for right. 7: Sharing information from SG16 to the IETF ** Tom Taylor and Glen Freundlich will work out the best way for IETF Megaco participants to have access to ITU-T SG16 contributions to the Santiago meeting. 8: Next Audio Call May 11/99 10am-12pm ET - call details will be posted to the Megaco and ITU-SG16 mailing lists. ---------- -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

1 0

Annex G & big messages
by Espen Skjæran (ETO) 04 May '99

04 May '99

Hi all, When an Annex G message will exceed max packet size (typically a DescriptorConfirm) on UDP, a Reject might be sent, and the session is repeated on TCP. But, isn't our PDU size on TCP also limited? When using TPKT, the max pdu size is 65k too, as seen in RFC-1006.... Hope I'm wrong here. Espen

2 1

text telephony Requirements
by Nancy-M Greene 03 May '99

03 May '99

Gunnar, thanks for reviewing the requirements document. I have incorporated the changes you suggested. See below for the relevant references in the new draft-ietf-megaco-reqs-03.txt document. Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > ---------- > From: Gunnar Hellstrom[SMTP:gunnar.hellstrom@OMNITOR.SE] > Sent: Thursday, April 22, 1999 5:38 PM > To: MEGACO(a)standards.nortelnetworks.com > Subject: Re: Media Gateway Control Requirements > > Previously sent to ITU-T Q13/16: > > I checked the Megaco requirements mainly from the point of view of how > well > it covers gatewaying between different forms of real time text > conversation > facilities. The most apparent need is between the current analogue network > based text telephones and IP text phones that are in the process of being > defined in SG16. The current textphones are working with different types > of > modem-like signalling ( that all can be joined by the V.18 modem in the > gateway) while in IP networks it is T.140 carried by a data protocol. > > With the current efforts in the US to arrange some kind of gateway between > land based text telephony and mobile text telephony, work in this > direction > is already going on. > > I found very little influence. And that might pose a question: Is Megaco > too vague, does it need to get more specific in its requirements to really > imply something? > But that might be the next step - the protocols and functions. > I want to suggest the following modifications to specifically mention the > important real time text gatewaying: > -------------------------------------------------------------------------- > --- > 5.2 d : insert "text" together with the other media, to read "e.g. audio, > text, video, T.120 ) ok > 5.3 d : insert "text telephony" before FAX ok > 11. Table 1. I am not sure what this table indicates. All multimedia > protocols are missing. Is it some kind of very basic mandatory media > requirements? > Without really knowing, I recommend: For ISDN, add Multi-media to the > applications. Multimedia added for Trunk+ISUP, Trunk+MF, and ISDN. > For Analogue, and Restricted, add Text telephony after FAX. Text Telephony added for Analogue, but I missed adding it to Restricted - will do this for next revision. > Insert a new section 11.2.4 ( pushing the existing down one step) > 11.2.4 Trunking/Access Gateway with text telephone access ports ok, but this section will only survive if someone lists specific requirements that belong here that are not covered elsewhere. Same goes for all other sections with no text in them. > 11.2.10 IVR Unit > Insert a requirement: IVR should never be the only way to control the MG. > Text based and web based control are important alternatives. 11.2.11 r) added: r. Be able to support an IVR unit that provides text-based and/or web-based prompts instead of audio-based prompts. > Accepted? yes, thanks. > Gunnar Hellström > >

1 0

Increase recommended ARQ timeout?
by Paul Long 03 May '99

03 May '99

At the interop, I sent an ARQ to a GK with an unregistered alias on purpose. The GK scanned its database, couldn't find it, and then queried another GK. I tried this maybe three times, and found that it took around 20 seconds for "my" GK to respond with its ARJ. The recommended time out and retry count is 3 seconds and 2 times, respectively, for an ARQ (7.19/H.225.0v2). This adds up to a maximum recommended time out of 9 seconds. The person testing the GK thought that it should be longer due to the fact that a GK may have to query another GK before responding. The GK-GK query should always be one-deep, regardless of whether it uni- or multicast the LRQ, so the time-to-reply is not indeterminate. Should we increase the recommended total wait for an ARQ to around 30 seconds, such as a time out and retry of 10/2 or 5/5? I know that a GK can use RIP with a v2 EP to increase the timeout, but increasing the recommended values would work with all EPs. Any thoughts? Paul Long Smith Micro Software, Inc.

1 0

Paper on multimedia contexts in H.gcp/megacoP (pdf format)
by John Segers 03 May '99

03 May '99

Attached you'll find a document explaining how multimedia contexts could work. The document is still evolving (see notes on the last page), but I thought I'd better get it out in time for people to be able to look at it before tomorrow's conference call. Regards, John Segers -- John Segers email: jsegers(a)lucent.com Lucent Technologies Room HE 344 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954

1 0

Re: Synchronization Of Streams
by Roni Even 02 May '99

02 May '99

Tom, The H.245 allows the association of specific streams for lip synch between audio and video. The general case that you specify is to know which streams belong to one call so that you can treat them as one entity. The MGC must know both relations to control the call. Roni Even ********************************************** 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: Tom-PT Taylor [SMTP:taylor@NORTELNETWORKS.COM] > Sent: Thursday, April 29, 1999 6:38 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Synchronization Of Streams > > This is a question which affects the design of the Media gateway > control > protocol. What information must be passed to the MG so it knows which > media > streams have to be synchronized? Is it sufficient that the MG knows > which > streams are flowing over the same user connection, or does the > relationship > have to be specified on a per-stream basis. I know that H.245 allows > the > latter, but I am considering the possibility of a Termination in a > multimedia context, which binds together multiple H.245 Logical > Channels. > Under that circumstance, can the MG use rules to know that, for > instance, > audio and video are synchronized but data flows independently? > > 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: Megaco/H.gcp call
by Tom-PT Taylor 30 Apr '99

30 Apr '99

Make that EDT, not EST. > -----Original Message----- > From: Bryan Hill [SMTP:bhill@VIDEOSERVER.COM] > Sent: Friday, April 30, 1999 7:41 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Megaco/H.gcp call > > Colleagues, > We would like to hold another H.GCP/Megacop audio call on Tuesday May 4th > at > 10 AM until noon EST. Agenda for the call is as follows > 1. Discuss multimedia/H.320 support > 2. Discuss SDP/H.245 message formats > 3. Any issues/question for the latest megacop draft > The call details are listed below and as usual, comments presented during > this call carry equal weight as those on the Megaco and ITU reflectors. > The > SG16 meeting in Santiago is fast approaching and reaching consensus on > these > topics prior to this meeting is clearly the goal of this call. > > Date: Tuesday May 4th/99 > Time: 10:00amEST - 12:00pmEST > Phone: 1-613-763-6338 > PassCode: 131313# > > ***Problems getting on the call? Call 1-613-765-CONF, and ask for the > conference chaired by Nancy Greene > ***No tones will announce people joining or leaving the conference > ***Minutes from the call will be posted by the end of the day to both the > Megaco and the SG16 mailing lists ***supposedly 63 will mute your phone, > and > 64 will unmute it - if you are about to use it, let Nancy Greene know - we > had problems with it last time... Of course your regular phone mute button > should work with no problems. > > Nancy Greene Bryan Hill > ngreene(a)nortelnetworks.com <mailto:ngreene@nortelnetworks.com> > bhill(a)videoserver.com <mailto:bhill@videoserver.com> > -------------------------------------------------------------------------- > --

1 0