- sg16-avd - lists.packetizer.com

FW: AW: Call hold and transfer in H.323 AnnexF. Too limited??
by Chris Purvis 06 Apr '99

06 Apr '99

All, I find it hard to believe that we can't do better (from the user's point of view) than the old black-phone view of the world whereby people have to type in various combinations of *s and digits to mean various different things to the local exchange. Most endpoints, after all, have pretty UIs. Now at the messaging level it may well make sense to have things APPEAR as if that (ie the typing of arcane sequences of digits) is what is happening - and it's possible that all we need to do to make that work in an interoperable way is to define what sequences of characters in the destination address in a setup message mean what sort of service. Do we start from a point such as "Setup with a single destination address which is e164 starting with '*' means arcane supplementary service", or define another alias type for "arcane supplementary service" or what? My aim is simply that an endpoint vendor should be ABLE to write things that do not require the user to understand bizarre control sequences, and will be able to access supplementary services wherever, and by whatever vendor, they are provided. Regards, Chris -- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. ENGLAND Phone: +44 1753 661 359 email: cpurvis(a)madge.com > -----Original Message----- > From: Espen Skjæran [mailto:Espen.Skjaeran@ERICSSON.COM] > Sent: 26 March 1999 6:42 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: AW: Call hold and transfer in H.323 AnnexF. Too limited?? > > > Hei, > > I do not think it is a bad thing if ISPs choose to control service > profiles/configuration outside of H.450. There are a lot > more flexible ways to transport data. Proven technologies > exist today which are > very flexible and extendible (HTTP, WAP, IVRs, etc). User > oriented services > might also include non-H.323 equipment (mobile, email, even a > SIP terminal!), so > confining it to H.450 and H.323 would limit the possibillity > for "fancy" > services significantly, thereby also limiting the > distribution of H.323. > > If a Call Forward service is put in the network, it turns > more into a user > oriented than an endpoint oriented service, and the > possibilities for extensions are huge. As soon as the "Call > Forward Unreachable" > is standardized, I might come up with a proposal for call > forward based on > week/time, and this will hardly ever stop. We need a flexible > mechanism for > controlling these services, not new detailed service specifications. > > As the mechanisms for a call forward done in the network does > not require the > same level of interactions as a terminal > oriented (or in-call) service, we do not need to follow the > same approach as > H.450, where services are specified in detail. > The H.450 approach makes the creation (and extension) of a > service a very > lenghty process, and is actually a great > obstacle to creativity and development of new user oriented > services. (Though > for in-call services I don't see any way around it...) > > Espen > > > "Derks, Frank" wrote: > > > Paul, > > > > you got my points exactly right. The reason that I weakened > by arguments by > > hinting at the ease of upgrade in an IP environment was to > avoid people > > coming back with this line of argument. Although using > "DTMF digits" as the > > means to access services may not be the most elegant one, > it is probably the > > simplest and it maps well onto a simple "blackphone" type > of terminal. If we > > do not provide for something fairly simple (both for the > users and the > > service providers) then the chances are that service > providers will come up > > with "(IP) Telephony unrelated" means to access services. > E.g. they could > > provide Web pages that allow customers to specify their > service behaviour. > > > > Frank > > > > -----Original Message----- > > From: Paul E. Jones [mailto:paul.jones@TIES.ITU.INT] > > Sent: 22 March 1999 19:11 > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: AW: Call hold and transfer in H.323 AnnexF. > Too limited?? > > > > Frank, > > > > I do agree that two mechanisms for accomplishing the same > task is a bad > > idea. I, too, would rather see one mechanism employed-- we > do want to > > create interoperable equipment, after all. Unfortunately, > we already have > > two ways of doing "call hold"-- H.450.4 and "empty > capability sets" (see > > 7.6.2 of Annex F). > > > > The issues you raise with supplementary services echoes the > concerns of > > those also participating in the TIPHON work. Essentially, > service providers > > would like to be able to add new services without upgrading > software in the > > endpoints. Although it may be possible to upgrade IP phone > devices, I can > > assure you that the average person would never do that-- > once the phone is > > plugged in, it will stay there until it stops working. > More importantly, > > why would one want to require somebody who purchased a > hardware phone device > > to upgrade periodically? > > > > We need to engineer a solution so that the telephony > service providers can > > introduce new services without requiring software upgrades > in the endpoints. > > I would like to see SET device to take advantage of those > newly introduced > > services without software or hardware upgrades. > > > > Paul > > > > -----Original Message----- > > From: Derks, Frank <F.Derks(a)PBC.BE.PHILIPS.COM> > > To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> > > Date: Monday, March 22, 1999 5:45 AM > > Subject: Re: AW: Call hold and transfer in H.323 AnnexF. > Too limited?? > > > > >Folks, > > > > > >when talking about a Simple Endpoint Type, I think we > should aim for it to > > >be something that closely resembles a black phone. This > way it becomes a > > lot > > >easier to define what its capabilities are and it makes > life easy on the > > >users and on those companies that will actually make > (physical) IP-phones. > > >These phones should probably look and act like the normal > phones that are > > >currently being used. Looking at how most supplementary > services are > > >accessed in both the public and the private (PBX) > networks, I think it is > > >safe to say that in most cases we are talking about > "stimulus protocols". > > >I.e. DTMF digits are sent to an exchange and the exchange > interprets > > certain > > >digit sequences as being the invocation of some service > rather than a > > number > > >to be dialled. The big advantage over functional protocols > (like H.450.x) > > >being that services can be added from the exchange side, > without the > > >terminal having to be modified as well. > > > > > >Functional protocols never became a success in the ISDN > world and this may > > >end up to be the same in the IP world. However, having > said this, there is > > a > > >lot more potential for easy upgrading of e.g. terminal > software in this > > >domain, which reduces the side effects of functional protocols. > > > > > >It does not seem to make sense to define "alternative" > mechanisms to > > provide > > >services, so I would strongly opt for using H.450.x when > possible and using > > >a simple stimulus protocol otherwise. The latter would > allow service > > >providers to easily make services available and I see no > reason why this > > >should be standardised. In practice, today, we already see > that certain > > >digit sequences for service activation are identical in > several countries. > > > > > >Frank > > > > > >----------------------------------------------------- > > >Frank Derks |Tel +31 35 6893238 | > > >Advanced Development |Fax +31 35 6891030 | > > >Philip Business Communications |P.O. Box 32 | > > > |1200 JD Hilversum | > > > |The Netherlands | > > >----------------------------------------------------| > > >E-mail: mailto:f.derks@pbc.be.philips.com | > > >WWW: http://www.business-comms.be.philips.com | > > >----------------------------------------------------- > > > > > > > > > > > >-----Original Message----- > > >From: Klaghofer Karl ICN IB NL IP 7 > > >[mailto:Karl.Klaghofer@ICN.SIEMENS.DE] > > >Sent: 18 March 1999 22:36 > > >To: ITU-SG16(a)MAILBAG.INTEL.COM > > >Subject: AW: AW: Call hold and transfer in H.323 AnnexF. > Too limited?? > > > > > > > > >See comment below. > > > > > >Karl > > > > > >> -----Ursprüngliche Nachricht----- > > >> Von: Paul E. Jones [SMTP:paul.jones@TIES.ITU.INT] > > >> Gesendet am: Donnerstag, 18. März 1999 18:57 > > >> An: ITU-SG16(a)mailbag.cps.intel.com > > >> Betreff: Re: AW: Call hold and transfer in H.323 AnnexF. Too > > >> limited?? > > >> > > >> Karl, > > >> > > >> Unfortunately, I will have to disagree with your > comments. While it is > > >> true > > >> that the H.450 supplementary services could be utilized > in a SET device, > > I > > >> believe that introducing H.450 into a SET breaks the > spirit of that work. > > >> > > >> The goal of Annex F is to define a "Simple Endpoint > Type". There are > > >> simpler ways to put a call on hold and to transfer a > call. Introducing > > >> H.450 introduces a lot more complexity that I believe we > want to have. > > If > > >> Annex F is not sufficiently clear on how to simply > transfer a call or put > > >> a > > >> call on hold, we should work on that text-- I will > absolutely disagree > > >> with > > >> introducing H.450 into a SET device. > > > [Klaghofer, Karl PN VS LP3] Whatever you mean with > > "introducing" - > > >H.450 as I sayd in my previous mail is a way of providing > supplementary > > >services like call hold and call transfer to a SET device. > It IS already > > >part of the H.323 Annex F! > > >> Paul > > >> > > >> -----Original Message----- > > >> From: Klaghofer Karl ICN IB NL IP 7 > <Karl.Klaghofer(a)ICN.SIEMENS.DE> > > >> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> > > >> Date: Wednesday, March 17, 1999 3:27 PM > > >> Subject: AW: Call hold and transfer in H.323 AnnexF. Too > limited?? > > >> > > >> > > >> >Gunnar, > > >> > > > >> >You are referring to call hold and transfer in > conjunction with H.323 > > >> Annex > > >> >F SETs (Audio or Text) and clause 7.6 of H.323 Annex F. > > >> > > > >> >Talking about call hold, clause 7.6 of H.323 Annex F is > not needed for a > > >> SET > > >> >at all. Call Hold works for a SET as it is defined in H.450.4. > > >> > > > >> >Talking about Call Transfer, clause 7.6 of H.323 Annex > F is not needed > > >> for > > >> a > > >> >SET, if the transfer is executed by the endpoints as > defined in H.450.2. > > >> >Codec re-negotiation you are referring to is no problem > and takes place > > >> >between the transferred and the transferred-to > endpoint. This may cover > > >> your > > >> >case with wireless endpoints being involved. > > >> > > > >> >For call transfer, section 7.6 of H.323 Annex F is only > needed if the > > >> >gatekeeper or a proxy acts on behalf of the transferred > SET endpoint B. > > >> >However, media re-negotiation also should work here as > part of the > > >> fastStart > > >> >method. > > >> > > > >> >Regards, > > >> >Karl > > >> >------------------------------------------------ > > >> >Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL IP7 > > >> >Hofmannstr. 51, D-81359 Munich, Germany > > >> >Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 > > >> >e-mail: karl.klaghofer(a)icn.siemens.de > > >> > > > >> > > > >> > > > >> >> -----Ursprüngliche Nachricht----- > > >> >> Von: Gunnar Hellstrom [SMTP:gunnar.hellstrom@OMNITOR.SE] > > >> >> Gesendet am: Dienstag, 16. März 1999 23:01 > > >> >> An: ITU-SG16(a)mailbag.cps.intel.com > > >> >> Betreff: Call hold and transfer in H.323 AnnexF. > Too limited?? > > >> >> > > >> >> Dear multimedia experts. > > >> >> > > >> >> In my efforts to establish the simple IP voice and > text telephone Text > > >> >> SET, > > >> >> I came across a section in H.323 Annex F (Simple > Endpoint Type, TD11 > > in > > >> >> Monterey) that I feel is causing a functional > obstacle also to the > > >> voice > > >> >> users. Can anyone clarify if I am correct and why it > is specified the > > >> way > > >> >> it is. > > >> >> > > >> >> In section 7.6.1 and 7.6.2 it is specified:" The > Audio SET device > > >> shall > > >> >> then resume transmitting its media stream(s) to the transport > > >> address(es) > > >> >> newly indicated in the OpenLogicalChannel structures." > > >> >> I understand that this means that you cannot > re-negotiate audio > > coding, > > >> >> and > > >> >> you cannot add text conversation after rerouting the > call from a Voice > > >> >> only > > >> >> SET to a Text SET. > > >> >> > > >> >> Re-negotiating the audio coding will probably be a > desired function, > > >> e.g. > > >> >> when rerouting from a fixed to a wireless IP phone. > > >> >> Adding a data channel for text will also be a desired > function, after > > >> >> answering a call in an audio-only SET, and then > rerouting it to a > > >> >> text-capable SET. > > >> >> That action is very common in today's text telephone > usage, and I > > would > > >> >> expect it to be just as common in the IP telephony > world. You first > > >> >> receive > > >> >> the call in the terminal that is closest to you, and > then you get a > > >> reason > > >> >> to start text mode. Then you transfer the call to > another device with > > >> text > > >> >> capabilities, where you can switch mode. > > >> >> > > >> >> Questions: > > >> >> > > >> >> 1. Is that kind of call transfer that is handled by > the mechanisms in > > >> 7.61 > > >> >> and 7.6.2? > > >> >> > > >> >> 2. Are my conclusion right about the limitations? > > >> >> > > >> >> 3. Is this limitation a consequence of using Fast Connect? > > >> >> > > >> >> 4. Do you see any possibility to avoid the negative > effects of it - to > > >> >> make > > >> >> re-negotiation possible? > > >> >> > > >> >> 5. Is the specified functionality acceptable in the > voice world? If > > two > > >> >> devices have agreed on a voice coder, is it likely > that the third > > >> device > > >> >> supports it? Will this not create a lot of > unsuccessful call transfers > > >> >> where the users will have a no chance to understand > why they fail? > > >> >> > > >> >> ---- > > >> >> > > >> >> Another question area: > > >> >> > > >> >> 6. When selecting the transport protocol for the text > conversation, > > the > > >> >> current draft (APC 1504) specifies TCP or UDP. I > realize that there > > are > > >> >> situations where TCP must be avoided. One such situation is a > > >> sub-titled > > >> >> H.332 transmission. Also other multi-casting > situations is better off > > >> with > > >> >> a UDP based transport protocol. > > >> >> I am therfore now leaning towards using RTP as the > transport for text > > >> >> conversation. With RTP we can discover dropped frames > and possibly > > >> invent > > >> >> a > > >> >> mechanism to mark that event in the text stream for > T.140 to display. > > >> If > > >> >> we > > >> >> have less than 3 % dropped frames, I think the users > would accept it. > > >> >> > > >> >> 6.1 Do you agree that there are situations when TCP > should be avoided, > > >> and > > >> >> a UDP based protocol preferred? > > >> >> > > >> >> 6.2 Do you agree that RTP is a good alternative, with > a thin protocol > > >> for > > >> >> error indications to the user? > > >> >> > > >> >> 6.3 Most packets will carry only 1-4 characters . Can > anyone give me > > an > > >> >> indication on the expected packet loss rates in > different situations > > >> for > > >> >> such packets. Or a document giving such figures. Is > max 3% loss > > >> reachable? > > >> >> > > >> >> Please give your view on these questions. > > >> >> > > >> >> Best regards > > >> >> > > >> >> Gunnar Hellström > > >> >> ----------------------------------------------- > > >> >> Gunnar Hellstrom > > >> >> Representing Ericsson in ITU-T > > >> >> > > >> >> E-mail gunnar.hellstrom(a)omnitor.se > > >> >> Tel +46 751 100 501 > > >> >> fax +46 8 556 002 06 > ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com **********************************************************************

1 0

Re: Firewalls [was: H.320 gateways a MEGACO / ITU]
by Iain Barker 06 Apr '99

06 Apr '99

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. FYI, SIEMENS have a submission to TIPHON which disusses how a media gateway [H.323 in their example] can instruct the firewall which IP ports to allow through. http://docbox.etsi.org/tech-org/TIPHON/Document/TIPHON/05-9903-Philadelphia/ 12TD054.rtf -- Iain Barker International data, Nortel PND, Maidenhead SL64AG UK Note: The above posting may not represent the views of Nortel. -----Original Message----- From: Douglas Clowes [mailto:dclowes@OZEMAIL.COM.AU] Sent: 01 April 1999 02:14 To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Firewalls [was: H.320 gateways a MEGACO / ITU] [deletia] 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

1 0

Re: Issues Around Support of Multimedia
by Ami Amir 06 Apr '99

06 Apr '99

Hi Fernando, I think we should address at least one issue in detail: Support of multiple media streams (I am assuming that each media stream is a context) which are part of a single "Point to Point Call" (for lack of a better term) that are egressing through a MG into a single PSTN connection. This is relevant for gateways between PSTN and IP or for gateways between native ATM and IP. Relevant issues there: 1. Define that a context supports only one media stream (RTP) - equivalent to an H.245 logical channel. 2. Decide that when there is a need for an association between contexts that on the PSTN side are "joined", to use the RTP mechanisms (see Scott Petrack's comments). This will allow a "smart" MGC to do all the rest. Most of the other issues raised seem to me like re-inventions of wheels. If we try to enlarge the scope to make MEGACO a generic call control protocol for everything - we will end up re-writing H.323. Ami -----Original Message----- From: Fernando Cuervo [SMTP:cuervo@NORTELNETWORKS.COM] Sent: Tuesday, April 06, 1999 5:00 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Issues Around Support of Multimedia Tom, What are we supposed to do from the point of view of the charter? Would it suffice to have a warm-fuzzy feeling that the protocol is extensible (this could be possible by having one or more "reasonable" proposals to handle Context "behaviour" and sychronisation between contexts but not necessarily reaching an agreement on the "best" way to do it) Fernando > ---------- > From: Taylor, Tom-PT [CAR:5V00-I:EXCH] > Sent: April 5, 1999 12:09 PM > To: megaco(a)BayNetworks.COM; itu-sg16(a)mailbag.cps.intel.com > Subject: Issues Around Support of Multimedia > > I have suggested some directions for exploration of solutions to the > problem > of support of multimedia over the past week, but I suspect such > suggestions > go beyond my role as WG Chair. Hence I am taking a step backward and > simply > summarizing the issues for others to resolve. > > Issue 1: representation of connection topologies for multiple media types. > > It seems to me that contexts are not topologies themselves, but rather > represent envelopes within which different topologies will be realized > depending on the mode settings for the associated terminations. > > Requirements: > a) Coordinate between different media streams (e.g. for lip-synch, > stereo). > b) Represent degenerate cases simply (e.g. audio-only connections, > two-point connections). > c) Support multicast. > > Issue 2: support for different multipoint, medium-specific bridging > methods. > > For audio, the most obvious bridging method sums all inputs except that of > the party to which the signal is being sent. For video, one can have > continuous presence, most recent speaker, and probably lots of others. > > Issue 3: support for Chair-controlled conferences. > > We most assuredly do not want to develop yet another conference control > protocol. Nevertheless, we must understand conference control and how it > could affect the messaging between the MG and MGC. > > Issue 4: support for T.120 multipoint data conferencing service. > > T.120 assigns roles to individual nodes within a conference network. Can > the MG infer its role from the context cardinality (two-point vs. > multipoint), or is additional information required? > > Meta-issue: where do Megaco's interests stop and those of SG 16 take over? > Are we reaching the stage where some things have to be marked "for further > study", or do we work through all the issues now to make sure our base > solution will cover all needs? > > > 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

Re: Issues Around Support of Multimedia
by Fernando Cuervo 05 Apr '99

05 Apr '99

Tom, What are we supposed to do from the point of view of the charter? Would it suffice to have a warm-fuzzy feeling that the protocol is extensible (this could be possible by having one or more "reasonable" proposals to handle Context "behaviour" and sychronisation between contexts but not necessarily reaching an agreement on the "best" way to do it) Fernando > ---------- > From: Taylor, Tom-PT [CAR:5V00-I:EXCH] > Sent: April 5, 1999 12:09 PM > To: megaco(a)BayNetworks.COM; itu-sg16(a)mailbag.cps.intel.com > Subject: Issues Around Support of Multimedia > > I have suggested some directions for exploration of solutions to the > problem > of support of multimedia over the past week, but I suspect such > suggestions > go beyond my role as WG Chair. Hence I am taking a step backward and > simply > summarizing the issues for others to resolve. > > Issue 1: representation of connection topologies for multiple media types. > > It seems to me that contexts are not topologies themselves, but rather > represent envelopes within which different topologies will be realized > depending on the mode settings for the associated terminations. > > Requirements: > a) Coordinate between different media streams (e.g. for lip-synch, > stereo). > b) Represent degenerate cases simply (e.g. audio-only connections, > two-point connections). > c) Support multicast. > > Issue 2: support for different multipoint, medium-specific bridging > methods. > > For audio, the most obvious bridging method sums all inputs except that of > the party to which the signal is being sent. For video, one can have > continuous presence, most recent speaker, and probably lots of others. > > Issue 3: support for Chair-controlled conferences. > > We most assuredly do not want to develop yet another conference control > protocol. Nevertheless, we must understand conference control and how it > could affect the messaging between the MG and MGC. > > Issue 4: support for T.120 multipoint data conferencing service. > > T.120 assigns roles to individual nodes within a conference network. Can > the MG infer its role from the context cardinality (two-point vs. > multipoint), or is additional information required? > > Meta-issue: where do Megaco's interests stop and those of SG 16 take over? > Are we reaching the stage where some things have to be marked "for further > study", or do we work through all the issues now to make sure our base > solution will cover all needs? > > > 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

Issues Around Support of Multimedia
by Tom-PT Taylor 05 Apr '99

05 Apr '99

I have suggested some directions for exploration of solutions to the problem of support of multimedia over the past week, but I suspect such suggestions go beyond my role as WG Chair. Hence I am taking a step backward and simply summarizing the issues for others to resolve. Issue 1: representation of connection topologies for multiple media types. It seems to me that contexts are not topologies themselves, but rather represent envelopes within which different topologies will be realized depending on the mode settings for the associated terminations. Requirements: a) Coordinate between different media streams (e.g. for lip-synch, stereo). b) Represent degenerate cases simply (e.g. audio-only connections, two-point connections). c) Support multicast. Issue 2: support for different multipoint, medium-specific bridging methods. For audio, the most obvious bridging method sums all inputs except that of the party to which the signal is being sent. For video, one can have continuous presence, most recent speaker, and probably lots of others. Issue 3: support for Chair-controlled conferences. We most assuredly do not want to develop yet another conference control protocol. Nevertheless, we must understand conference control and how it could affect the messaging between the MG and MGC. Issue 4: support for T.120 multipoint data conferencing service. T.120 assigns roles to individual nodes within a conference network. Can the MG infer its role from the context cardinality (two-point vs. multipoint), or is additional information required? Meta-issue: where do Megaco's interests stop and those of SG 16 take over? Are we reaching the stage where some things have to be marked "for further study", or do we work through all the issues now to make sure our base solution will cover all needs? 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

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