- sg16-avd - lists.packetizer.com

Re: Transport issue (was: audio call Thursday: Minutes)
by Krishna Kurpati 09 Apr '99

09 Apr '99

I think both TCP and UDP should be provided as options. Particularly with Trunking Gateways TCP can be used as transport mechanism. Since there would be less number of these gateways (in most cases two or four per Call Agent) there will be less number of connections to manage. TCP provides better communication with Trunking gateways in that there is no need to maintain timers and retransmission acks for large number of transactions between Call Agent and Trunking gateway. Three-way hand shaking … [View More]

1 0

Event reporting (was audio call Thursday: Minutes)
by Christian Huitema 08 Apr '99

08 Apr '99

> 5) event handling > - currently an event is identified to the MGC with an eventId - Paul > Sijben suggested that it would be better to use a terminationId Sorry for missing the call, but let's comment on that specific point. We discussed the event reporting model at length during the IETF meetings and in the following week, and I don't beleive that there is any advantage in opening the debate again. Termination Id and event names just do not belong to the same space. Terminations … [View More]

3 2

Transport issue (was: audio call Thursday: Minutes)
by Christian Huitema 08 Apr '99

08 Apr '99

> 7) transport issues > There was discussion on what to use for interoperability purposes until the > actual transport is agreed on. Some people wanted to mandate TCP for the MG, > others said UDP + the message acks, + the addition of timers would be > better. Are there MG manufacturers that do not want to put TCP in their MGs, > even if only for demonstration purposes? If there is opposition to TCP even > for demonstration purposes, then we would go with UDP + message acks,… [View More]

1 0

audio call Thursday: Minutes
by Nancy-M Greene 08 Apr '99

08 Apr '99

Minutes of the IETF/ITU Megaco/H.GCP audio call held April 8, 1999, 11am-1pm EDT 22 people participated, with participants from IETF Megaco, and from ITU-T SG16. Topics discussed: a) issues with the current Megaco protocol internet-draft (draft-ietf-megaco-protocol-00.txt) b) status on folding this work into H.gcp c) report on US Study Group D meeting April 6th/99 d) miscellaneous Action items: i) Next version of documents: April 9th: Bryan Hill will release the current version of H.gcp … [View More]April 16th: Brian Rosen will release an new version of the Megaco protocol internet-draft. He will coordinate with Bryan Hill, to also get out a new version of H.gcp at that time that is as identical as possible to the new internet-draft. ii) Tom Taylor volunteered to produce write-up explaining two approaches for handling H.320 gateways - input will come from email msgs sent out on this topic by Brian Rosen and Paul Sijben. iii) Tom Taylor will put together an Issues List, where each issue is described, zero or more resolutions proposed, and there will be a tag marking the issue as open or closed. All editor's notes will be pulled out of the body of the internet-draft/H.gcp, and put in the issues list, with references back to the internet-draft. The issues list will be included in each revision of the internet-draft/H.gcp. Next meeting: - no date was set for an audio call. There was some discussion on having one some time before April 21st. If one is scheduled, it will be announced on the ITU-SG16 and megaco reflectors. Detailed report: Brian Hill opened the meeting. a) issues with the current Megaco protocol internet-draft (draft-ietf-megaco-protocol-00.txt) As stated above, Tom Taylor will put together an Issues List, where each issue is described, zero or more resolutions proposed, and there will be a tag marking the issue as open or closed. All editor's notes will be pulled out of the body of the internet-draft/H.gcp, and put in the issues list, with references back to the internet-draft. The issues list will be included in each revision of the internet-draft/H.gcp. Issues discussed in the audio call today: 1) association of contexts and terminations - is the context model, with one media type per context, adequate for multimedia? Tom Taylor says he believes the current context model with one media type per context is adequate. Brian Rosen explained that keeping it this way simplifies things for the common case where there is just one media type per call (i.e. audio). Paul Sijben would still prefer to allow multiple media types per context. When there was just one media type, the fields identifying media type, or separate media streams would be optional. Brian Rosen is still not convinced. Conclusion: Tom Taylor volunteered to produce a write-up explaining the two approaches for handling H.320 gateways - input will come from email msgs sent out on this topic by Brian Rosen and Paul Sijben. We agreed that figures for this discussion can be distributed in pdf instead of ascii. Discussion on what you would need to synchronize between contexts: - lip synch - issue - do you link contexts, or do you link a particular termination in a context to a particular termination in another context? How do you know that the video stream going out is the one that you want to lip sync with the audio stream going out? If you were lipsynching the current speaker and you knew that both the audio and video were of the current speaker, you could lipsync the contexts. But what if the video stream going out was NOT the one related to the audio? - synchronize closed captioning - synchronize the switching of streams being sent based on current speaker 2) H.245 capability negotiation Tom Taylor explained that the capability negotiaton stage is done between MGCs, and thus does not need to be expressable in the Megaco protocol - this negotiation is done BEFORE connection setup. Audit allows the MGC to discover what capabilities the MG has, but it does not give information on mutually exclusive choices based on processing power availability, for example. Need to walk through the example of Test Case 1 that Tom put out before the last IETF meeting, where the terminating MG may choose G.711 or G.729 - does the originating MG reserve both G.711 and G.729 for the termination, or just one of the two, and then modify it based on what the terminating MG chose? The test case allows G.711 in one direction and G.729 in the other. 3) attributes per termination class - these need more detail 4) how to extend the protocol - this needs to be spelled out 5) event handling - currently an event is identified to the MGC with an eventId - Paul Sijben suggested that it would be better to use a terminationId 6) terminationIds - there was a question whether terminationIds were logical or physical, i.e., would you put the word audio in a terminationId to make it a logical name? The answer was NO, a terminationId is a name of a physical termination, not a logical one. 7) transport issues There was discussion on what to use for interoperability purposes until the actual transport is agreed on. Some people wanted to mandate TCP for the MG, others said UDP + the message acks, + the addition of timers would be better. Are there MG manufacturers that do not want to put TCP in their MGs, even if only for demonstration purposes? If there is opposition to TCP even for demonstration purposes, then we would go with UDP + message acks, + timers. Chip Sharp reminded us that SGCP worked just fine with UPD, acks, and timers. ===> An issue for the mailing list. 8) security issues - no one had issues with security as it is described in the Megaco protocol internet-draft 9) syntax issues - discussion on this issue was deferred 10) Handling of NAS - can the protocol handle dial-out? this should be no problem - indication that the NAS wishes to dial out would be an event from the NAS (MG) to the MGC (NAS Controller), then the MGC issues an Add into a new context. - if the MGC does directory lookup to an AAA server, and there are Radius attributes to pass to the NAS, these need to be spelled out ===> need to make sure the foundations are in place to handle NAS. If termination classes, etc. for NAS are not ready for this internet-draft, they can go in as a separate RFC. But we will try to get them ready in time. b) status on folding this work into H.gcp As mentioned in the Action Items list above, Brian Hill, the H.gcp editor, will be releasing the current version of H.gcp tommorrow. It has much of the Megaco internet-draft folded into it. Everyone agreed that we want to keep these two protocols aligned, and identical if at all possible. When Brian Rosen releases a new version of the internet-draft by April 16th, he will coordinate with Bryan Hill to get this version into a new version of H.gcp as well. A question was asked on what a determined document means in the ITU? Tom Taylor answered that it means the technical directions are firmly set. A document that is to be decided at an ITU meeting must be ready four months before the actual meeting. In this case, it means it must be ready by Nov/99 (white paper deadline) to be decided at the Feb/2000 SG16 meeting. If interoperability testing of the protocol starts in early fall, there will be time to feed any corrections needed into the protocol before the Nov/99 white paper deadline. With all this cooperation, there is a feeling that there is a good chance to get one common protocol document between the IETF and the ITU. c) report on US Study Group D meeting April 6th/99 It seems there is still an issue that the US may oppose determining a document they haven't seen yet, unless there is "overriding industry interest" in having the document determined. So, any US company interested in having H.gcp determined should make their interest in determining H.gcp known. d) miscellaneous Chip Sharp asked who is using H.226. No one on the call was. Meeting Conclusion: See above for action items. -end of the meeting- Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com [View Less]

1 0

PER ASN Encode of Open type elements
by Manoj Paul 07 Apr '99

07 Apr '99

We would like to seek opinion about the PER ASN encoding of open type elements (such as extension additions in sequence/choice etc.). Such an encoding requires unconstrained length "len" to be appended before the actual field-list of open type element, where "len" is the number of octets in open type element field list encoding. There seem to be the following ways to achieve this: a) Keep encoding the open type element and when it's encoding is finished, count the number of … [View More]

2 1

Re: ASN.1 vs Text
by Paul Long 07 Apr '99

07 Apr '99

The experiment should implement the entire protocol and include a large set of messages. The syntax should then be extended in various ways. Text encoding is seductive. At first, text looks easier than ASN.1, but as more complex structures are needed and the syntax grows, it becomes cumbersome and error-prone. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Tom-PT Taylor [SMTP:taylor@NORTELNETWORKS.COM] Sent: Wednesday, March 31, 1999 9:17 PM … [View More] To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: ASN.1 vs Text 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 [View Less]

2 1

joining the megaco list
by Nancy-M Greene 07 Apr '99

07 Apr '99

Some of you have been asking how to join the IETF Megaco working group mailing list. Here is how: Send a message to majordomo(a)baynetworks.com with subscribe megaco end in the message body. Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

1 0

Re: Firewalls [was: H.320 gateways a MEGACO / ITU]
by Melinda Shore 07 Apr '99

07 Apr '99

There's an awful lot of overlap between HFCI and SOCKS. Additionally, HFCI is still rather incomplete yet has some enormously useful stuff in it, so I'm hopeful that w'll be able to resolve these two over the next 3-6 months within the IETF or elsewhere. Melinda At 12:09 PM 4/6/99 +0100, Iain Barker wrote: >One solution would be not to expect the firewall to 'find' >which ports to open, but instead for the gateway to inform >the firewall of the nature of the underlying connection. &… [View More]

2 1

audio call Thursday
by Bryan Hill 06 Apr '99

06 Apr '99

We decided at the last audio call March 29th/99 (minutes went out the same day), to hold the next call Thursday April 8th/99. The goal of the call is to move towards agreement for content of H.GCP, based on the draft Megaco protocol (draft-ietf-megaco-protocol-00.txt). As well, the call is a place where issues with the protocol can be discussed, and questions answered. As before, no "decisions" can be made on the call. Minutes will be posted to both itu-sg16(a)mailbag.intel.com <mailto:itu-… [View More]

1 0

Re: Issues Around Support of Multimedia
by Christian Huitema 06 Apr '99

06 Apr '99

Tom, I agree with your analysis of requirements. We need to support multuimedia conference, yet we should not loose sight that H.320 is only a very small fraction of the initial market, and that we should not unduly increase the complexity of an audio only system. I also agree that we have to support multicast, and that we have to provide for fancy control of (at least some) conferences. The architecture we had in mind, as Brian explained, is to have one context per media. This brings in the … [View More]notion of a "context type" -- an audio bridge, a video bridge, a T.120 bridge all behave somewhat differently. In fact, the particular realm of video bridging is prone to divisions such as "single image", "mosaic", "incrustations", which could be defined as context level parameters. In fact, a common practice on the MBONE is to carry several video streams on the same RTP association, using the SSRC as the stream identifier, and letting individual recipients select which video is displayed and which one is iconized. Short of that, conference control does not appear to be a real problem with the current spec. The mode parameter allows the MGC to specify the terminations that "contribute" to the mix (allowed to send) and the ones that only receive information. In a video bridge, the contributing terminations are sent in the mosaic, or multiplexed as RTP streams. In a T.120 bridge, the "master" termination is authorized to contribute, the other one remain passive. Synchronization of multiple context can be performed by the MGC: event reporting allows it to detect the last speaker, or video activity, or T.120 activity, and to issue MODIFY command that manage the conference accordingly. If the event/command chain is deemed to slow, then we will have to resort to a local script, a surrogate for the MGC. But there is more. Support for H.320 requires, in particular, the support for H.221 multiplexing of several streams onto a single carrier. That support is somewhat similar to the support of several DS0 inside a single DS1, or several B-Channels, albeit there are some obvious differences -- multiplexing parameters vary on a call per call basis, or even within a call. We have to express the notion that a specific termination, for the duration of a call, is "exploded" into a set of ephemeral terminations, each of which is then connected to a media specific context. This requires an additional mechanism, something like a 'demultiplexing context'. Demultiplexing has a symmetric, inverse multiplexing. This happens when an H.320 conference spans several B channels. It can also happen for data calls. In order to at least obtain the "warm and fuzzy feeling" that Fernando mentions, we have at a minimum to sketch out our solution to inverse multiplexing and demultiplexing, and maybe to propose one way to handle H.320. -- Christian Huitema ------------------------------ Please note my new address: huitema(a)research.telcordia.com http://www.telcordia.com/ [View Less]

1 0