- sg16-avd - lists.packetizer.com

ASN.1 vs Text
by Tom-PT Taylor 01 Apr '99

01 Apr '99

Since the other responses seem to have gone off into a discussion of firewalls, let me respond to this more directly by recalling a bit of past discussion. 1) On the Megaco list, we finally agreed that the text vs. binary question is something to be resolved by experiment. 2) In Turin (I think), the general opinion was that the protocol would have to be binary to achieve the required performance. Interestingly enough, however, no one that I recall felt that it should be PER ASN.1 (or even, I think, BER ASN.1). Good reasons were given at the time. It would be good if someone can remember them, but I think it has something to do with processing performance and less risk of fragmentation than call signalling. 3) We have had an occasionally recurring suggestion on the Megaco list that the Media Gateway control protocol should conform to the format of other messaging out of the MGC, for the reason you give (i.e. to minimize transcoding). Interestingly, the person advocating this was talking about billing data, not signalling. The counter-argument on the list is that the Media Gateway control protocol must work with different signalling protocols (for example in H.GCP's case, with any of the H-series systems), so there is no point in optimizing it for just one. The real sticking point of debate is going to be whether the media description structures will be those defined for H.245 OLC etc., or SDP. Text vs. binary is a closely related but broader debate. I'd suggest we start thinking about experimental design. > -----Original Message----- > From: Ami Amir [SMTP:amir@RADVISION.RAD.CO.IL] > Sent: Wednesday, March 31, 1999 4:15 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.320 gateways a MEGACO / ITU > > Hi > > During the last MEGACO conference call - Tom Taylor asked what could > hinder > ITU acceptance of the MEGACO work. It is obviously to everybody's interest > that IETF and ITU standards merge. As an example - it would be great if > the > MEGACO work could become an ITU SG 16 contribution. > > An obvious item is efficient multimedia support (as reflected also in > John's > mail). > > However, I think that one of the even more major difficulties facing us > will > be the encoding scheme (ASN.1 vs Text). > > There are many who feel that ASN.1 is too heavy and complex for simple > devices, and should be avoided. This was one of the major reasons for the > emergence of SIP. > > On the other hand, experience in the ITU H.323 work has shown that since > ASN.1 is the encoding scheme on the PSTN side, the use of ASN cleared the > way for PSTN to IP interoperability. This feature will be extremely > important in hybrid networks that need to provide Intelligent Network (IN) > services (e.g. "800"), while retaining the investment in existing IN, > billing and directory services (411). > > Another problem is that if ASN.1 is not chosen, every device that will > have > to connect between a MEGACO component and H.323 will need to dis-assemble > and re-assemble (transcode) messages, and hence network performance will > suffer, and those devices will be more complex. A prime example - MGC to > GK > communications. > > I am not promoting a specific approach. I just think that this complex > issue > needs to be addressed if we want to be able to be able accept a universal > protocol. > > Do you think this is really a problem? > If so - any ideas on how to bridge the gap? > > Ami > > -----Original Message----- > From: John Segers [SMTP:jsegers@lucent.com] > Sent: Tuesday, March 30, 1999 6:27 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: H.320 gateways > > People, > > In yesterday's conference call, the subject of H.320 GWs was > raised > briefly. In my opinion, the connection model and protocol should > be > able > to deal with H.320. I would like to continue discussion on it on > the > mailing list. > > H.320 allows a user to have a session with both audio and video on > a > single 64 kbit/s channel such as an ISDN B-channel. The same > channel > carries some signalling information (frame alignment, bitrate > allocation). To a MG supporting H.320, this means that on a > single > endpoint, three streams can come in, carrying different types of > media. > The current connection model of megaco/H.gcp does not cater to > this. > I > see two possible solutions: > > The first is to allow multiple media in one context and to > describe > for > terminations the logical streams they carry. In a picture: > > +----------+ > | | > | +--------- signalling (FAS, BAS) > | | > B-channel ==========+ +--------- audio (16 kbit/s) > | | > | +--------- video (46.4 kbit/s) > | | > +----------+ > > The second solution is to have separate terminations for the > different > streams. They would all "connect to" the same physical endpoint. > In > order to properly identify the terminations, it is necessary to > have > logical names for them. The physical endpoint they connect may > have > the > hierarchical name proposed in the megaco document. > > Another example of a H.320 session is the case of two B-channels > being > used for an audiovisual call. The following frame structure is > then > possible. > > +--------------------------++-----------------------+ > | Channel 1 || Channel 2 | > +-----+--+--+--+--+--+--+--++--+--+--+--+--+--+--+--+ > |Bit 1|B2|B3|B4|B5|B6|B7|B8||B1|B2|B3|B4|B5|B6|B7|B8| > +-----+--+--+--+--+--+--+--++--+--+--+--+--+--+--+--+ > 1 | a1 |a2|a3|a4|a5|a6|v1|F ||v2|v3|v4|v5|v6|v7|v8|F | > 2 | a7 |a8|a9|a |a |a |v9|F ||v |v |v |v |v |v |v |F | > 3 | a |a |a |a |a |a |v |F ||v |v |v |v |v |v |v |F | > 4 | a | | | | |a |v |F ||v | |v |F | > 5 | a | | | | |a |v |F ||v | |v |F | > 6 | a | | | | |a |v |F ||v | |v |F | > 7 | a | | | | |a |v |F ||v | |v |F | > 8 | a | | | | |a |v |F ||v | |v |F | > +---------------------------------------------------+ > 9 | a | | | | |a |v |B ||v | |v |B | > 10 | a | | | | |a |v |B ||v | |v |B | > 11 | a | | | | |a |v |B ||v | |v |B | > 12 | a | | | | |a |v |B ||v | |v |B | > 13 | a | | | | |a |v |B ||v | |v |B | > 14 | a | | | | |a |v |B ||v | |v |B | > 15 | a | | | | |a |v |B ||v | |v |B | > 16 | a | | | | |a |v |B ||v | |v |B | > +---------------------------------------------------+ > 17 | a | | | | |a |v |v ||v | |v |v | > . > . > . > 80 | a | | | | |a |v |v ||v | |v |v | > +---------------------------------------------------+ > > (a=audio, v=video, F=FAS, B=BAS). > > We see that the video stream is split up over two channels. In > order to > cater to this, it seems we have to allow terminations to receive > media > from and send it to multiple physical endpoints. The two > approaches > outlined above can both be extended to allow this. Both extensions > will > lead to the introduction of logical names for terminations. In > the > first approach there will be one termination "containing" two > B-channels > on one side and three logical streams on the other. In the second > approach there will be three terminations, the one for the video > stream > referencing both B-channels, the ones for signalling and audio > referencing only channel 1. > > The second approach allows us to keep separate contexts for > different > media types. It is then easy to delete, for instance, the video > part of > a session (session used loosely to desribe the contexts for the > audio > and video). > > The first approach groups the streams coming from/going to one > user, > making it possible to remove a user from a context more easily. > > > Personally, I can't decide which approach I would prefer. How do > others > feel about these ideas? > > 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

2 1

TINA '99 in Hawaii mid April , last call for participation
by Martine.Lapierre＠ALCATEL.FR 01 Apr '99

01 Apr '99

Dear colleague, In this message is the text for the final call for participation for TINA'99. It is also accessible at http://www.tinac.com/tina99.html. I apologize if you received the TINA'99 information before, this is just a check that you were informed before the last chance for registration has arrived. The scientific committee expressed a gratitude for the excellence of the papers submitted, especially on VoIP and IN for IP. May I insist on the quality of the Panel of Wednesday afternoon where very senior people will express their views on the future of telecommunication networks: H. Aldermeshian AT&T T. Aoki NTT J. Craveur France Telecom E. Raubold Deutsche Telekom T. Rowbotham British Telecom If you are interested in attending, and desire to do so, I urge you to follow the instructions in the call. I look forward to seeing you in Hawaii. Martine Lapierre <martine.lapierre(a)alcatel.fr> TINA'99 Telecommunications Information Networking Architecture Conference 1999 Turtle Bay Resort, Oahu, Hawaii, USA - 12-15 April 1999 The Application of Distributed Computing Technologies to Telecommunications Solutions The Telecommunication Information Networking Architecture (TINA) Consortium invites you to attend the TINA'99 Conference on applications of state-of-the-art distributed computing technologies to problems of the globally converging telecommunications and computing domains. TINA'99 is an open international conference, with participation from researchers and developers in open networking technologies related to telecommunication and information systems. HOSTED BY: Hewlett-Packard Laboratories IN COOPERATION WITH: * IEEE Communications Society * Object Management Group SUPPORTED BY: * Hewlett-Packard Company * TINA Consortium CONFERENCE STRUCTURE AND PARTICIPATION TINA'99 consists of tutorials, keynote addresses, technical sessions, and demonstrations. The tutorials are on 12 April, with the keynote addresses and technical sessions occupying a single track on 13 April, and two tracks on 14 April and until noon on 15 April. A preliminary program is available for your perusal. (http://www.tinac.com/99/Conference/program.pdf) REGISTRATION To attend the conference, you must register for the conference and book accommodations with the conference hotel. The relevant forms are: * Registration Form (http://www.tinac.com/99/Conference/regform.html) * Hotel Information and Booking Form (http://www.tinac.com/99/Conference/regform.html) The registration includes admittance to the tutorials of your choice, the technical sessions, the reception, and the conference dinner. We also will accept American Express cards for the conference registration. There is still room for late registrants, and the hotel will continue to accept bookings at the preferred rate on a space available basis. If you are interested in attending, please register for the conference and book your accommodations as soon as possible! VENUE The Turtle Bay Hilton Resort is located on the north shore of the island of Oahu. Honolulu is located on the south shore of Oahu. A link to the resort's web site is available by following the Hotel Information and Booking Form link above. Transportation Airport to Turtle Bay - approximately 1 hour Hotel Shuttle - Reservations must be made by 3:30pm, Hawaii time, at least one day prior. Call Turtle Bay Hilton, Assistant Manager - 808/293-1286 x23. Credit card needed to confirm reservations. Shuttle Timetable Depart Honolulu 7:45am 8:45am 9:45am 10:45am 1:!5pm 4:45pm Intl. Arrive Turtle 8:45am 9:45am 10:45am 11:45am 2:15pm 5:45pm Bay Depart Turtle 9:00am 10:00am 11:00am 12:00pm 2:30pm 6:00pm Bay Arrive Honolulu 10:00am 11:00am 12:00pm 1:00pm 3:30pm 7:00pm Intl. Airport pickup outside Baggage Claim area of your Airline. Rates: Registered Guest per person $30.00 + 1.25 = $31.25 (USD) Non Guest per person $95.00 + 3.96 = $ 98.96 (USD) Child (1-5 years) registered $15.00 + .62 = $15.62 (USD) Child ( 1-5 years) non guest $47.50 + 1.98 = $ 49.48 (USD) Limo - Northshore Limousine - 808/293-1447 Cost - $114.11 - includes tax & tip (USD) Call ahead to make reservations Taxi Ride - Cost $85 - $115 (USD) ENQUIRIES If you require any other information, please contact us at +1-650-857-3377 or send e-mail to Renee_Coca(a)hpl.hp.com.

1 0

Re: Firewalls [was: H.320 gateways a MEG
by Sengodan Senthil NRC/Boston 01 Apr '99

01 Apr '99

Douglas, IMHO, I think that the issue comes down to trust. The SAs need to be so constructed that the trust model is satisfied. In case 3, where SA2 is an ESP SA between EP1-EP2: Such a deployment may be chosen when EP1 does not trust SG1 and EP2 does not trust SG2 to look inside the packet. The SPD present at EP1 would reflect the policy that currently exists in firewalls. The firewall functionality has essentially been distributed to the edge (EP1) in this case. If the SG is trusted - which is the case with most firewalls - then, the scenario in case 3 should probably not be chosen. An ESP SA can exist between SG1 and SG2. If there is a problem of snooping within the AD, then an ESP SA can be established between EP1 - SG1 and SG2-EP2 as well. - Senthil ---------- From: Mailing list for parties associ To: ITU-SG16 Subject: Re: Firewalls [was: H.320 gateways a MEGACO / ITU] Date: Thursday, April 01, 1999 3:08PM At 19:03 1999-03-31 -0800, Matt Holdrege wrote: >If you are using ESP, there are no worries. The endpoints unwrap the >original packet and process it as normal. The firewall doesn't know or care >about the original internal packet. In Melinda's case, and I think it applies to the megaco messages as well, if that pdu contains protocol addresses, and the firewall wants/needs to unblock them (but not translate them), it certainly does care. I think we are talking about firewalls that filter/block all but a few configured ports, and open others when genuine needs are detected. >But if we are talking about MEGACO and I originally thought we were, you >don't need to use ESP if you don't want to. For security's sake, you may >wish to use AH in which case the firewall will simply authenticate the >packet and pass it through without any worries. Assume for the moment that the MG lives behind a firewall, and the MGC is "out there", communicating on the well known and open port allocated to megaco. An RTP session needs to be opened, on a dynamically allocated port that the firewall is blocking. The session is to be made from another dynamically allocated port, on a different MG, somewhere "out there". For security reasons, the megaco protocol exchanges between the MGC and MG are encrypted, according to a security association between themselves. The firewall is seeing encrypted pdu's that it cannot examine for addresses. How will media flow to these blocked ports? I think that the other questions were similar, but the messages were Q.931 setup, or H.245 OLC and the firewall problem was the PER coding. It's worse with ESP/TLS than with PER, but it's still the same-ish problem. Using AH does not provide privacy. An eavesdropper can snoop dial strings, which can be sensitive. An eavesdropper can spot IP/port pairs, which it knows are going to be opened by the firewall, for targeting denial of service attacks. It would not be impossible to find ESP being used on megaco. >The only worries are if you are using NAT. And yes, the problem also arises with NAT, where the firewall also wants to _change_ the pdu. See: http://www.ietf.org/internet-drafts/draft-ietf-nat-protocol-complications-00 .txt :-) > >At 11:14 AM 4/1/99 +1000, Douglas Clowes wrote: >>Hi Matt, >> >>I've read 2401 (IPsec), 2402 (AH), and 2406 (ESP) before. I've also >>skimmed, but probably not understood, the ones on IKE and ISAKMP and OAKLEY >>too. I've just re-skimmed 2401/2/6 and still don't have the answer. >> >>Re-reading the postings, they're about H.323 proxies, call signalling, and >>H.245 - some people are talking about H.323 rather than megaco/H.gcp, and >>that's part of the problem: different threads by different people. >> >>My points are several, and relate to firewalls (as noted by the subject >>change). >> >>In a mode 3 security association: >>> 3. neither endpoint is the same -- The inner and outer >>> tunnels could each be either AH or ESP. >>> >>> Host 1 --- Security ---- Internet -- Security --- Host 2 >>> | Gwy 1 Gwy 2 | >>> | | | | >>> | --Security Assoc 1 (tunnel)- | >>> | | >>> -----------Security Association 2 (tunnel)----------- >> >>where Security Association 2 is ESP, how is SG1 or SG2 going to do packet >>filtering and port opening? >> >>Or, if SG1/SG2 is a single entity, as in Case 4: >>> ====================================================== >>> | | >>> |============================== | >>> || | | >>> || ---|----------------------|--- >>> || | | | | >>> H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* | >>> ^ | Intranet) | >>> | ------------------------------ >>> could be dialup admin. boundary (optional) >>> to PPP/ARA server >> >>or SG2, here, is "just" a firewall, instead of a Signalling Gateway. >> >>Assuming that the SA between H1 and H2 involves payload encryption, such as >>ESP, and is call signalling or H.245, how does SG2 cope with finding the >>IP/port pairs, even in a text based protocol? >> >>My interest extends beyond megaco/H.gcp, and includes Annex G. How do we >>handle this in the more general case? >> >>Douglas >> >>At 16:05 1999-03-31 -0800, Matt Holdrege wrote: >>>You can read RFC 2401 & 2402 to find out about IPsec and AH. And this >>>discussion is about MEGACO/H.GCP which is not the same as H.323. >> >> >> > >

1 0

Re: H.320 gateways a MEGACO / ITU
by Ami Amir 01 Apr '99

01 Apr '99

Melinda By transcoding I meant that specific information fields which contain identical information but are encoded differently need to be translated from one format to another. Ami -----Original Message----- From: Melinda Shore [SMTP:shore@ITHACA-VIENNASYS.COM] Sent: Wednesday, March 31, 1999 5:35 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: H.320 gateways a MEGACO / ITU There's another problem - the use of PER combined with protocol- embedded addresses greatly complicates operation through firewalls. Not that I'm a fan of text-based protocols - I absolutely am not. But PER-encoded signaling streams could force the use of firewall proxies, which has unfortunate performance implications. I'm not certain that I understand the point about transcoding - it's going to have to take place, anyway, whether the megaco protocol is text-based or not. At 11:14 AM 3/31/99 +0200, Ami Amir wrote: >There are many who feel that ASN.1 is too heavy and complex for simple >devices, and should be avoided. This was one of the major reasons for the >emergence of SIP. Melinda Shore Member of the Scientific Staff Nokia IP Telephony 127 West State Street Ithaca, New York 14850 +1 607 273 0724 x81 (office) +1 607 275 3610 (fax) +1 607 280 0010 (mobile) shore(a)ithaca-viennasys.com

1 0

Moneterey meeting report APC-1554
by Sakae OKUBO 01 Apr '99

01 Apr '99

Dear Q.12-14/16 experts, With completion of the liaison to SG8 (TD-39 revised), the report of the Monterey meeting (APC-1554) has also been completed. Please find the relevant files APC-1554b.zip and TD-39a.zip at the following directory of the PictureTel ftp site: ftp://standard.pictel.com/avc-site/9802_Mon or http://standard.pictel.com/ftp/avc-site/9802_Mon 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: Multimedia (was Re: Megaco Protocol - IETF/ITU conf call minu tes)
by Tom-PT Taylor 01 Apr '99

01 Apr '99

Single-medium contexts as a representaion scheme are orthogonal to the question of multimedia. Multimedia implies (a) multiple media types (b) coordination between them. If I have multiple contexts, each devoted to one medium, that satisfies (a). One suggestion on the call was to do that, then add a context attribute which linked together different contexts. This is a possible solution to (b). My personal feeling is that the single-medium context is a good direction to explore, because in the degenerate (audio-only) case it turns out simply. The open question, of course, is whether it introduces too many problems of coordination. I'm hoping to work through the two test cases I posed before the Minneapolis meeting to see. > -----Original Message----- > From: John Segers [SMTP:jsegers@LUCENT.COM] > Sent: Wednesday, March 31, 1999 7:11 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Multimedia (was Re: Megaco Protocol - IETF/ITU conf call > minutes) > > Mauricio, > > You are right that single medium contexts are simpler to reason about > services and call flows. But we must take care that we don't end up > with a protocol that cannot be extended to cover multimedia GWs. If > multimedia applications are within scope, the protocol document should > not contain a connection model that handles only audio. > > What do others think? Is multimedia in the scope of megaco/H.gcp? And > if so, is Paul's proposal general enough? Doesn't it lead to too much > overhead for single media GWs? I'd be interested to hear opinions. > > John Segers > > "Arango, Mauricio" wrote: > > > > Please disregard my previous message which by mistake I sent without > erasing > > editing. Apologies to the list members. > > > > Paul, > > > > I understand the rationale for your multiple media context. My > preference is > > the single medium context because it seems simpler for thinking about > > services and call flows. This seems to require more discussion. I > suggest we > > advance the protocol as proposed with single-medium contexts and revisit > > this later if necessary. > > > > Mauricio > > > > > -----Original Message----- > > > From: Paul Sijben [mailto:sijben@lucent.com] > > > Sent: Tuesday, March 30, 1999 2:45 PM > > > To: Arango, Mauricio > > > Cc: 'Greene, Nancy-M [CAR:5N10:EXCH]'; 'ITU-SG16(a)mailbag.intel.com'; > > > 'megaco(a)baynetworks.com' > > > Subject: Multimedia (was Re: Megaco Protocol - IETF/ITU conf call > > > minutes) > > > > > > > > > Mauricio, > > > > > > you write: > > > > It could be good idea to have some entity that ties > > > together multiple > > > > contexts, this was our experience in the Touring Machine > > > and we referred to > > > > it as "session". However, it may not be necessary for the > > > most common audio > > > > only operations, and for the sake of simplicity it may be > > > better to leave it > > > > as an option. > > > > > > I think you are absolutely right. We have been doing some > > > work on that and > > > have come up with the following which seems like a sensible > > > extention to > > > the H.gcp/MEGACOP work: > > > > > > Problem definition: > > > For multimedia calls you will have multiple media streams > > > representing > > > each of the users. these streams need to be appropriately > > > processed (maybe > > > mixed or something more clever) and synchronised. > > > > > > The current definition in the MEGACO I-D specifies that each > > > context only > > > has one type of medium. This makes the logical grouping of > > > terminations > > > belonging to one user difficult, creates issues with synchronisation > > > between media. It also makes it difficult to remove one user > > > or an entire > > > conference in one command. > > > > > > We have gone over several possible solutions, you can group > > > terminations > > > per user, and/or per medium and/or make some kind of links between > > > terminations or contexts which signify the synchronisation. > > > > > > What seems like a workable model is to allow multiple media > > > in one context > > > and have a matrix binding the terminations to the right > > > medium/user. So you > > > would get something like: > > > > > > context > > > > > > medium1 | M2 | ....| Mn > > > ------------------------------ > > > user1 | x | | | x > > > user2 | | x | | x > > > .......... > > > usern | x | x > > > where x==termination > > > > > > such a matrix could be a "scap paper" used by the MGW and MC > > > to keep track > > > of to which user and which medium each termination belongs. > > > One could set a > > > flag on terminations that one wants to synchronise. > > > > > > Naturally you would not need this for simple voice gateways so the > > > extentions needed to the protocol for this youl be optional. > > > > > > The extentions would look like: > > > > > > Commands: > > > We now have a command structure that states: > > > > > > ContextID > > > *Command(TerminationID ....) > > > > > > we would get: > > > > > > ContextID > > > [UserID] > > > *command( [MediaID] Termination ID....) > > > > > > so for example: > > > ContextID=3 > > > UserID=2 > > > add (MediaID=Video3, TerminationID=RTP:32424, ....) > > > modify (MediaID=Video3, TerminationID=*, SychWith:MediaID=Audio2) > > > > > > etc. > > > > > > A context could have the following properties: > > > - mode (unidirectional, bidirectional, mix, choose...) > > > - maxNumberOfUsers (e.g. 3) > > > - maxNumberOfMedia (e.g. 1 for a simple voice gateway) > > > > > > This extention would allow the removal of one medium or one > > > user from a > > > conference but not hamper "simple" operations. > > > > > > Paul > > > > > > "Arango, Mauricio" wrote: > > > > > > > > Nancy, > > > > > > > > Thanks for preparing the minutes. > > > > > > > > > > > > > > b. Raised by Mauricio Arango: you may want to be able to > > > > > create a context > > > > > with parameters before adding any terminations to it - (e.g. > > > > > turing machine) > > > > > > > > I want to clarify that I was not referring to Alan Turing's > > > grand work but > > > > to something colleagues and I did some years ago in > > > multimedia call control, > > > > called "Touring Machine". This effort developed a > > > connection model similar > > > > to the one in MEGACO's protocol and could be worth keeping > > > in mind as > > > > previous experience to help this effort. > > > > > > > > The January 1993 of the Communications of the ACM has an > > > article on the > > > > Touring Machine. Following is an excerpt desribing its > > > connection model > > > > (page 71): > > > > > > > > "The logical topology of a session is specified as a set of > > > typed connectors > > > > (see Figure 2). A connector represents a multiway transport > > > connection among > > > > endpoints (logical ports). A connection is an abstraction of a > > > > communications bridge, including point-to-point (two way) as well as > > > > multipoint connections. Since bridging is a medium-specific > > > operation, > > > > connectors are typed by medium. A session may have one or > > > more connectors > > > > per medium, with souce and sink endpoints from > > > participating clients. An > > > > endpoint represents a connector termination point. Endpoints are > > > > distinguished by medium, direction of flow, and the client > > > receiving or > > > > providing transport." > > > > > > > > In the above excerpt a "connector" is equivalent to > > > MEGACO's context and an > > > > "endpoint" is equivalent to MEGACO's termination. > > > > > > > > > c. Raised by a few people: we need to see whether we need a > > > > > meta definition > > > > > of a "call" in the MG, so that the MG can link together > > > > > related contexts. > > > > > May be needed for lipsynch between a call's video context and > > > > > its audio > > > > > context. Instead of introducing a callId, this could be done using > > > > > parameters on each context referring to the other one. > > > > > Benefit of a callId > > > > > is that the MGC can bring down the entire call by just > > > > > referring to the > > > > > callId. (Note: "call" may be the wrong word - if we need it, > > > > > let's try to > > > > > invent a new name). > > > > > > > > > > > > > It could be good idea to have some entity that ties > > > together multiple > > > > contexts, this was our experience in the Touring Machine > > > and we referred to > > > > it as "session". However, it may not be necessary for the > > > most common audio > > > > only operations, and for the sake of simplicity it may be > > > better to leave it > > > > as an option. > > > > > > > > Regards, > > > > > > > > Mauricio Arango > > > > > > > > > -----Original Message----- > > > > > From: Greene, Nancy-M [CAR:5N10:EXCH] > > > > > [mailto:ngreene@americasm01.nt.com] > > > > > Sent: Monday, March 29, 1999 8:54 PM > > > > > To: 'ITU-SG16(a)mailbag.intel.com'; 'megaco(a)baynetworks.com' > > > > > Subject: Megaco Protocol - IETF/ITU conf call minutes > > > > > > > > > > > > > > > Here are the minutes from the call today. Please email me any > > > > > corrections. I > > > > > tried to pair comments made with the person that made them - > > > > > I may have made > > > > > some errors, and I know I missed the names of some of the > > > > > people commenting. > > > > > > > > > > > > > > > > > > > > Nancy (ngreene(a)nortelnetworks.com) > > > > > ----------------------------------------------------------- > > > > > > > > > > Megaco Protocol presentation to IETF megaco and ITU SG16 > > > participants > > > > > March 29/99 10am-12pm EST > > > > > ================================================= > > > > > > > > > > Present: The number of ports being used went as high as 47, > > > > > and was about 45 > > > > > on average. Number of participants was higher since a number > > > > > of people were > > > > > sharing ports. > > > > > > > > > > Chair of the call: Glen Freundlich (ggf(a)lucent.com) > > > > > Minutes: taken by Nancy Greene (ngreene(a)nortelnetworks.com) > > > > > > > > > > NOTE: In keeping with IETF and ITU procedures, the audio call > > > > > cannot make > > > > > binding decisions. It is a tool for the chairs and > > > editors, and the > > > > > participants of both the IETF and ITU working groups, to > > > > > gauge support for > > > > > the protocol, and to raise issues with the protocol. Issues > > > > > may be raised in > > > > > either an audio call, or on the mailing list > > > > > (megaco(a)baynetworks.com) These > > > > > minutes are going to both the Megaco and ITU-SG16 mailing lists. > > > > > > > > > > Meeting summary: > > > > > -------------------------- > > > > > Glen Freundlich summed up results of the meeting. The goal of > > > > > the meeting > > > > > was two fold: > > > > > 1) it was the first opportunity for people to look at the > > > > > output from the > > > > > Megaco protocol design/drafting group. > > > > > 2) it was an opportunity for people to pose questions on > > > the draft. > > > > > > > > > > He saw no opposition to the connection model proposed in the > > > > > Megaco protocol > > > > > I-D > > > > > (ftp://www.ietf.org/internet-drafts/draft-ietf-megaco-protocol > > > > > -00.txt). > > > > > To date, the Megaco protocol I-D has been run through audio > > > > > call scenarios > > > > > for 3-way call, for call waiting, ... However, it needs to be > > > > > tested with > > > > > multimedia scenarios. Any input in this area is appreciated. > > > > > > > > > > Because there seems to be agreement on the connection model, > > > > > Bryan Hill, the > > > > > H.gcp editor, will start pulling related sections from the > > > > > Megaco protocol > > > > > I-D into H.gcp. > > > > > > > > > > Glen will hold another audio call next week to see where we > > > > > stand, and to > > > > > look towards adding more sections to H.gcp from the Megaco > > > > > protocol I-D. > > > > > > > > > > For the ITU-T SG16 May meeting, H.gcp needs to contain: > > > > > - a connection model > > > > > - a set of commands > > > > > - a start on parameters for those commands > > > > > - generic syntax > > > > > - and a list of issues to resolve. > > > > > > > > > > > > > > > Protocol timetable: > > > > > -------------------------- > > > > > IETF Megaco: > > > > > - Proposed Standard by summer/99 > > > > > - interoperability testing in fall/99 > > > > > - Draft Standard in Feb/2000 > > > > > > > > > > This matches up closely with the ITU-T SG16 schedule: > > > > > - planning to get H.gcp determined in May/99 > > > > > - planning to get H.gcp decided in Feb/2000 > > > > > > > > > > IETF/ITU collaboration: > > > > > ------------------------------- > > > > > Question raised: will the two protocols be identical? > > > > > > > > > > Tom Taylor proposes two options: > > > > > 1) SG16 and Megaco completely agree on the protocol > > > > > requirements. If this is > > > > > the case, the protocol will be identical > > > > > > > > > > 2) Each group has some requirements that are different from > > > > > the other group. > > > > > In this case, there would be agreement on a core > > > protocol, and then > > > > > additional parts would be defined by each group. > > > > > > > > > > BUT how to do this in practice? Tom said that if a huge > > > > > roadblock comes up > > > > > again, we would form a new design team to work out a solution. > > > > > > > > > > Tom asked whether the group on the call agreed that the > > > > > Megaco protocol I-D > > > > > was a reasonable basis for H.gcp. Feeling was that it is, but > > > > > that we need > > > > > to do multimedia call walkthroughs. Mike Buckley had some > > > > > concern about the > > > > > definition of a context, but thought that the basic model > > > is workable. > > > > > Mauricio Arango thought it was a good model for multimedia. > > > > > Ami Amir raised > > > > > issue about associating contexts. Glen asked the H.320 > > > > > experts to look at > > > > > the protocol and see if we need to modify the connection model. > > > > > > > > > > > > > > > Next audio call: > > > > > ---------------------- > > > > > Probably next Thursday April 8/99, same time. Confirmation of > > > > > date & time > > > > > and the call details will be out later this week. > > > > > > > > > > > > > > > Use of mailing lists: > > > > > --------------------------- > > > > > It was agreed that we would try to keep all technical > > > > > discussion of the > > > > > Megaco protocol on the megaco(a)baynetworks.com mailing list. > > > > > > > > > > Invitations to audio calls, and audio call minutes will be > > > > > sent to both the > > > > > megaco(a)baynetworks.com and to the ITU-SG16(a)mailbag.intel.com > > > > > mailing lists. > > > > > > > > > > Tom Taylor took the action of posting to each list, how to > > > > > join the other > > > > > one. > > > > > > > > > > Detailed minutes: > > > > > ------------------------ > > > > > Brian Rosen presented the Megaco protocol draft > > > > > (ftp://www.ietf.org/internet-drafts/draft-ietf-megaco-protocol > > > > > -00.txt). He > > > > > first noted that this draft is open for discussion. It is not > > > > > cast in stone. > > > > > If changes need to be made to any part, they will be > > > made, if they are > > > > > deemed necessary to satisfy the requirements of the protocol, > > > > > and agreed to > > > > > by the group. > > > > > > > > > > 1. New connection model > > > > > - concept of a termination - have permanent (e.g. DS0) and > > > > > ephemeral (e.g. > > > > > RTP port) terminations > > > > > - a termination is named with a terminationId, this name can > > > > > have wildcards, > > > > > for example to allow the MG to choose the actual physical > > > > > termination, or to > > > > > request notification of an event that occurs on any DS0 > > > > > - concept of a context - can add, subtract, modify > > > terminations in a > > > > > context. A context is created when the first termination is > > > > > added to it, and > > > > > goes away when the last termination is subtracted from it. > > > > > - a context can have parameters associated with it - for > > > > > example, a video > > > > > mixing context may have parameters to describe how the video > > > > > is to be mixed > > > > > - mosaic, or current speaker/last speaker, ... > > > > > - a termination class defines parameters on a typical > > > > > termination - e.g. DS0 > > > > > Termination Class, RTP Termination Class > > > > > - Signals can be attached to a termination class, events can > > > > > occur at a > > > > > termination class, and the MGC can specify which ones it > > > wants to be > > > > > notified about. > > > > > - packages define signals and events > > > > > - a termination class can have more than one package that > > > apply to it > > > > > - event naming structure allows package name to be put in > > > > > front of the event > > > > > name > > > > > - question: how do you apply a call waiting tone? - answer - > > > > > it is a signal > > > > > that you apply to a termination > > > > > > > > > > 1.1 Proposed Changes and Issues: > > > > > a. Tom Taylor proposed a more general definition for > > > context: every > > > > > termination in a context has connectivity with all other > > > > > terminations in the > > > > > context. > > > > > > > > > > b. Raised by Mauricio Arango: you may want to be able to > > > > > create a context > > > > > with parameters before adding any terminations to it - (e.g. > > > > > turing machine) > > > > > - may want to mark a context with the max # of terminations > > > > > at creation > > > > > time. - BUT this may bring lack of flexibility - may be > > > > > better to let the MG > > > > > decide, as new terminations are added to a context, whether > > > > > it is able to > > > > > mix them in. For example, instead of marking a context with > > > > > one particular > > > > > type of codec, it is more flexible to let the MG decide what > > > > > transcoding > > > > > needs to be done in a context as a function of the types of > > > > > terminations > > > > > added to it. > > > > > > > > > > c. Raised by a few people: we need to see whether we need a > > > > > meta definition > > > > > of a "call" in the MG, so that the MG can link together > > > > > related contexts. > > > > > May be needed for lipsynch between a call's video context and > > > > > its audio > > > > > context. Instead of introducing a callId, this could be done using > > > > > parameters on each context referring to the other one. > > > > > Benefit of a callId > > > > > is that the MGC can bring down the entire call by just > > > > > referring to the > > > > > callId. (Note: "call" may be the wrong word - if we need it, > > > > > let's try to > > > > > invent a new name). > > > > > > > > > > d. Raised by Steve Davies: with H.320, the MG has one > > > > > physical termination > > > > > with audio, video and data on it - can a termination be in > > > > > more than one > > > > > context? no - so need to separate the different media out of > > > > > this physical > > > > > termination before creating the contexts. > > > > > > > > > > e. Raised by Tom Taylor: need to see whether it is > > > feasible to have > > > > > decomposed H.320 gateways - if it is necessary (people say > > > > > yes), then need > > > > > to be sure the Megaco protocol can handle it. > > > > > > > > > > > > > > > 2. Commands > > > > > - grouped into commands within an action per context, and > > > one or more > > > > > actions are grouped into a transaction. Transaction is > > > all or nothing. > > > > > - Add, Modify, Subtract each can contain local and remote > > > terminiation > > > > > descriptors, signalling descriptor, an events descriptor, and > > > > > a digit map > > > > > descriptor > > > > > - question on how to change an event description for a > > > > > termination - answer: > > > > > use Modify - can do it within a context, or outside a context > > > > > - if it is > > > > > outside the context (i.e. using the NULL context), then that > > > > > is how you > > > > > change the default parameters for that termination. > > > > > - MGCP's NotificationRequest is now covered in Modify > > > > > > > > > > 3. Multimedia and Contexts and Terminations > > > > > - a termination only belongs to one context > > > > > - for multimedia, there is one context per media type > > > > > - just as you have separate RTP flows for different media > > > > > types, you have > > > > > separate contexts. > > > > > > > > > > 3.1 Issues > > > > > a. Paul Sijben noted that when you try to use the Megaco > > > protocol with > > > > > H.320, there may be problems with the model - Paul will bring > > > > > these up on > > > > > the mailing list. > > > > > > > > > > Also, see Issue c in 1.1 above. > > > > > > > > > > 4. H.245 & SDP > > > > > - Tom Taylor explained that H.245 has at least 2 purposes: 1) > > > > > for capability > > > > > negotiation, and 2) for specification of open logical > > > > > channel. The scope of > > > > > the Megaco protocol is 2). Capability negotiation may use > > > > > H.245 between > > > > > MGCs, but the Megaco protocol is between MGC and MG. SDP may > > > > > be good enough > > > > > to be used between the MGC and the MG. Discussion still open > > > > > here. Need to > > > > > allow for an environment where H.245 may not be involved. > > > > > - with H.263 - H.245 provides a tag to link together 2 RTP > > > > > streams - need to > > > > > be able to carry this tag from the MGC to the MG. > > > > > > > > > > 5. underspecifying termination descriptors > > > > > - can be used as a way to tell the MG to use default > > > values for the > > > > > termination > > > > > - a termination learns its default values at MG boot-up time > > > > > - MGC can change these values using Modify with context > > > set to NULL. > > > > > > > > > > 6. underspecifying terminationIds > > > > > - provides a way of setting default parameters for a T1 > > > for example > > > > > > > > > > 7. Case: two audio contexts - in different MGs, and in the same MG > > > > > - can the connection model handle this? Yes > > > > > - protocol should need to keep track of where resources are. > > > > > - it is up to the MGC to know what contexts are associated > > > > > with a call. > > > > > > > > > > 8. overview of Audit, Notify, ServiceChange > > > > > - ServiceChange - MG can use it upon reboot, to register > > > > > itself with an MGC > > > > > - MG knows which MGC to send this msg to from some method > > > > > outside the scope > > > > > of this protocol (pre-provisioned, for example). > > > > > - MGC learns capabilities of MG using Audit. - can learn codecs > > > > > > > > > > 8.1 Issue > > > > > - need a way for MGC to learn the QUANTITY of codecs an MG has! > > > > > > > > > > 9. overview of Security > > > > > - this is security between an MGC and an MG > > > > > - interim method is specified for when an MG does not have IPSEC > > > > > > > > > > 10. Question on scope of the protocol > > > > > - check the requirements draft: > > > > > ftp://standards.nortelnetworks.com/megaco/docs/minn99 > > > > > - Steve Davies brought up point that some aspects of the > > > > > Megaco protocol > > > > > overlap with Policy server protocol proposals. > > > > > > > > > > 11. Can MG do coded renegotiation? > > > > > - David Featherstone asked if an MG can negotiate use of a > > > > > new codec on its > > > > > own > > > > > - Brian Rosen answered that with AAL2 profiles, the MG can > > > > > > > > > > Issue: > > > > > a. MGC may need to be involved - for example if the Quality > > > > > goes down too > > > > > low, call may no longer be billable. Solution - create an > > > > > event to notify > > > > > the MGC for this case. > > > > > > > > > > 12. How does the MGC find out RTP interfaces? > > > > > - should be able to do this using Audit in the NULL context. > > > > > > > > > > 13. IVR - still open for discussion > > > > > - view IVR as a termination > > > > > - issue is how much signalling effort do you need to add to > > > > > the protocol? > > > > > - simply playing msgs is ok - they just look like events > > > > > - problem is when you want to put time and money values into > > > > > it for example, > > > > > you have x minutes left on your calling card. - this may be > > > > > out of the scope > > > > > of the Megaco protocol > > > > > > > > > > 14. QoS reservation > > > > > - needs more discussion > > > > > > > > > > ****see Meeting summary above for audio call conclusions. > > > > > > > > > > end of minutes. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > ------------ > > > > > Nancy M. Greene > > > > > Internet & Service Provider Networks, Nortel Networks > > > > > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > > > > > > > > > > > -- > > > Paul Sijben Telno:+ 31 35 687 4774 Fax:+31 35 687 5954 > > > Lucent Technologies Home telno: +31 33 4557522 > > > Forward Looking Work e-mail: sijben(a)lucent.com > > > Huizen, The Netherlands internal http://hzsgp68.nl.lucent.com/ > > > > > -- > 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

3 2

Re: H.320 gateways a MEGACO / ITU
by Flemming Andreasen 01 Apr '99

01 Apr '99

It really depends on the type of firewall and the policies associated with it. However, in general, whenever you deal with protocols that include information about one stream in another stream (e.g. RTP in H.245 or SDP, or H.245 in H.225.0) you have a need to peak inside the stream (and thereby be able to decode it) to determine what to let through and not. Regards Flemming Andreasen Matt Holdrege <matt(a)ASCEND.COM> on 03/31/99 10:57:14 AM Please respond to Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.cps.intel.com> To: ITU-SG16(a)mailbag.cps.intel.com cc: (bcc: Flemming Andreasen/Bellcore) Subject: Re: H.320 gateways a MEGACO / ITU Such as? In it's simplest form, a firewall is simply a filter. You can add on IPsec functionality and other things, but that wouldn't affect a stream of PER data. At 10:50 AM 3/31/99 -0500, Melinda Shore wrote: >Well, it depends. You've still got the problem of picking up >any dynamically-assigned/allocated information, NAT or no. > >Melinda > >At 07:31 AM 3/31/99 -0800, Matt Holdrege wrote: >>To be more accurate, PER may not work fine through a NAT function. If your >>firewall doesn't do NAT, then PER should have no problems. > >Melinda Shore >Member of the Scientific Staff >Nokia IP Telephony >127 West State Street >Ithaca, New York 14850 >+1 607 273 0724 x81 (office) >+1 607 275 3610 (fax) >+1 607 280 0010 (mobile) >shore(a)ithaca-viennasys.com >

5 14

Re: Latest implementers guide?
by Jim Hirni 31 Mar '99

31 Mar '99

Oh no, I can't believe I did that. Please accept my apologies for my carelessness. I promise not to do it again... Regards, Jim Hirni ___________________________________________________ PakNetX, Inc. jhirni(a)paknetx.com 11 Red Roof Lane Tel: 603-890-6616 x204 Salem, NH 03079 Fax: 603-870-9395 www.paknetx.com "If you're not the lead dog, the view never changes" -----Original Message----- From: Jim Hirni [mailto:jhirni@PAKNETX.COM] Sent: Wednesday, March 31, 1999 5:04 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Latest implementers guide? Jim, It looks like you are in Boston now. When are you going to put something about what you are doing on your web page so we can tell what you are up to? jth -----Original Message----- From: Jim Toga [mailto:jim.toga@METATEL.COM] Sent: Wednesday, March 31, 1999 9:51 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Latest implementers guide? Jan, It has not been completed yet. I hope to finish it in the near future. I will be posting it to the list when I do. Regards, jimt. At 02:35 PM 3/31/99 , you wrote: >Where can I find the latest implementers guide? > >Is it updated updated according to the Monterey meeting yet? > >/Regards > Jan Holm Ericsson Telecom AB MetaTel - Boston, MA mailto:jim.toga@metatel.com +1-781-891-9000 PGP keyID E746 1CE4 CEC0 C91E 7190 65CA 70B1 B1D2 6A1E A2B7

1 0

Re: Latest implementers guide?
by Mike Ely 31 Mar '99

31 Mar '99

I like your reply... -----Original Message----- From: Jim Hirni [mailto:jhirni@PAKNETX.COM] Sent: Wednesday, March 31, 1999 5:04 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Latest implementers guide? Jim, It looks like you are in Boston now. When are you going to put something about what you are doing on your web page so we can tell what you are up to? jth -----Original Message----- From: Jim Toga [mailto:jim.toga@METATEL.COM] Sent: Wednesday, March 31, 1999 9:51 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Latest implementers guide? Jan, It has not been completed yet. I hope to finish it in the near future. I will be posting it to the list when I do. Regards, jimt. At 02:35 PM 3/31/99 , you wrote: >Where can I find the latest implementers guide? > >Is it updated updated according to the Monterey meeting yet? > >/Regards > Jan Holm Ericsson Telecom AB MetaTel - Boston, MA mailto:jim.toga@metatel.com +1-781-891-9000 PGP keyID E746 1CE4 CEC0 C91E 7190 65CA 70B1 B1D2 6A1E A2B7

1 0

Re: Latest implementers guide?
by Jim Hirni 31 Mar '99

31 Mar '99

Jim, It looks like you are in Boston now. When are you going to put something about what you are doing on your web page so we can tell what you are up to? jth -----Original Message----- From: Jim Toga [mailto:jim.toga@METATEL.COM] Sent: Wednesday, March 31, 1999 9:51 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Latest implementers guide? Jan, It has not been completed yet. I hope to finish it in the near future. I will be posting it to the list when I do. Regards, jimt. At 02:35 PM 3/31/99 , you wrote: >Where can I find the latest implementers guide? > >Is it updated updated according to the Monterey meeting yet? > >/Regards > Jan Holm Ericsson Telecom AB MetaTel - Boston, MA mailto:jim.toga@metatel.com +1-781-891-9000 PGP keyID E746 1CE4 CEC0 C91E 7190 65CA 70B1 B1D2 6A1E A2B7

1 0

Re: H.320 gateways a MEGACO / ITU
by Flemming Andreasen 31 Mar '99

31 Mar '99

No disagreement on the applicability of IPSEC, however let's not equate IPSEC, firewalls and a certain policy associated with deployment of a firewall in given environment. In any case, Intel once produced an excellent paper on the H.323 firewall topic which interested parties can access at http://support.intel.com/support/videophone/trial21/H323_WPR.HTM Regards Flemming Matt Holdrege <matt(a)ascend.com> on 03/31/99 01:06:17 PM To: Flemming Andreasen <fandreas(a)TELCORDIA.COM> cc: ITU-SG16(a)mailbag.cps.intel.com (bcc: Flemming Andreasen/Bellcore) Subject: Re: H.320 gateways a MEGACO / ITU I don't believe that is the case, especially with MEGACO/H.GCP or SIGTRAN. The main reason for using Firewalls in these architectures is to make sure that unauthorized sources do not send info through the firewall. Also to make sure that even the authorized sources only send the proper information through the firewall. As has been discussed on the MEGACO list, the best way to authenticate and authorize is to use IPsec. This has absolutely nothing to do with inspecting the internal payload of the packet. The only functions that can fully inspect the internals of the packet are the MG and MGC. Not the firewall. At 11:38 AM 3/31/99 -0500, Flemming Andreasen wrote: >It really depends on the type of firewall and the policies associated with >it. However, in general, whenever you deal with protocols that include >information about one stream in another stream (e.g. RTP in H.245 or SDP, >or H.245 in H.225.0) you have a need to peak inside the stream (and thereby >be able to decode it) to determine what to let through and not. > > >Regards > > Flemming Andreasen > > > > > > >Matt Holdrege <matt(a)ASCEND.COM> on 03/31/99 10:57:14 AM > >Please respond to Mailing list for parties associated with ITU-T Study > Group 16 <ITU-SG16(a)mailbag.cps.intel.com> > >To: ITU-SG16(a)mailbag.cps.intel.com >cc: (bcc: Flemming Andreasen/Bellcore) >Subject: Re: H.320 gateways a MEGACO / ITU > > > > >Such as? > >In it's simplest form, a firewall is simply a filter. You can add on IPsec >functionality and other things, but that wouldn't affect a stream of PER >data. > > >At 10:50 AM 3/31/99 -0500, Melinda Shore wrote: >>Well, it depends. You've still got the problem of picking up >>any dynamically-assigned/allocated information, NAT or no. >> >>Melinda >> >>At 07:31 AM 3/31/99 -0800, Matt Holdrege wrote: >>>To be more accurate, PER may not work fine through a NAT function. If >your >>>firewall doesn't do NAT, then PER should have no problems. >> >>Melinda Shore >>Member of the Scientific Staff >>Nokia IP Telephony >>127 West State Street >>Ithaca, New York 14850 >>+1 607 273 0724 x81 (office) >>+1 607 275 3610 (fax) >>+1 607 280 0010 (mobile) >>shore(a)ithaca-viennasys.com >> >

1 0

Re: Megaco Protocol - IETF/ITU conf call minutes
by gilles.fayad＠CONEXANT.COM 31 Mar '99

31 Mar '99

I have been only aware of the Megaco through th ITU-SG16 list, and would like to stay current on Megaco. Anyone kind enough to indicate what are the pointers to the list server? Best regards, Gilles Fayad Rex Coldren <coldrenr(a)AGCS.COM> on 03/31/99 07:54:31 AM Please respond to Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.cps.intel.com> To: ITU-SG16(a)mailbag.cps.intel.com cc: (bcc: Gilles G Fayad/RSS/Rockwell) Subject: Re: Megaco Protocol - IETF/ITU conf call minutes Chip, We DID agree to use the MEGACO list instead of SG16 and should start to do so. I am guessing that those who are posting to both have been waiting to see an official announcement on the SG16 list stating that this is the policy. I am expecting that to come from Tom Taylor or Bryan Hill. Hope I didn't miss it if it already came through. Rex Chip Sharp wrote: > On the call, I believe we agreed to hold technical discussions on the > megaco mail list. Cross-Posting doubles the traffic for those who are > subscribed to both lists. Could we start using the megaco list now? > > To Subscribe: majordomo(a)baynetworks.com > In Body: subscribe megaco > Archive: ftp://standards.nortelnetworks.com/megaco > General Discussion:megaco@baynetworks.com > > Thanks, > Chip > -------------------------------------------------- > Chip Sharp voice: +1 (919) 851-2085 > Cisco Systems Consulting Eng. - Telco > Reality - Love it or Leave it. > --------------------------------------------------

1 0

Re: Megaco Protocol - IETF/ITU conf call minutes
by Arango, Mauricio 31 Mar '99

31 Mar '99

Nancy, Thanks for preparing the minutes. > > b. Raised by Mauricio Arango: you may want to be able to > create a context > with parameters before adding any terminations to it - (e.g. > turing machine) I want to clarify that I was not referring to Alan Turing's grand work but to something colleagues and I did some years ago in multimedia call control, called "Touring Machine". This effort developed a connection model similar to the one in MEGACO's protocol and could be worth keeping in mind as previous experience to help this effort. The January 1993 of the Communications of the ACM has an article on the Touring Machine. Following is an excerpt desribing its connection model (page 71): "The logical topology of a session is specified as a set of typed connectors (see Figure 2). A connector represents a multiway transport connection among endpoints (logical ports). A connection is an abstraction of a communications bridge, including point-to-point (two way) as well as multipoint connections. Since bridging is a medium-specific operation, connectors are typed by medium. A session may have one or more connectors per medium, with souce and sink endpoints from participating clients. An endpoint represents a connector termination point. Endpoints are distinguished by medium, direction of flow, and the client receiving or providing transport." In the above excerpt a "connector" is equivalent to MEGACO's context and an "endpoint" is equivalent to MEGACO's termination. > c. Raised by a few people: we need to see whether we need a > meta definition > of a "call" in the MG, so that the MG can link together > related contexts. > May be needed for lipsynch between a call's video context and > its audio > context. Instead of introducing a callId, this could be done using > parameters on each context referring to the other one. > Benefit of a callId > is that the MGC can bring down the entire call by just > referring to the > callId. (Note: "call" may be the wrong word - if we need it, > let's try to > invent a new name). > It could be good idea to have some entity that ties together multiple contexts, this was our experience in the Touring Machine and we referred to it as "session". However, it may not be necessary for the most common audio only operations, and for the sake of simplicity it may be better to leave it as an option. Regards, Mauricio Arango > -----Original Message----- > From: Greene, Nancy-M [CAR:5N10:EXCH] > [mailto:ngreene@americasm01.nt.com] > Sent: Monday, March 29, 1999 8:54 PM > To: 'ITU-SG16(a)mailbag.intel.com'; 'megaco(a)baynetworks.com' > Subject: Megaco Protocol - IETF/ITU conf call minutes > > > Here are the minutes from the call today. Please email me any > corrections. I > tried to pair comments made with the person that made them - > I may have made > some errors, and I know I missed the names of some of the > people commenting. > > > > Nancy (ngreene(a)nortelnetworks.com) > ----------------------------------------------------------- > > Megaco Protocol presentation to IETF megaco and ITU SG16 participants > March 29/99 10am-12pm EST > ================================================= > > Present: The number of ports being used went as high as 47, > and was about 45 > on average. Number of participants was higher since a number > of people were > sharing ports. > > Chair of the call: Glen Freundlich (ggf(a)lucent.com) > Minutes: taken by Nancy Greene (ngreene(a)nortelnetworks.com) > > NOTE: In keeping with IETF and ITU procedures, the audio call > cannot make > binding decisions. It is a tool for the chairs and editors, and the > participants of both the IETF and ITU working groups, to > gauge support for > the protocol, and to raise issues with the protocol. Issues > may be raised in > either an audio call, or on the mailing list > (megaco(a)baynetworks.com) These > minutes are going to both the Megaco and ITU-SG16 mailing lists. > > Meeting summary: > -------------------------- > Glen Freundlich summed up results of the meeting. The goal of > the meeting > was two fold: > 1) it was the first opportunity for people to look at the > output from the > Megaco protocol design/drafting group. > 2) it was an opportunity for people to pose questions on the draft. > > He saw no opposition to the connection model proposed in the > Megaco protocol > I-D > (ftp://www.ietf.org/internet-drafts/draft-ietf-megaco-protocol > -00.txt). > To date, the Megaco protocol I-D has been run through audio > call scenarios > for 3-way call, for call waiting, ... However, it needs to be > tested with > multimedia scenarios. Any input in this area is appreciated. > > Because there seems to be agreement on the connection model, > Bryan Hill, the > H.gcp editor, will start pulling related sections from the > Megaco protocol > I-D into H.gcp. > > Glen will hold another audio call next week to see where we > stand, and to > look towards adding more sections to H.gcp from the Megaco > protocol I-D. > > For the ITU-T SG16 May meeting, H.gcp needs to contain: > - a connection model > - a set of commands > - a start on parameters for those commands > - generic syntax > - and a list of issues to resolve. > > > Protocol timetable: > -------------------------- > IETF Megaco: > - Proposed Standard by summer/99 > - interoperability testing in fall/99 > - Draft Standard in Feb/2000 > > This matches up closely with the ITU-T SG16 schedule: > - planning to get H.gcp determined in May/99 > - planning to get H.gcp decided in Feb/2000 > > IETF/ITU collaboration: > ------------------------------- > Question raised: will the two protocols be identical? > > Tom Taylor proposes two options: > 1) SG16 and Megaco completely agree on the protocol > requirements. If this is > the case, the protocol will be identical > > 2) Each group has some requirements that are different from > the other group. > In this case, there would be agreement on a core protocol, and then > additional parts would be defined by each group. > > BUT how to do this in practice? Tom said that if a huge > roadblock comes up > again, we would form a new design team to work out a solution. > > Tom asked whether the group on the call agreed that the > Megaco protocol I-D > was a reasonable basis for H.gcp. Feeling was that it is, but > that we need > to do multimedia call walkthroughs. Mike Buckley had some > concern about the > definition of a context, but thought that the basic model is workable. > Mauricio Arango thought it was a good model for multimedia. > Ami Amir raised > issue about associating contexts. Glen asked the H.320 > experts to look at > the protocol and see if we need to modify the connection model. > > > Next audio call: > ---------------------- > Probably next Thursday April 8/99, same time. Confirmation of > date & time > and the call details will be out later this week. > > > Use of mailing lists: > --------------------------- > It was agreed that we would try to keep all technical > discussion of the > Megaco protocol on the megaco(a)baynetworks.com mailing list. > > Invitations to audio calls, and audio call minutes will be > sent to both the > megaco(a)baynetworks.com and to the ITU-SG16(a)mailbag.intel.com > mailing lists. > > Tom Taylor took the action of posting to each list, how to > join the other > one. > > Detailed minutes: > ------------------------ > Brian Rosen presented the Megaco protocol draft > (ftp://www.ietf.org/internet-drafts/draft-ietf-megaco-protocol > -00.txt). He > first noted that this draft is open for discussion. It is not > cast in stone. > If changes need to be made to any part, they will be made, if they are > deemed necessary to satisfy the requirements of the protocol, > and agreed to > by the group. > > 1. New connection model > - concept of a termination - have permanent (e.g. DS0) and > ephemeral (e.g. > RTP port) terminations > - a termination is named with a terminationId, this name can > have wildcards, > for example to allow the MG to choose the actual physical > termination, or to > request notification of an event that occurs on any DS0 > - concept of a context - can add, subtract, modify terminations in a > context. A context is created when the first termination is > added to it, and > goes away when the last termination is subtracted from it. > - a context can have parameters associated with it - for > example, a video > mixing context may have parameters to describe how the video > is to be mixed > - mosaic, or current speaker/last speaker, ... > - a termination class defines parameters on a typical > termination - e.g. DS0 > Termination Class, RTP Termination Class > - Signals can be attached to a termination class, events can > occur at a > termination class, and the MGC can specify which ones it wants to be > notified about. > - packages define signals and events > - a termination class can have more than one package that apply to it > - event naming structure allows package name to be put in > front of the event > name > - question: how do you apply a call waiting tone? - answer - > it is a signal > that you apply to a termination > > 1.1 Proposed Changes and Issues: > a. Tom Taylor proposed a more general definition for context: every > termination in a context has connectivity with all other > terminations in the > context. > > b. Raised by Mauricio Arango: you may want to be able to > create a context > with parameters before adding any terminations to it - (e.g. > turing machine) > - may want to mark a context with the max # of terminations > at creation > time. - BUT this may bring lack of flexibility - may be > better to let the MG > decide, as new terminations are added to a context, whether > it is able to > mix them in. For example, instead of marking a context with > one particular > type of codec, it is more flexible to let the MG decide what > transcoding > needs to be done in a context as a function of the types of > terminations > added to it. > > c. Raised by a few people: we need to see whether we need a > meta definition > of a "call" in the MG, so that the MG can link together > related contexts. > May be needed for lipsynch between a call's video context and > its audio > context. Instead of introducing a callId, this could be done using > parameters on each context referring to the other one. > Benefit of a callId > is that the MGC can bring down the entire call by just > referring to the > callId. (Note: "call" may be the wrong word - if we need it, > let's try to > invent a new name). > > d. Raised by Steve Davies: with H.320, the MG has one > physical termination > with audio, video and data on it - can a termination be in > more than one > context? no - so need to separate the different media out of > this physical > termination before creating the contexts. > > e. Raised by Tom Taylor: need to see whether it is feasible to have > decomposed H.320 gateways - if it is necessary (people say > yes), then need > to be sure the Megaco protocol can handle it. > > > 2. Commands > - grouped into commands within an action per context, and one or more > actions are grouped into a transaction. Transaction is all or nothing. > - Add, Modify, Subtract each can contain local and remote terminiation > descriptors, signalling descriptor, an events descriptor, and > a digit map > descriptor > - question on how to change an event description for a > termination - answer: > use Modify - can do it within a context, or outside a context > - if it is > outside the context (i.e. using the NULL context), then that > is how you > change the default parameters for that termination. > - MGCP's NotificationRequest is now covered in Modify > > 3. Multimedia and Contexts and Terminations > - a termination only belongs to one context > - for multimedia, there is one context per media type > - just as you have separate RTP flows for different media > types, you have > separate contexts. > > 3.1 Issues > a. Paul Sijben noted that when you try to use the Megaco protocol with > H.320, there may be problems with the model - Paul will bring > these up on > the mailing list. > > Also, see Issue c in 1.1 above. > > 4. H.245 & SDP > - Tom Taylor explained that H.245 has at least 2 purposes: 1) > for capability > negotiation, and 2) for specification of open logical > channel. The scope of > the Megaco protocol is 2). Capability negotiation may use > H.245 between > MGCs, but the Megaco protocol is between MGC and MG. SDP may > be good enough > to be used between the MGC and the MG. Discussion still open > here. Need to > allow for an environment where H.245 may not be involved. > - with H.263 - H.245 provides a tag to link together 2 RTP > streams - need to > be able to carry this tag from the MGC to the MG. > > 5. underspecifying termination descriptors > - can be used as a way to tell the MG to use default values for the > termination > - a termination learns its default values at MG boot-up time > - MGC can change these values using Modify with context set to NULL. > > 6. underspecifying terminationIds > - provides a way of setting default parameters for a T1 for example > > 7. Case: two audio contexts - in different MGs, and in the same MG > - can the connection model handle this? Yes > - protocol should need to keep track of where resources are. > - it is up to the MGC to know what contexts are associated > with a call. > > 8. overview of Audit, Notify, ServiceChange > - ServiceChange - MG can use it upon reboot, to register > itself with an MGC > - MG knows which MGC to send this msg to from some method > outside the scope > of this protocol (pre-provisioned, for example). > - MGC learns capabilities of MG using Audit. - can learn codecs > > 8.1 Issue > - need a way for MGC to learn the QUANTITY of codecs an MG has! > > 9. overview of Security > - this is security between an MGC and an MG > - interim method is specified for when an MG does not have IPSEC > > 10. Question on scope of the protocol > - check the requirements draft: > ftp://standards.nortelnetworks.com/megaco/docs/minn99 > - Steve Davies brought up point that some aspects of the > Megaco protocol > overlap with Policy server protocol proposals. > > 11. Can MG do coded renegotiation? > - David Featherstone asked if an MG can negotiate use of a > new codec on its > own > - Brian Rosen answered that with AAL2 profiles, the MG can > > Issue: > a. MGC may need to be involved - for example if the Quality > goes down too > low, call may no longer be billable. Solution - create an > event to notify > the MGC for this case. > > 12. How does the MGC find out RTP interfaces? > - should be able to do this using Audit in the NULL context. > > 13. IVR - still open for discussion > - view IVR as a termination > - issue is how much signalling effort do you need to add to > the protocol? > - simply playing msgs is ok - they just look like events > - problem is when you want to put time and money values into > it for example, > you have x minutes left on your calling card. - this may be > out of the scope > of the Megaco protocol > > 14. QoS reservation > - needs more discussion > > ****see Meeting summary above for audio call conclusions. > > end of minutes. > > > > > > -------------------------------------------------------------- > ------------ > Nancy M. Greene > Internet & Service Provider Networks, Nortel Networks > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com >

3 2

Re: H.320 gateways a MEGACO / ITU
by Matt Holdrege 31 Mar '99

31 Mar '99

To be more accurate, PER may not work fine through a NAT function. If your firewall doesn't do NAT, then PER should have no problems. At 09:34 AM 3/31/99 -0500, Melinda Shore wrote: >There's another problem - the use of PER combined with protocol- >embedded addresses greatly complicates operation through firewalls. >Not that I'm a fan of text-based protocols - I absolutely am not. >But PER-encoded signaling streams could force the use of firewall >proxies, which has unfortunate performance implications. > >I'm not certain that I understand the point about transcoding - >it's going to have to take place, anyway, whether the megaco protocol >is text-based or not. > >At 11:14 AM 3/31/99 +0200, Ami Amir wrote: >>There are many who feel that ASN.1 is too heavy and complex for simple >>devices, and should be avoided. This was one of the major reasons for the >>emergence of SIP. > >Melinda Shore >Member of the Scientific Staff >Nokia IP Telephony >127 West State Street >Ithaca, New York 14850 >+1 607 273 0724 x81 (office) >+1 607 275 3610 (fax) >+1 607 280 0010 (mobile) >shore(a)ithaca-viennasys.com >

2 2

H.320 gateways a MEGACO / ITU
by Ami Amir 31 Mar '99

31 Mar '99

Hi During the last MEGACO conference call - Tom Taylor asked what could hinder ITU acceptance of the MEGACO work. It is obviously to everybody's interest that IETF and ITU standards merge. As an example - it would be great if the MEGACO work could become an ITU SG 16 contribution. An obvious item is efficient multimedia support (as reflected also in John's mail). However, I think that one of the even more major difficulties facing us will be the encoding scheme (ASN.1 vs Text). There are many who feel that ASN.1 is too heavy and complex for simple devices, and should be avoided. This was one of the major reasons for the emergence of SIP. On the other hand, experience in the ITU H.323 work has shown that since ASN.1 is the encoding scheme on the PSTN side, the use of ASN cleared the way for PSTN to IP interoperability. This feature will be extremely important in hybrid networks that need to provide Intelligent Network (IN) services (e.g. "800"), while retaining the investment in existing IN, billing and directory services (411). Another problem is that if ASN.1 is not chosen, every device that will have to connect between a MEGACO component and H.323 will need to dis-assemble and re-assemble (transcode) messages, and hence network performance will suffer, and those devices will be more complex. A prime example - MGC to GK communications. I am not promoting a specific approach. I just think that this complex issue needs to be addressed if we want to be able to be able accept a universal protocol. Do you think this is really a problem? If so - any ideas on how to bridge the gap? Ami -----Original Message----- From: John Segers [SMTP:jsegers@lucent.com] Sent: Tuesday, March 30, 1999 6:27 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: H.320 gateways People, In yesterday's conference call, the subject of H.320 GWs was raised briefly. In my opinion, the connection model and protocol should be able to deal with H.320. I would like to continue discussion on it on the mailing list. H.320 allows a user to have a session with both audio and video on a single 64 kbit/s channel such as an ISDN B-channel. The same channel carries some signalling information (frame alignment, bitrate allocation). To a MG supporting H.320, this means that on a single endpoint, three streams can come in, carrying different types of media. The current connection model of megaco/H.gcp does not cater to this. I see two possible solutions: The first is to allow multiple media in one context and to describe for terminations the logical streams they carry. In a picture: +----------+ | | | +--------- signalling (FAS, BAS) | | B-channel ==========+ +--------- audio (16 kbit/s) | | | +--------- video (46.4 kbit/s) | | +----------+ The second solution is to have separate terminations for the different streams. They would all "connect to" the same physical endpoint. In order to properly identify the terminations, it is necessary to have logical names for them. The physical endpoint they connect may have the hierarchical name proposed in the megaco document. Another example of a H.320 session is the case of two B-channels being used for an audiovisual call. The following frame structure is then possible. +--------------------------++-----------------------+ | Channel 1 || Channel 2 | +-----+--+--+--+--+--+--+--++--+--+--+--+--+--+--+--+ |Bit 1|B2|B3|B4|B5|B6|B7|B8||B1|B2|B3|B4|B5|B6|B7|B8| +-----+--+--+--+--+--+--+--++--+--+--+--+--+--+--+--+ 1 | a1 |a2|a3|a4|a5|a6|v1|F ||v2|v3|v4|v5|v6|v7|v8|F | 2 | a7 |a8|a9|a |a |a |v9|F ||v |v |v |v |v |v |v |F | 3 | a |a |a |a |a |a |v |F ||v |v |v |v |v |v |v |F | 4 | a | | | | |a |v |F ||v | |v |F | 5 | a | | | | |a |v |F ||v | |v |F | 6 | a | | | | |a |v |F ||v | |v |F | 7 | a | | | | |a |v |F ||v | |v |F | 8 | a | | | | |a |v |F ||v | |v |F | +---------------------------------------------------+ 9 | a | | | | |a |v |B ||v | |v |B | 10 | a | | | | |a |v |B ||v | |v |B | 11 | a | | | | |a |v |B ||v | |v |B | 12 | a | | | | |a |v |B ||v | |v |B | 13 | a | | | | |a |v |B ||v | |v |B | 14 | a | | | | |a |v |B ||v | |v |B | 15 | a | | | | |a |v |B ||v | |v |B | 16 | a | | | | |a |v |B ||v | |v |B | +---------------------------------------------------+ 17 | a | | | | |a |v |v ||v | |v |v | . . . 80 | a | | | | |a |v |v ||v | |v |v | +---------------------------------------------------+ (a=audio, v=video, F=FAS, B=BAS). We see that the video stream is split up over two channels. In order to cater to this, it seems we have to allow terminations to receive media from and send it to multiple physical endpoints. The two approaches outlined above can both be extended to allow this. Both extensions will lead to the introduction of logical names for terminations. In the first approach there will be one termination "containing" two B-channels on one side and three logical streams on the other. In the second approach there will be three terminations, the one for the video stream referencing both B-channels, the ones for signalling and audio referencing only channel 1. The second approach allows us to keep separate contexts for different media types. It is then easy to delete, for instance, the video part of a session (session used loosely to desribe the contexts for the audio and video). The first approach groups the streams coming from/going to one user, making it possible to remove a user from a context more easily. Personally, I can't decide which approach I would prefer. How do others feel about these ideas? 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

4 3

Latest implementers guide?
by Jan Holm 31 Mar '99

31 Mar '99

Where can I find the latest implementers guide? Is it updated updated according to the Monterey meeting yet? /Regards Jan Holm Ericsson Telecom AB

3 2

Re: H.320 gateways
by Brian Rosen 31 Mar '99

31 Mar '99

I'm in favor of the second approach. You could have a termination class H.320 with H.320/audio H.320/video and H.320/T.120. There would be 3 contexts, each with different media. There is a slight ugliness where the termination class would define all the parameters for all of the streams as one big list, and each of the terminations would have all of them. Unfortunate, but it works. Christian did not want to infer anything from the name. We would need to have some way for the MG to know which media was on which termination if we couldn't infer it from the name. I like this approach because from the MGC, whether the three streams are on one gateway, or multiple gateways, it operates on them the same way, only the names are changed (to protect the innocent). The MG is built differently in these cases, but I don't see any way around that. BTW, the H.320 stream could be multi-ported, so you could have H.320/7/video. > -----Original Message----- > From: John Segers [ mailto:jsegers@lucent.com <mailto:jsegers@lucent.com> ] > Sent: Tuesday, March 30, 1999 10:27 AM > To: megaco(a)BayNetworks.COM; ITU-SG16(a)mailbag.cps.intel.com > Subject: H.320 gateways > > > People, > > In yesterday's conference call, the subject of H.320 GWs was raised > briefly. In my opinion, the connection model and protocol > should be able > to deal with H.320. I would like to continue discussion on it on the > mailing list. > > H.320 allows a user to have a session with both audio and video on a > single 64 kbit/s channel such as an ISDN B-channel. The same channel > carries some signalling information (frame alignment, bitrate > allocation). To a MG supporting H.320, this means that on a single > endpoint, three streams can come in, carrying different types > of media. > The current connection model of megaco/H.gcp does not cater > to this. I > see two possible solutions: > > The first is to allow multiple media in one context and to > describe for > terminations the logical streams they carry. In a picture: > > +----------+ > | | > | +--------- signalling (FAS, BAS) > | | > B-channel ==========+ +--------- audio (16 kbit/s) > | | > | +--------- video (46.4 kbit/s) > | | > +----------+ > > The second solution is to have separate terminations for the different > streams. They would all "connect to" the same physical endpoint. In > order to properly identify the terminations, it is necessary to have > logical names for them. The physical endpoint they connect > may have the > hierarchical name proposed in the megaco document. > > Another example of a H.320 session is the case of two B-channels being > used for an audiovisual call. The following frame structure is then > possible. > > +--------------------------++-----------------------+ > | Channel 1 || Channel 2 | > +-----+--+--+--+--+--+--+--++--+--+--+--+--+--+--+--+ > |Bit 1|B2|B3|B4|B5|B6|B7|B8||B1|B2|B3|B4|B5|B6|B7|B8| > +-----+--+--+--+--+--+--+--++--+--+--+--+--+--+--+--+ > 1 | a1 |a2|a3|a4|a5|a6|v1|F ||v2|v3|v4|v5|v6|v7|v8|F | > 2 | a7 |a8|a9|a |a |a |v9|F ||v |v |v |v |v |v |v |F | > 3 | a |a |a |a |a |a |v |F ||v |v |v |v |v |v |v |F | > 4 | a | | | | |a |v |F ||v | |v |F | > 5 | a | | | | |a |v |F ||v | |v |F | > 6 | a | | | | |a |v |F ||v | |v |F | > 7 | a | | | | |a |v |F ||v | |v |F | > 8 | a | | | | |a |v |F ||v | |v |F | > +---------------------------------------------------+ > 9 | a | | | | |a |v |B ||v | |v |B | > 10 | a | | | | |a |v |B ||v | |v |B | > 11 | a | | | | |a |v |B ||v | |v |B | > 12 | a | | | | |a |v |B ||v | |v |B | > 13 | a | | | | |a |v |B ||v | |v |B | > 14 | a | | | | |a |v |B ||v | |v |B | > 15 | a | | | | |a |v |B ||v | |v |B | > 16 | a | | | | |a |v |B ||v | |v |B | > +---------------------------------------------------+ > 17 | a | | | | |a |v |v ||v | |v |v | > . > . > . > 80 | a | | | | |a |v |v ||v | |v |v | > +---------------------------------------------------+ > > (a=audio, v=video, F=FAS, B=BAS). > > We see that the video stream is split up over two channels. > In order to > cater to this, it seems we have to allow terminations to receive media > from and send it to multiple physical endpoints. The two approaches > outlined above can both be extended to allow this. Both > extensions will > lead to the introduction of logical names for terminations. In the > first approach there will be one termination "containing" two > B-channels > on one side and three logical streams on the other. In the second > approach there will be three terminations, the one for the > video stream > referencing both B-channels, the ones for signalling and audio > referencing only channel 1. > > The second approach allows us to keep separate contexts for different > media types. It is then easy to delete, for instance, the > video part of > a session (session used loosely to desribe the contexts for the audio > and video). > > The first approach groups the streams coming from/going to one user, > making it possible to remove a user from a context more easily. > > > Personally, I can't decide which approach I would prefer. > How do others > feel about these ideas? > > 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 >

2 1

Re: Multimedia (was Re: Megaco Protocol - IETF/ITU conf call minutes)
by Roni Even 31 Mar '99

31 Mar '99

I want to add the issue of T.120 to the multimedia discussion. An effort is made in SG16 Q3 to try to develop T.120 as the control interface for audio graphic conferences using PSTN. So far we talk about h.323 and H.245 but what about T.120 Roni Even Accord Video Telecommunication. email:roni_e@accord.co.il -----Original Message----- From: John Segers <jsegers(a)LUCENT.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: éåí øáéòé 31 îøõ 1999 14:13 Subject: Re: Multimedia (was Re: Megaco Protocol - IETF/ITU conf call minutes) >Mauricio, > >You are right that single medium contexts are simpler to reason about >services and call flows. But we must take care that we don't end up >with a protocol that cannot be extended to cover multimedia GWs. If >multimedia applications are within scope, the protocol document should >not contain a connection model that handles only audio. > >What do others think? Is multimedia in the scope of megaco/H.gcp? And >if so, is Paul's proposal general enough? Doesn't it lead to too much >overhead for single media GWs? I'd be interested to hear opinions. > >John Segers > >"Arango, Mauricio" wrote: >> >> Please disregard my previous message which by mistake I sent without erasing >> editing. Apologies to the list members. >> >> Paul, >> >> I understand the rationale for your multiple media context. My preference is >> the single medium context because it seems simpler for thinking about >> services and call flows. This seems to require more discussion. I suggest we >> advance the protocol as proposed with single-medium contexts and revisit >> this later if necessary. >> >> Mauricio >> >> > -----Original Message----- >> > From: Paul Sijben [mailto:sijben@lucent.com] >> > Sent: Tuesday, March 30, 1999 2:45 PM >> > To: Arango, Mauricio >> > Cc: 'Greene, Nancy-M [CAR:5N10:EXCH]'; 'ITU-SG16(a)mailbag.intel.com'; >> > 'megaco(a)baynetworks.com' >> > Subject: Multimedia (was Re: Megaco Protocol - IETF/ITU conf call >> > minutes) >> > >> > >> > Mauricio, >> > >> > you write: >> > > It could be good idea to have some entity that ties >> > together multiple >> > > contexts, this was our experience in the Touring Machine >> > and we referred to >> > > it as "session". However, it may not be necessary for the >> > most common audio >> > > only operations, and for the sake of simplicity it may be >> > better to leave it >> > > as an option. >> > >> > I think you are absolutely right. We have been doing some >> > work on that and >> > have come up with the following which seems like a sensible >> > extention to >> > the H.gcp/MEGACOP work: >> > >> > Problem definition: >> > For multimedia calls you will have multiple media streams >> > representing >> > each of the users. these streams need to be appropriately >> > processed (maybe >> > mixed or something more clever) and synchronised. >> > >> > The current definition in the MEGACO I-D specifies that each >> > context only >> > has one type of medium. This makes the logical grouping of >> > terminations >> > belonging to one user difficult, creates issues with synchronisation >> > between media. It also makes it difficult to remove one user >> > or an entire >> > conference in one command. >> > >> > We have gone over several possible solutions, you can group >> > terminations >> > per user, and/or per medium and/or make some kind of links between >> > terminations or contexts which signify the synchronisation. >> > >> > What seems like a workable model is to allow multiple media >> > in one context >> > and have a matrix binding the terminations to the right >> > medium/user. So you >> > would get something like: >> > >> > context >> > >> > medium1 | M2 | ....| Mn >> > ------------------------------ >> > user1 | x | | | x >> > user2 | | x | | x >> > .......... >> > usern | x | x >> > where x==termination >> > >> > such a matrix could be a "scap paper" used by the MGW and MC >> > to keep track >> > of to which user and which medium each termination belongs. >> > One could set a >> > flag on terminations that one wants to synchronise. >> > >> > Naturally you would not need this for simple voice gateways so the >> > extentions needed to the protocol for this youl be optional. >> > >> > The extentions would look like: >> > >> > Commands: >> > We now have a command structure that states: >> > >> > ContextID >> > *Command(TerminationID ....) >> > >> > we would get: >> > >> > ContextID >> > [UserID] >> > *command( [MediaID] Termination ID....) >> > >> > so for example: >> > ContextID=3 >> > UserID=2 >> > add (MediaID=Video3, TerminationID=RTP:32424, ....) >> > modify (MediaID=Video3, TerminationID=*, SychWith:MediaID=Audio2) >> > >> > etc. >> > >> > A context could have the following properties: >> > - mode (unidirectional, bidirectional, mix, choose...) >> > - maxNumberOfUsers (e.g. 3) >> > - maxNumberOfMedia (e.g. 1 for a simple voice gateway) >> > >> > This extention would allow the removal of one medium or one >> > user from a >> > conference but not hamper "simple" operations. >> > >> > Paul >> > >> > "Arango, Mauricio" wrote: >> > > >> > > Nancy, >> > > >> > > Thanks for preparing the minutes. >> > > >> > > > >> > > > b. Raised by Mauricio Arango: you may want to be able to >> > > > create a context >> > > > with parameters before adding any terminations to it - (e.g. >> > > > turing machine) >> > > >> > > I want to clarify that I was not referring to Alan Turing's >> > grand work but >> > > to something colleagues and I did some years ago in >> > multimedia call control, >> > > called "Touring Machine". This effort developed a >> > connection model similar >> > > to the one in MEGACO's protocol and could be worth keeping >> > in mind as >> > > previous experience to help this effort. >> > > >> > > The January 1993 of the Communications of the ACM has an >> > article on the >> > > Touring Machine. Following is an excerpt desribing its >> > connection model >> > > (page 71): >> > > >> > > "The logical topology of a session is specified as a set of >> > typed connectors >> > > (see Figure 2). A connector represents a multiway transport >> > connection among >> > > endpoints (logical ports). A connection is an abstraction of a >> > > communications bridge, including point-to-point (two way) as well as >> > > multipoint connections. Since bridging is a medium-specific >> > operation, >> > > connectors are typed by medium. A session may have one or >> > more connectors >> > > per medium, with souce and sink endpoints from >> > participating clients. An >> > > endpoint represents a connector termination point. Endpoints are >> > > distinguished by medium, direction of flow, and the client >> > receiving or >> > > providing transport." >> > > >> > > In the above excerpt a "connector" is equivalent to >> > MEGACO's context and an >> > > "endpoint" is equivalent to MEGACO's termination. >> > > >> > > > c. Raised by a few people: we need to see whether we need a >> > > > meta definition >> > > > of a "call" in the MG, so that the MG can link together >> > > > related contexts. >> > > > May be needed for lipsynch between a call's video context and >> > > > its audio >> > > > context. Instead of introducing a callId, this could be done using >> > > > parameters on each context referring to the other one. >> > > > Benefit of a callId >> > > > is that the MGC can bring down the entire call by just >> > > > referring to the >> > > > callId. (Note: "call" may be the wrong word - if we need it, >> > > > let's try to >> > > > invent a new name). >> > > > >> > > >> > > It could be good idea to have some entity that ties >> > together multiple >> > > contexts, this was our experience in the Touring Machine >> > and we referred to >> > > it as "session". However, it may not be necessary for the >> > most common audio >> > > only operations, and for the sake of simplicity it may be >> > better to leave it >> > > as an option. >> > > >> > > Regards, >> > > >> > > Mauricio Arango >> > > >> > > > -----Original Message----- >> > > > From: Greene, Nancy-M [CAR:5N10:EXCH] >> > > > [mailto:ngreene@americasm01.nt.com] >> > > > Sent: Monday, March 29, 1999 8:54 PM >> > > > To: 'ITU-SG16(a)mailbag.intel.com'; 'megaco(a)baynetworks.com' >> > > > Subject: Megaco Protocol - IETF/ITU conf call minutes >> > > > >> > > > >> > > > Here are the minutes from the call today. Please email me any >> > > > corrections. I >> > > > tried to pair comments made with the person that made them - >> > > > I may have made >> > > > some errors, and I know I missed the names of some of the >> > > > people commenting. >> > > > >> > > > >> > > > >> > > > Nancy (ngreene(a)nortelnetworks.com) >> > > > ----------------------------------------------------------- >> > > > >> > > > Megaco Protocol presentation to IETF megaco and ITU SG16 >> > participants >> > > > March 29/99 10am-12pm EST >> > > > ================================================= >> > > > >> > > > Present: The number of ports being used went as high as 47, >> > > > and was about 45 >> > > > on average. Number of participants was higher since a number >> > > > of people were >> > > > sharing ports. >> > > > >> > > > Chair of the call: Glen Freundlich (ggf(a)lucent.com) >> > > > Minutes: taken by Nancy Greene (ngreene(a)nortelnetworks.com) >> > > > >> > > > NOTE: In keeping with IETF and ITU procedures, the audio call >> > > > cannot make >> > > > binding decisions. It is a tool for the chairs and >> > editors, and the >> > > > participants of both the IETF and ITU working groups, to >> > > > gauge support for >> > > > the protocol, and to raise issues with the protocol. Issues >> > > > may be raised in >> > > > either an audio call, or on the mailing list >> > > > (megaco(a)baynetworks.com) These >> > > > minutes are going to both the Megaco and ITU-SG16 mailing lists. >> > > > >> > > > Meeting summary: >> > > > -------------------------- >> > > > Glen Freundlich summed up results of the meeting. The goal of >> > > > the meeting >> > > > was two fold: >> > > > 1) it was the first opportunity for people to look at the >> > > > output from the >> > > > Megaco protocol design/drafting group. >> > > > 2) it was an opportunity for people to pose questions on >> > the draft. >> > > > >> > > > He saw no opposition to the connection model proposed in the >> > > > Megaco protocol >> > > > I-D >> > > > (ftp://www.ietf.org/internet-drafts/draft-ietf-megaco-protocol >> > > > -00.txt). >> > > > To date, the Megaco protocol I-D has been run through audio >> > > > call scenarios >> > > > for 3-way call, for call waiting, ... However, it needs to be >> > > > tested with >> > > > multimedia scenarios. Any input in this area is appreciated. >> > > > >> > > > Because there seems to be agreement on the connection model, >> > > > Bryan Hill, the >> > > > H.gcp editor, will start pulling related sections from the >> > > > Megaco protocol >> > > > I-D into H.gcp. >> > > > >> > > > Glen will hold another audio call next week to see where we >> > > > stand, and to >> > > > look towards adding more sections to H.gcp from the Megaco >> > > > protocol I-D. >> > > > >> > > > For the ITU-T SG16 May meeting, H.gcp needs to contain: >> > > > - a connection model >> > > > - a set of commands >> > > > - a start on parameters for those commands >> > > > - generic syntax >> > > > - and a list of issues to resolve. >> > > > >> > > > >> > > > Protocol timetable: >> > > > -------------------------- >> > > > IETF Megaco: >> > > > - Proposed Standard by summer/99 >> > > > - interoperability testing in fall/99 >> > > > - Draft Standard in Feb/2000 >> > > > >> > > > This matches up closely with the ITU-T SG16 schedule: >> > > > - planning to get H.gcp determined in May/99 >> > > > - planning to get H.gcp decided in Feb/2000 >> > > > >> > > > IETF/ITU collaboration: >> > > > ------------------------------- >> > > > Question raised: will the two protocols be identical? >> > > > >> > > > Tom Taylor proposes two options: >> > > > 1) SG16 and Megaco completely agree on the protocol >> > > > requirements. If this is >> > > > the case, the protocol will be identical >> > > > >> > > > 2) Each group has some requirements that are different from >> > > > the other group. >> > > > In this case, there would be agreement on a core >> > protocol, and then >> > > > additional parts would be defined by each group. >> > > > >> > > > BUT how to do this in practice? Tom said that if a huge >> > > > roadblock comes up >> > > > again, we would form a new design team to work out a solution. >> > > > >> > > > Tom asked whether the group on the call agreed that the >> > > > Megaco protocol I-D >> > > > was a reasonable basis for H.gcp. Feeling was that it is, but >> > > > that we need >> > > > to do multimedia call walkthroughs. Mike Buckley had some >> > > > concern about the >> > > > definition of a context, but thought that the basic model >> > is workable. >> > > > Mauricio Arango thought it was a good model for multimedia. >> > > > Ami Amir raised >> > > > issue about associating contexts. Glen asked the H.320 >> > > > experts to look at >> > > > the protocol and see if we need to modify the connection model. >> > > > >> > > > >> > > > Next audio call: >> > > > ---------------------- >> > > > Probably next Thursday April 8/99, same time. Confirmation of >> > > > date & time >> > > > and the call details will be out later this week. >> > > > >> > > > >> > > > Use of mailing lists: >> > > > --------------------------- >> > > > It was agreed that we would try to keep all technical >> > > > discussion of the >> > > > Megaco protocol on the megaco(a)baynetworks.com mailing list. >> > > > >> > > > Invitations to audio calls, and audio call minutes will be >> > > > sent to both the >> > > > megaco(a)baynetworks.com and to the ITU-SG16(a)mailbag.intel.com >> > > > mailing lists. >> > > > >> > > > Tom Taylor took the action of posting to each list, how to >> > > > join the other >> > > > one. >> > > > >> > > > Detailed minutes: >> > > > ------------------------ >> > > > Brian Rosen presented the Megaco protocol draft >> > > > (ftp://www.ietf.org/internet-drafts/draft-ietf-megaco-protocol >> > > > -00.txt). He >> > > > first noted that this draft is open for discussion. It is not >> > > > cast in stone. >> > > > If changes need to be made to any part, they will be >> > made, if they are >> > > > deemed necessary to satisfy the requirements of the protocol, >> > > > and agreed to >> > > > by the group. >> > > > >> > > > 1. New connection model >> > > > - concept of a termination - have permanent (e.g. DS0) and >> > > > ephemeral (e.g. >> > > > RTP port) terminations >> > > > - a termination is named with a terminationId, this name can >> > > > have wildcards, >> > > > for example to allow the MG to choose the actual physical >> > > > termination, or to >> > > > request notification of an event that occurs on any DS0 >> > > > - concept of a context - can add, subtract, modify >> > terminations in a >> > > > context. A context is created when the first termination is >> > > > added to it, and >> > > > goes away when the last termination is subtracted from it. >> > > > - a context can have parameters associated with it - for >> > > > example, a video >> > > > mixing context may have parameters to describe how the video >> > > > is to be mixed >> > > > - mosaic, or current speaker/last speaker, ... >> > > > - a termination class defines parameters on a typical >> > > > termination - e.g. DS0 >> > > > Termination Class, RTP Termination Class >> > > > - Signals can be attached to a termination class, events can >> > > > occur at a >> > > > termination class, and the MGC can specify which ones it >> > wants to be >> > > > notified about. >> > > > - packages define signals and events >> > > > - a termination class can have more than one package that >> > apply to it >> > > > - event naming structure allows package name to be put in >> > > > front of the event >> > > > name >> > > > - question: how do you apply a call waiting tone? - answer - >> > > > it is a signal >> > > > that you apply to a termination >> > > > >> > > > 1.1 Proposed Changes and Issues: >> > > > a. Tom Taylor proposed a more general definition for >> > context: every >> > > > termination in a context has connectivity with all other >> > > > terminations in the >> > > > context. >> > > > >> > > > b. Raised by Mauricio Arango: you may want to be able to >> > > > create a context >> > > > with parameters before adding any terminations to it - (e.g. >> > > > turing machine) >> > > > - may want to mark a context with the max # of terminations >> > > > at creation >> > > > time. - BUT this may bring lack of flexibility - may be >> > > > better to let the MG >> > > > decide, as new terminations are added to a context, whether >> > > > it is able to >> > > > mix them in. For example, instead of marking a context with >> > > > one particular >> > > > type of codec, it is more flexible to let the MG decide what >> > > > transcoding >> > > > needs to be done in a context as a function of the types of >> > > > terminations >> > > > added to it. >> > > > >> > > > c. Raised by a few people: we need to see whether we need a >> > > > meta definition >> > > > of a "call" in the MG, so that the MG can link together >> > > > related contexts. >> > > > May be needed for lipsynch between a call's video context and >> > > > its audio >> > > > context. Instead of introducing a callId, this could be done using >> > > > parameters on each context referring to the other one. >> > > > Benefit of a callId >> > > > is that the MGC can bring down the entire call by just >> > > > referring to the >> > > > callId. (Note: "call" may be the wrong word - if we need it, >> > > > let's try to >> > > > invent a new name). >> > > > >> > > > d. Raised by Steve Davies: with H.320, the MG has one >> > > > physical termination >> > > > with audio, video and data on it - can a termination be in >> > > > more than one >> > > > context? no - so need to separate the different media out of >> > > > this physical >> > > > termination before creating the contexts. >> > > > >> > > > e. Raised by Tom Taylor: need to see whether it is >> > feasible to have >> > > > decomposed H.320 gateways - if it is necessary (people say >> > > > yes), then need >> > > > to be sure the Megaco protocol can handle it. >> > > > >> > > > >> > > > 2. Commands >> > > > - grouped into commands within an action per context, and >> > one or more >> > > > actions are grouped into a transaction. Transaction is >> > all or nothing. >> > > > - Add, Modify, Subtract each can contain local and remote >> > terminiation >> > > > descriptors, signalling descriptor, an events descriptor, and >> > > > a digit map >> > > > descriptor >> > > > - question on how to change an event description for a >> > > > termination - answer: >> > > > use Modify - can do it within a context, or outside a context >> > > > - if it is >> > > > outside the context (i.e. using the NULL context), then that >> > > > is how you >> > > > change the default parameters for that termination. >> > > > - MGCP's NotificationRequest is now covered in Modify >> > > > >> > > > 3. Multimedia and Contexts and Terminations >> > > > - a termination only belongs to one context >> > > > - for multimedia, there is one context per media type >> > > > - just as you have separate RTP flows for different media >> > > > types, you have >> > > > separate contexts. >> > > > >> > > > 3.1 Issues >> > > > a. Paul Sijben noted that when you try to use the Megaco >> > protocol with >> > > > H.320, there may be problems with the model - Paul will bring >> > > > these up on >> > > > the mailing list. >> > > > >> > > > Also, see Issue c in 1.1 above. >> > > > >> > > > 4. H.245 & SDP >> > > > - Tom Taylor explained that H.245 has at least 2 purposes: 1) >> > > > for capability >> > > > negotiation, and 2) for specification of open logical >> > > > channel. The scope of >> > > > the Megaco protocol is 2). Capability negotiation may use >> > > > H.245 between >> > > > MGCs, but the Megaco protocol is between MGC and MG. SDP may >> > > > be good enough >> > > > to be used between the MGC and the MG. Discussion still open >> > > > here. Need to >> > > > allow for an environment where H.245 may not be involved. >> > > > - with H.263 - H.245 provides a tag to link together 2 RTP >> > > > streams - need to >> > > > be able to carry this tag from the MGC to the MG. >> > > > >> > > > 5. underspecifying termination descriptors >> > > > - can be used as a way to tell the MG to use default >> > values for the >> > > > termination >> > > > - a termination learns its default values at MG boot-up time >> > > > - MGC can change these values using Modify with context >> > set to NULL. >> > > > >> > > > 6. underspecifying terminationIds >> > > > - provides a way of setting default parameters for a T1 >> > for example >> > > > >> > > > 7. Case: two audio contexts - in different MGs, and in the same MG >> > > > - can the connection model handle this? Yes >> > > > - protocol should need to keep track of where resources are. >> > > > - it is up to the MGC to know what contexts are associated >> > > > with a call. >> > > > >> > > > 8. overview of Audit, Notify, ServiceChange >> > > > - ServiceChange - MG can use it upon reboot, to register >> > > > itself with an MGC >> > > > - MG knows which MGC to send this msg to from some method >> > > > outside the scope >> > > > of this protocol (pre-provisioned, for example). >> > > > - MGC learns capabilities of MG using Audit. - can learn codecs >> > > > >> > > > 8.1 Issue >> > > > - need a way for MGC to learn the QUANTITY of codecs an MG has! >> > > > >> > > > 9. overview of Security >> > > > - this is security between an MGC and an MG >> > > > - interim method is specified for when an MG does not have IPSEC >> > > > >> > > > 10. Question on scope of the protocol >> > > > - check the requirements draft: >> > > > ftp://standards.nortelnetworks.com/megaco/docs/minn99 >> > > > - Steve Davies brought up point that some aspects of the >> > > > Megaco protocol >> > > > overlap with Policy server protocol proposals. >> > > > >> > > > 11. Can MG do coded renegotiation? >> > > > - David Featherstone asked if an MG can negotiate use of a >> > > > new codec on its >> > > > own >> > > > - Brian Rosen answered that with AAL2 profiles, the MG can >> > > > >> > > > Issue: >> > > > a. MGC may need to be involved - for example if the Quality >> > > > goes down too >> > > > low, call may no longer be billable. Solution - create an >> > > > event to notify >> > > > the MGC for this case. >> > > > >> > > > 12. How does the MGC find out RTP interfaces? >> > > > - should be able to do this using Audit in the NULL context. >> > > > >> > > > 13. IVR - still open for discussion >> > > > - view IVR as a termination >> > > > - issue is how much signalling effort do you need to add to >> > > > the protocol? >> > > > - simply playing msgs is ok - they just look like events >> > > > - problem is when you want to put time and money values into >> > > > it for example, >> > > > you have x minutes left on your calling card. - this may be >> > > > out of the scope >> > > > of the Megaco protocol >> > > > >> > > > 14. QoS reservation >> > > > - needs more discussion >> > > > >> > > > ****see Meeting summary above for audio call conclusions. >> > > > >> > > > end of minutes. >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > -------------------------------------------------------------- >> > > > ------------ >> > > > Nancy M. Greene >> > > > Internet & Service Provider Networks, Nortel Networks >> > > > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com >> > > > >> > >> > -- >> > Paul Sijben Telno:+ 31 35 687 4774 Fax:+31 35 687 5954 >> > Lucent Technologies Home telno: +31 33 4557522 >> > Forward Looking Work e-mail: sijben(a)lucent.com >> > Huizen, The Netherlands internal http://hzsgp68.nl.lucent.com/ >> > > >-- >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: Multimedia (was Re: Megaco Protocol - IETF/ITU conf call min utes)
by Arango, Mauricio 31 Mar '99

31 Mar '99

Please disregard my previous message which by mistake I sent without erasing editing. Apologies to the list members. Paul, I understand the rationale for your multiple media context. My preference is the single medium context because it seems simpler for thinking about services and call flows. This seems to require more discussion. I suggest we advance the protocol as proposed with single-medium contexts and revisit this later if necessary. Mauricio > -----Original Message----- > From: Paul Sijben [mailto:sijben@lucent.com] > Sent: Tuesday, March 30, 1999 2:45 PM > To: Arango, Mauricio > Cc: 'Greene, Nancy-M [CAR:5N10:EXCH]'; 'ITU-SG16(a)mailbag.intel.com'; > 'megaco(a)baynetworks.com' > Subject: Multimedia (was Re: Megaco Protocol - IETF/ITU conf call > minutes) > > > Mauricio, > > you write: > > It could be good idea to have some entity that ties > together multiple > > contexts, this was our experience in the Touring Machine > and we referred to > > it as "session". However, it may not be necessary for the > most common audio > > only operations, and for the sake of simplicity it may be > better to leave it > > as an option. > > I think you are absolutely right. We have been doing some > work on that and > have come up with the following which seems like a sensible > extention to > the H.gcp/MEGACOP work: > > Problem definition: > For multimedia calls you will have multiple media streams > representing > each of the users. these streams need to be appropriately > processed (maybe > mixed or something more clever) and synchronised. > > The current definition in the MEGACO I-D specifies that each > context only > has one type of medium. This makes the logical grouping of > terminations > belonging to one user difficult, creates issues with synchronisation > between media. It also makes it difficult to remove one user > or an entire > conference in one command. > > We have gone over several possible solutions, you can group > terminations > per user, and/or per medium and/or make some kind of links between > terminations or contexts which signify the synchronisation. > > What seems like a workable model is to allow multiple media > in one context > and have a matrix binding the terminations to the right > medium/user. So you > would get something like: > > context > > medium1 | M2 | ....| Mn > ------------------------------ > user1 | x | | | x > user2 | | x | | x > .......... > usern | x | x > where x==termination > > such a matrix could be a "scap paper" used by the MGW and MC > to keep track > of to which user and which medium each termination belongs. > One could set a > flag on terminations that one wants to synchronise. > > Naturally you would not need this for simple voice gateways so the > extentions needed to the protocol for this youl be optional. > > The extentions would look like: > > Commands: > We now have a command structure that states: > > ContextID > *Command(TerminationID ....) > > we would get: > > ContextID > [UserID] > *command( [MediaID] Termination ID....) > > so for example: > ContextID=3 > UserID=2 > add (MediaID=Video3, TerminationID=RTP:32424, ....) > modify (MediaID=Video3, TerminationID=*, SychWith:MediaID=Audio2) > > etc. > > A context could have the following properties: > - mode (unidirectional, bidirectional, mix, choose...) > - maxNumberOfUsers (e.g. 3) > - maxNumberOfMedia (e.g. 1 for a simple voice gateway) > > This extention would allow the removal of one medium or one > user from a > conference but not hamper "simple" operations. > > Paul > > "Arango, Mauricio" wrote: > > > > Nancy, > > > > Thanks for preparing the minutes. > > > > > > > > b. Raised by Mauricio Arango: you may want to be able to > > > create a context > > > with parameters before adding any terminations to it - (e.g. > > > turing machine) > > > > I want to clarify that I was not referring to Alan Turing's > grand work but > > to something colleagues and I did some years ago in > multimedia call control, > > called "Touring Machine". This effort developed a > connection model similar > > to the one in MEGACO's protocol and could be worth keeping > in mind as > > previous experience to help this effort. > > > > The January 1993 of the Communications of the ACM has an > article on the > > Touring Machine. Following is an excerpt desribing its > connection model > > (page 71): > > > > "The logical topology of a session is specified as a set of > typed connectors > > (see Figure 2). A connector represents a multiway transport > connection among > > endpoints (logical ports). A connection is an abstraction of a > > communications bridge, including point-to-point (two way) as well as > > multipoint connections. Since bridging is a medium-specific > operation, > > connectors are typed by medium. A session may have one or > more connectors > > per medium, with souce and sink endpoints from > participating clients. An > > endpoint represents a connector termination point. Endpoints are > > distinguished by medium, direction of flow, and the client > receiving or > > providing transport." > > > > In the above excerpt a "connector" is equivalent to > MEGACO's context and an > > "endpoint" is equivalent to MEGACO's termination. > > > > > c. Raised by a few people: we need to see whether we need a > > > meta definition > > > of a "call" in the MG, so that the MG can link together > > > related contexts. > > > May be needed for lipsynch between a call's video context and > > > its audio > > > context. Instead of introducing a callId, this could be done using > > > parameters on each context referring to the other one. > > > Benefit of a callId > > > is that the MGC can bring down the entire call by just > > > referring to the > > > callId. (Note: "call" may be the wrong word - if we need it, > > > let's try to > > > invent a new name). > > > > > > > It could be good idea to have some entity that ties > together multiple > > contexts, this was our experience in the Touring Machine > and we referred to > > it as "session". However, it may not be necessary for the > most common audio > > only operations, and for the sake of simplicity it may be > better to leave it > > as an option. > > > > Regards, > > > > Mauricio Arango > > > > > -----Original Message----- > > > From: Greene, Nancy-M [CAR:5N10:EXCH] > > > [mailto:ngreene@americasm01.nt.com] > > > Sent: Monday, March 29, 1999 8:54 PM > > > To: 'ITU-SG16(a)mailbag.intel.com'; 'megaco(a)baynetworks.com' > > > Subject: Megaco Protocol - IETF/ITU conf call minutes > > > > > > > > > Here are the minutes from the call today. Please email me any > > > corrections. I > > > tried to pair comments made with the person that made them - > > > I may have made > > > some errors, and I know I missed the names of some of the > > > people commenting. > > > > > > > > > > > > Nancy (ngreene(a)nortelnetworks.com) > > > ----------------------------------------------------------- > > > > > > Megaco Protocol presentation to IETF megaco and ITU SG16 > participants > > > March 29/99 10am-12pm EST > > > ================================================= > > > > > > Present: The number of ports being used went as high as 47, > > > and was about 45 > > > on average. Number of participants was higher since a number > > > of people were > > > sharing ports. > > > > > > Chair of the call: Glen Freundlich (ggf(a)lucent.com) > > > Minutes: taken by Nancy Greene (ngreene(a)nortelnetworks.com) > > > > > > NOTE: In keeping with IETF and ITU procedures, the audio call > > > cannot make > > > binding decisions. It is a tool for the chairs and > editors, and the > > > participants of both the IETF and ITU working groups, to > > > gauge support for > > > the protocol, and to raise issues with the protocol. Issues > > > may be raised in > > > either an audio call, or on the mailing list > > > (megaco(a)baynetworks.com) These > > > minutes are going to both the Megaco and ITU-SG16 mailing lists. > > > > > > Meeting summary: > > > -------------------------- > > > Glen Freundlich summed up results of the meeting. The goal of > > > the meeting > > > was two fold: > > > 1) it was the first opportunity for people to look at the > > > output from the > > > Megaco protocol design/drafting group. > > > 2) it was an opportunity for people to pose questions on > the draft. > > > > > > He saw no opposition to the connection model proposed in the > > > Megaco protocol > > > I-D > > > (ftp://www.ietf.org/internet-drafts/draft-ietf-megaco-protocol > > > -00.txt). > > > To date, the Megaco protocol I-D has been run through audio > > > call scenarios > > > for 3-way call, for call waiting, ... However, it needs to be > > > tested with > > > multimedia scenarios. Any input in this area is appreciated. > > > > > > Because there seems to be agreement on the connection model, > > > Bryan Hill, the > > > H.gcp editor, will start pulling related sections from the > > > Megaco protocol > > > I-D into H.gcp. > > > > > > Glen will hold another audio call next week to see where we > > > stand, and to > > > look towards adding more sections to H.gcp from the Megaco > > > protocol I-D. > > > > > > For the ITU-T SG16 May meeting, H.gcp needs to contain: > > > - a connection model > > > - a set of commands > > > - a start on parameters for those commands > > > - generic syntax > > > - and a list of issues to resolve. > > > > > > > > > Protocol timetable: > > > -------------------------- > > > IETF Megaco: > > > - Proposed Standard by summer/99 > > > - interoperability testing in fall/99 > > > - Draft Standard in Feb/2000 > > > > > > This matches up closely with the ITU-T SG16 schedule: > > > - planning to get H.gcp determined in May/99 > > > - planning to get H.gcp decided in Feb/2000 > > > > > > IETF/ITU collaboration: > > > ------------------------------- > > > Question raised: will the two protocols be identical? > > > > > > Tom Taylor proposes two options: > > > 1) SG16 and Megaco completely agree on the protocol > > > requirements. If this is > > > the case, the protocol will be identical > > > > > > 2) Each group has some requirements that are different from > > > the other group. > > > In this case, there would be agreement on a core > protocol, and then > > > additional parts would be defined by each group. > > > > > > BUT how to do this in practice? Tom said that if a huge > > > roadblock comes up > > > again, we would form a new design team to work out a solution. > > > > > > Tom asked whether the group on the call agreed that the > > > Megaco protocol I-D > > > was a reasonable basis for H.gcp. Feeling was that it is, but > > > that we need > > > to do multimedia call walkthroughs. Mike Buckley had some > > > concern about the > > > definition of a context, but thought that the basic model > is workable. > > > Mauricio Arango thought it was a good model for multimedia. > > > Ami Amir raised > > > issue about associating contexts. Glen asked the H.320 > > > experts to look at > > > the protocol and see if we need to modify the connection model. > > > > > > > > > Next audio call: > > > ---------------------- > > > Probably next Thursday April 8/99, same time. Confirmation of > > > date & time > > > and the call details will be out later this week. > > > > > > > > > Use of mailing lists: > > > --------------------------- > > > It was agreed that we would try to keep all technical > > > discussion of the > > > Megaco protocol on the megaco(a)baynetworks.com mailing list. > > > > > > Invitations to audio calls, and audio call minutes will be > > > sent to both the > > > megaco(a)baynetworks.com and to the ITU-SG16(a)mailbag.intel.com > > > mailing lists. > > > > > > Tom Taylor took the action of posting to each list, how to > > > join the other > > > one. > > > > > > Detailed minutes: > > > ------------------------ > > > Brian Rosen presented the Megaco protocol draft > > > (ftp://www.ietf.org/internet-drafts/draft-ietf-megaco-protocol > > > -00.txt). He > > > first noted that this draft is open for discussion. It is not > > > cast in stone. > > > If changes need to be made to any part, they will be > made, if they are > > > deemed necessary to satisfy the requirements of the protocol, > > > and agreed to > > > by the group. > > > > > > 1. New connection model > > > - concept of a termination - have permanent (e.g. DS0) and > > > ephemeral (e.g. > > > RTP port) terminations > > > - a termination is named with a terminationId, this name can > > > have wildcards, > > > for example to allow the MG to choose the actual physical > > > termination, or to > > > request notification of an event that occurs on any DS0 > > > - concept of a context - can add, subtract, modify > terminations in a > > > context. A context is created when the first termination is > > > added to it, and > > > goes away when the last termination is subtracted from it. > > > - a context can have parameters associated with it - for > > > example, a video > > > mixing context may have parameters to describe how the video > > > is to be mixed > > > - mosaic, or current speaker/last speaker, ... > > > - a termination class defines parameters on a typical > > > termination - e.g. DS0 > > > Termination Class, RTP Termination Class > > > - Signals can be attached to a termination class, events can > > > occur at a > > > termination class, and the MGC can specify which ones it > wants to be > > > notified about. > > > - packages define signals and events > > > - a termination class can have more than one package that > apply to it > > > - event naming structure allows package name to be put in > > > front of the event > > > name > > > - question: how do you apply a call waiting tone? - answer - > > > it is a signal > > > that you apply to a termination > > > > > > 1.1 Proposed Changes and Issues: > > > a. Tom Taylor proposed a more general definition for > context: every > > > termination in a context has connectivity with all other > > > terminations in the > > > context. > > > > > > b. Raised by Mauricio Arango: you may want to be able to > > > create a context > > > with parameters before adding any terminations to it - (e.g. > > > turing machine) > > > - may want to mark a context with the max # of terminations > > > at creation > > > time. - BUT this may bring lack of flexibility - may be > > > better to let the MG > > > decide, as new terminations are added to a context, whether > > > it is able to > > > mix them in. For example, instead of marking a context with > > > one particular > > > type of codec, it is more flexible to let the MG decide what > > > transcoding > > > needs to be done in a context as a function of the types of > > > terminations > > > added to it. > > > > > > c. Raised by a few people: we need to see whether we need a > > > meta definition > > > of a "call" in the MG, so that the MG can link together > > > related contexts. > > > May be needed for lipsynch between a call's video context and > > > its audio > > > context. Instead of introducing a callId, this could be done using > > > parameters on each context referring to the other one. > > > Benefit of a callId > > > is that the MGC can bring down the entire call by just > > > referring to the > > > callId. (Note: "call" may be the wrong word - if we need it, > > > let's try to > > > invent a new name). > > > > > > d. Raised by Steve Davies: with H.320, the MG has one > > > physical termination > > > with audio, video and data on it - can a termination be in > > > more than one > > > context? no - so need to separate the different media out of > > > this physical > > > termination before creating the contexts. > > > > > > e. Raised by Tom Taylor: need to see whether it is > feasible to have > > > decomposed H.320 gateways - if it is necessary (people say > > > yes), then need > > > to be sure the Megaco protocol can handle it. > > > > > > > > > 2. Commands > > > - grouped into commands within an action per context, and > one or more > > > actions are grouped into a transaction. Transaction is > all or nothing. > > > - Add, Modify, Subtract each can contain local and remote > terminiation > > > descriptors, signalling descriptor, an events descriptor, and > > > a digit map > > > descriptor > > > - question on how to change an event description for a > > > termination - answer: > > > use Modify - can do it within a context, or outside a context > > > - if it is > > > outside the context (i.e. using the NULL context), then that > > > is how you > > > change the default parameters for that termination. > > > - MGCP's NotificationRequest is now covered in Modify > > > > > > 3. Multimedia and Contexts and Terminations > > > - a termination only belongs to one context > > > - for multimedia, there is one context per media type > > > - just as you have separate RTP flows for different media > > > types, you have > > > separate contexts. > > > > > > 3.1 Issues > > > a. Paul Sijben noted that when you try to use the Megaco > protocol with > > > H.320, there may be problems with the model - Paul will bring > > > these up on > > > the mailing list. > > > > > > Also, see Issue c in 1.1 above. > > > > > > 4. H.245 & SDP > > > - Tom Taylor explained that H.245 has at least 2 purposes: 1) > > > for capability > > > negotiation, and 2) for specification of open logical > > > channel. The scope of > > > the Megaco protocol is 2). Capability negotiation may use > > > H.245 between > > > MGCs, but the Megaco protocol is between MGC and MG. SDP may > > > be good enough > > > to be used between the MGC and the MG. Discussion still open > > > here. Need to > > > allow for an environment where H.245 may not be involved. > > > - with H.263 - H.245 provides a tag to link together 2 RTP > > > streams - need to > > > be able to carry this tag from the MGC to the MG. > > > > > > 5. underspecifying termination descriptors > > > - can be used as a way to tell the MG to use default > values for the > > > termination > > > - a termination learns its default values at MG boot-up time > > > - MGC can change these values using Modify with context > set to NULL. > > > > > > 6. underspecifying terminationIds > > > - provides a way of setting default parameters for a T1 > for example > > > > > > 7. Case: two audio contexts - in different MGs, and in the same MG > > > - can the connection model handle this? Yes > > > - protocol should need to keep track of where resources are. > > > - it is up to the MGC to know what contexts are associated > > > with a call. > > > > > > 8. overview of Audit, Notify, ServiceChange > > > - ServiceChange - MG can use it upon reboot, to register > > > itself with an MGC > > > - MG knows which MGC to send this msg to from some method > > > outside the scope > > > of this protocol (pre-provisioned, for example). > > > - MGC learns capabilities of MG using Audit. - can learn codecs > > > > > > 8.1 Issue > > > - need a way for MGC to learn the QUANTITY of codecs an MG has! > > > > > > 9. overview of Security > > > - this is security between an MGC and an MG > > > - interim method is specified for when an MG does not have IPSEC > > > > > > 10. Question on scope of the protocol > > > - check the requirements draft: > > > ftp://standards.nortelnetworks.com/megaco/docs/minn99 > > > - Steve Davies brought up point that some aspects of the > > > Megaco protocol > > > overlap with Policy server protocol proposals. > > > > > > 11. Can MG do coded renegotiation? > > > - David Featherstone asked if an MG can negotiate use of a > > > new codec on its > > > own > > > - Brian Rosen answered that with AAL2 profiles, the MG can > > > > > > Issue: > > > a. MGC may need to be involved - for example if the Quality > > > goes down too > > > low, call may no longer be billable. Solution - create an > > > event to notify > > > the MGC for this case. > > > > > > 12. How does the MGC find out RTP interfaces? > > > - should be able to do this using Audit in the NULL context. > > > > > > 13. IVR - still open for discussion > > > - view IVR as a termination > > > - issue is how much signalling effort do you need to add to > > > the protocol? > > > - simply playing msgs is ok - they just look like events > > > - problem is when you want to put time and money values into > > > it for example, > > > you have x minutes left on your calling card. - this may be > > > out of the scope > > > of the Megaco protocol > > > > > > 14. QoS reservation > > > - needs more discussion > > > > > > ****see Meeting summary above for audio call conclusions. > > > > > > end of minutes. > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > ------------ > > > Nancy M. Greene > > > Internet & Service Provider Networks, Nortel Networks > > > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > > > > > -- > Paul Sijben Telno:+ 31 35 687 4774 Fax:+31 35 687 5954 > Lucent Technologies Home telno: +31 33 4557522 > Forward Looking Work e-mail: sijben(a)lucent.com > Huizen, The Netherlands internal http://hzsgp68.nl.lucent.com/ >

2 1

H.320 gateways
by John Segers 30 Mar '99

30 Mar '99

People, In yesterday's conference call, the subject of H.320 GWs was raised briefly. In my opinion, the connection model and protocol should be able to deal with H.320. I would like to continue discussion on it on the mailing list. H.320 allows a user to have a session with both audio and video on a single 64 kbit/s channel such as an ISDN B-channel. The same channel carries some signalling information (frame alignment, bitrate allocation). To a MG supporting H.320, this means that on a single endpoint, three streams can come in, carrying different types of media. The current connection model of megaco/H.gcp does not cater to this. I see two possible solutions: The first is to allow multiple media in one context and to describe for terminations the logical streams they carry. In a picture: +----------+ | | | +--------- signalling (FAS, BAS) | | B-channel ==========+ +--------- audio (16 kbit/s) | | | +--------- video (46.4 kbit/s) | | +----------+ The second solution is to have separate terminations for the different streams. They would all "connect to" the same physical endpoint. In order to properly identify the terminations, it is necessary to have logical names for them. The physical endpoint they connect may have the hierarchical name proposed in the megaco document. Another example of a H.320 session is the case of two B-channels being used for an audiovisual call. The following frame structure is then possible. +--------------------------++-----------------------+ | Channel 1 || Channel 2 | +-----+--+--+--+--+--+--+--++--+--+--+--+--+--+--+--+ |Bit 1|B2|B3|B4|B5|B6|B7|B8||B1|B2|B3|B4|B5|B6|B7|B8| +-----+--+--+--+--+--+--+--++--+--+--+--+--+--+--+--+ 1 | a1 |a2|a3|a4|a5|a6|v1|F ||v2|v3|v4|v5|v6|v7|v8|F | 2 | a7 |a8|a9|a |a |a |v9|F ||v |v |v |v |v |v |v |F | 3 | a |a |a |a |a |a |v |F ||v |v |v |v |v |v |v |F | 4 | a | | | | |a |v |F ||v | |v |F | 5 | a | | | | |a |v |F ||v | |v |F | 6 | a | | | | |a |v |F ||v | |v |F | 7 | a | | | | |a |v |F ||v | |v |F | 8 | a | | | | |a |v |F ||v | |v |F | +---------------------------------------------------+ 9 | a | | | | |a |v |B ||v | |v |B | 10 | a | | | | |a |v |B ||v | |v |B | 11 | a | | | | |a |v |B ||v | |v |B | 12 | a | | | | |a |v |B ||v | |v |B | 13 | a | | | | |a |v |B ||v | |v |B | 14 | a | | | | |a |v |B ||v | |v |B | 15 | a | | | | |a |v |B ||v | |v |B | 16 | a | | | | |a |v |B ||v | |v |B | +---------------------------------------------------+ 17 | a | | | | |a |v |v ||v | |v |v | . . . 80 | a | | | | |a |v |v ||v | |v |v | +---------------------------------------------------+ (a=audio, v=video, F=FAS, B=BAS). We see that the video stream is split up over two channels. In order to cater to this, it seems we have to allow terminations to receive media from and send it to multiple physical endpoints. The two approaches outlined above can both be extended to allow this. Both extensions will lead to the introduction of logical names for terminations. In the first approach there will be one termination "containing" two B-channels on one side and three logical streams on the other. In the second approach there will be three terminations, the one for the video stream referencing both B-channels, the ones for signalling and audio referencing only channel 1. The second approach allows us to keep separate contexts for different media types. It is then easy to delete, for instance, the video part of a session (session used loosely to desribe the contexts for the audio and video). The first approach groups the streams coming from/going to one user, making it possible to remove a user from a context more easily. Personally, I can't decide which approach I would prefer. How do others feel about these ideas? 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

Megaco Protocol - IETF/ITU conf call minutes
by Greene, Nancy-M [CAR:5N10:EXCH] 29 Mar '99

29 Mar '99

Here are the minutes from the call today. Please email me any corrections. I tried to pair comments made with the person that made them - I may have made some errors, and I know I missed the names of some of the people commenting. Nancy (ngreene(a)nortelnetworks.com) ----------------------------------------------------------- Megaco Protocol presentation to IETF megaco and ITU SG16 participants March 29/99 10am-12pm EST ================================================= Present: The number of ports being used went as high as 47, and was about 45 on average. Number of participants was higher since a number of people were sharing ports. Chair of the call: Glen Freundlich (ggf(a)lucent.com) Minutes: taken by Nancy Greene (ngreene(a)nortelnetworks.com) NOTE: In keeping with IETF and ITU procedures, the audio call cannot make binding decisions. It is a tool for the chairs and editors, and the participants of both the IETF and ITU working groups, to gauge support for the protocol, and to raise issues with the protocol. Issues may be raised in either an audio call, or on the mailing list (megaco(a)baynetworks.com) These minutes are going to both the Megaco and ITU-SG16 mailing lists. Meeting summary: -------------------------- Glen Freundlich summed up results of the meeting. The goal of the meeting was two fold: 1) it was the first opportunity for people to look at the output from the Megaco protocol design/drafting group. 2) it was an opportunity for people to pose questions on the draft. He saw no opposition to the connection model proposed in the Megaco protocol I-D (ftp://www.ietf.org/internet-drafts/draft-ietf-megaco-protocol-00.txt) To date, the Megaco protocol I-D has been run through audio call scenarios for 3-way call, for call waiting, ... However, it needs to be tested with multimedia scenarios. Any input in this area is appreciated. Because there seems to be agreement on the connection model, Bryan Hill, the H.gcp editor, will start pulling related sections from the Megaco protocol I-D into H.gcp. Glen will hold another audio call next week to see where we stand, and to look towards adding more sections to H.gcp from the Megaco protocol I-D. For the ITU-T SG16 May meeting, H.gcp needs to contain: - a connection model - a set of commands - a start on parameters for those commands - generic syntax - and a list of issues to resolve. Protocol timetable: -------------------------- IETF Megaco: - Proposed Standard by summer/99 - interoperability testing in fall/99 - Draft Standard in Feb/2000 This matches up closely with the ITU-T SG16 schedule: - planning to get H.gcp determined in May/99 - planning to get H.gcp decided in Feb/2000 IETF/ITU collaboration: ------------------------------- Question raised: will the two protocols be identical? Tom Taylor proposes two options: 1) SG16 and Megaco completely agree on the protocol requirements. If this is the case, the protocol will be identical 2) Each group has some requirements that are different from the other group. In this case, there would be agreement on a core protocol, and then additional parts would be defined by each group. BUT how to do this in practice? Tom said that if a huge roadblock comes up again, we would form a new design team to work out a solution. Tom asked whether the group on the call agreed that the Megaco protocol I-D was a reasonable basis for H.gcp. Feeling was that it is, but that we need to do multimedia call walkthroughs. Mike Buckley had some concern about the definition of a context, but thought that the basic model is workable. Mauricio Arango thought it was a good model for multimedia. Ami Amir raised issue about associating contexts. Glen asked the H.320 experts to look at the protocol and see if we need to modify the connection model. Next audio call: ---------------------- Probably next Thursday April 8/99, same time. Confirmation of date & time and the call details will be out later this week. Use of mailing lists: --------------------------- It was agreed that we would try to keep all technical discussion of the Megaco protocol on the megaco(a)baynetworks.com mailing list. Invitations to audio calls, and audio call minutes will be sent to both the megaco(a)baynetworks.com and to the ITU-SG16(a)mailbag.intel.com mailing lists. Tom Taylor took the action of posting to each list, how to join the other one. Detailed minutes: ------------------------ Brian Rosen presented the Megaco protocol draft (ftp://www.ietf.org/internet-drafts/draft-ietf-megaco-protocol-00.txt) He first noted that this draft is open for discussion. It is not cast in stone. If changes need to be made to any part, they will be made, if they are deemed necessary to satisfy the requirements of the protocol, and agreed to by the group. 1. New connection model - concept of a termination - have permanent (e.g. DS0) and ephemeral (e.g. RTP port) terminations - a termination is named with a terminationId, this name can have wildcards, for example to allow the MG to choose the actual physical termination, or to request notification of an event that occurs on any DS0 - concept of a context - can add, subtract, modify terminations in a context. A context is created when the first termination is added to it, and goes away when the last termination is subtracted from it. - a context can have parameters associated with it - for example, a video mixing context may have parameters to describe how the video is to be mixed - mosaic, or current speaker/last speaker, ... - a termination class defines parameters on a typical termination - e.g. DS0 Termination Class, RTP Termination Class - Signals can be attached to a termination class, events can occur at a termination class, and the MGC can specify which ones it wants to be notified about. - packages define signals and events - a termination class can have more than one package that apply to it - event naming structure allows package name to be put in front of the event name - question: how do you apply a call waiting tone? - answer - it is a signal that you apply to a termination 1.1 Proposed Changes and Issues: a. Tom Taylor proposed a more general definition for context: every termination in a context has connectivity with all other terminations in the context. b. Raised by Mauricio Arango: you may want to be able to create a context with parameters before adding any terminations to it - (e.g. turing machine) - may want to mark a context with the max # of terminations at creation time. - BUT this may bring lack of flexibility - may be better to let the MG decide, as new terminations are added to a context, whether it is able to mix them in. For example, instead of marking a context with one particular type of codec, it is more flexible to let the MG decide what transcoding needs to be done in a context as a function of the types of terminations added to it. c. Raised by a few people: we need to see whether we need a meta definition of a "call" in the MG, so that the MG can link together related contexts. May be needed for lipsynch between a call's video context and its audio context. Instead of introducing a callId, this could be done using parameters on each context referring to the other one. Benefit of a callId is that the MGC can bring down the entire call by just referring to the callId. (Note: "call" may be the wrong word - if we need it, let's try to invent a new name). d. Raised by Steve Davies: with H.320, the MG has one physical termination with audio, video and data on it - can a termination be in more than one context? no - so need to separate the different media out of this physical termination before creating the contexts. e. Raised by Tom Taylor: need to see whether it is feasible to have decomposed H.320 gateways - if it is necessary (people say yes), then need to be sure the Megaco protocol can handle it. 2. Commands - grouped into commands within an action per context, and one or more actions are grouped into a transaction. Transaction is all or nothing. - Add, Modify, Subtract each can contain local and remote terminiation descriptors, signalling descriptor, an events descriptor, and a digit map descriptor - question on how to change an event description for a termination - answer: use Modify - can do it within a context, or outside a context - if it is outside the context (i.e. using the NULL context), then that is how you change the default parameters for that termination. - MGCP's NotificationRequest is now covered in Modify 3. Multimedia and Contexts and Terminations - a termination only belongs to one context - for multimedia, there is one context per media type - just as you have separate RTP flows for different media types, you have separate contexts. 3.1 Issues a. Paul Sijben noted that when you try to use the Megaco protocol with H.320, there may be problems with the model - Paul will bring these up on the mailing list. Also, see Issue c in 1.1 above. 4. H.245 & SDP - Tom Taylor explained that H.245 has at least 2 purposes: 1) for capability negotiation, and 2) for specification of open logical channel. The scope of the Megaco protocol is 2). Capability negotiation may use H.245 between MGCs, but the Megaco protocol is between MGC and MG. SDP may be good enough to be used between the MGC and the MG. Discussion still open here. Need to allow for an environment where H.245 may not be involved. - with H.263 - H.245 provides a tag to link together 2 RTP streams - need to be able to carry this tag from the MGC to the MG. 5. underspecifying termination descriptors - can be used as a way to tell the MG to use default values for the termination - a termination learns its default values at MG boot-up time - MGC can change these values using Modify with context set to NULL. 6. underspecifying terminationIds - provides a way of setting default parameters for a T1 for example 7. Case: two audio contexts - in different MGs, and in the same MG - can the connection model handle this? Yes - protocol should need to keep track of where resources are. - it is up to the MGC to know what contexts are associated with a call. 8. overview of Audit, Notify, ServiceChange - ServiceChange - MG can use it upon reboot, to register itself with an MGC - MG knows which MGC to send this msg to from some method outside the scope of this protocol (pre-provisioned, for example). - MGC learns capabilities of MG using Audit. - can learn codecs 8.1 Issue - need a way for MGC to learn the QUANTITY of codecs an MG has! 9. overview of Security - this is security between an MGC and an MG - interim method is specified for when an MG does not have IPSEC 10. Question on scope of the protocol - check the requirements draft: ftp://standards.nortelnetworks.com/megaco/docs/minn99 - Steve Davies brought up point that some aspects of the Megaco protocol overlap with Policy server protocol proposals. 11. Can MG do coded renegotiation? - David Featherstone asked if an MG can negotiate use of a new codec on its own - Brian Rosen answered that with AAL2 profiles, the MG can Issue: a. MGC may need to be involved - for example if the Quality goes down too low, call may no longer be billable. Solution - create an event to notify the MGC for this case. 12. How does the MGC find out RTP interfaces? - should be able to do this using Audit in the NULL context. 13. IVR - still open for discussion - view IVR as a termination - issue is how much signalling effort do you need to add to the protocol? - simply playing msgs is ok - they just look like events - problem is when you want to put time and money values into it for example, you have x minutes left on your calling card. - this may be out of the scope of the Megaco protocol 14. QoS reservation - needs more discussion ****see Meeting summary above for audio call conclusions. end of minutes. -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

1 0

Re: Invitation to ITU/IETF audio call announcement on megaco prot ocol
by Nancy-M Greene 29 Mar '99

29 Mar '99

Just a reminder of the call details, and that the passcode is 131313# for the ITU/IETF audio call today. > CALL DETAILS: > DATE: Monday, March 29/99 > TIME: 10amEST till 12pmEST > NUMBER: 613-763-6338 > PASSCODE: 131313# > CHAIR: Nancy Greene > problems joining? Call 613-765-CONF (613-765-2663) > There are 90 ports, and no more than that. If you cannot get on the call because there are not enough ports, please be assured that minutes of the call will be published by the end of Monday EST. PLEASE share ports where possible if more than one person is calling from one location. If you have a comment to make, but can't make yourself heard on the call, or if you can't be on the call at all, just put your comment in an email msg to the mailing lists. Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > IMPORTANT: > *****The audio call cannot make any decisions. There will > certainly be people that won't be available for the call. > *****Comments sent to the mailing lists carry equal weight > to any discussions held in the audio call. > *****The minutes of the audio call will be published to the > mailing lists. > Ideally, the SG16 group would agree to as much of the > internet-draft as they can, and turn it into the current version of H.GCP. > The more we agree on between the two groups the better. > CALL DETAILS: > DATE: Monday, March 29/99 > TIME: 10amEST till 12pmEST > NUMBER: 613-763-6338 > PASSCODE: 131313# > CHAIR: Nancy Greene > > problems joining? Call 613-765-CONF (613-765-2663) > 90 ports have been booked. > NOTES: > * because of the potentially large # of people, no > tones will be used to mark people joining or leaving > * to improve the voice quality, it is important to > mute your phone when you are not speaking - press 63 to mute, and 66 to > unmute. > > Nancy Greene Bryan Hill > ngreene(a)nortelnetworks.com bhill(a)videoserver.com > > >

1 0

H.GCP and Megaco
by Roni Even 28 Mar '99

28 Mar '99

I read the Draft Megaco Protocol proposal. It still make me wonder how multimedia calls are going to be handled. I am sorry that I will not be able to attend the audio call because of other meeting but I have to questions I would like to raise. 1. Will the relation between a video and audio stream be managed in the Media gateway controller. 2. What about T.120 is it part of the media streams and if so how is it decomposed between the media gateway and the media gateway controller. Where do we run MCS, GCC. 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 ***************************************************

1 0

Megaco Requirements
by Tom-PT Taylor 28 Mar '99

28 Mar '99

Attached are two notes giving the outcome of a review of requirements at the Megaco meeting two weeks ago. I'm sorry I didn't sent this material out to the SG 16 list earlier. I also attach a set of ATM-related requirements which the Multi-Service Switching Forum (MSF) provided to Megaco. It's important that we determine whether Q. 14/16 and Megaco have the same view of requirements. I've asked Glen Freundlich for time to probe the issue on tomorrow's H.GCP conference call. The dialogue can continue by E-mail. In the end, I hope we can determine a core set of requirements agreed by both groups, plus, if necessary, additional separately-documented requirements which are specific to one group or the other. <<Megaco Requirements>> <<Requirements Part II>> <<draft-ietf-megaco-msf-reqs-00.txt>> Tom Taylor E-mail: taylor(a)nortelnetworks.com (internally Tom-PT Taylor) Tel.: +1 613 765 4167 (internally 395-4167) This is frequently forwarded to my residence.

1 0

h.341 version 7
by George Kajos 26 Mar '99

26 Mar '99

Hi folks, I put the latest document in the avc-site\incoming directory on the picturetel site as h341wht7.[zip,doc]. The changes have been those of an editorial nature resulting from email of Mr. Shulman, Ms. Gafni, and Ms. Shah. The document includes content changes approved from the Monterey SG-16 meeting. Please review the document for correctness. The zipped version is also inserted below: Thanks, George Kajos gkajos(a)videoserver.com VideoServer Inc. 63 Third Avenue Burlington, MA 01803 phone: 781-505-2193 fax: 781-505-2101

1 0