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

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