November 1998 - sg16-avd - lists.packetizer.com

subscribing to H.323 mailing list
by Viswanath Math 01 Feb '99

01 Feb '99

Hi I would like to suscribe to your mailing list for discussions on H.323. Thanks Viswanath

3 2

Updated APC-1480 uploaded
by Douglas Clowes 29 Nov '98

29 Nov '98

As promised at Torino, an updated version of APC-1480 has been uploaded to the Incomming Directory. This version reflects recent changes which had been made to the Interline BEST protocol, but which had not been incorporated into the documentation. The main changes in the protocol have been the addition of a "Connection" concept where a single set of identification and authorisation information can be grouped with a set of possible destination transport addresses, to permit line-hunting with that set of identification and authorisation information across the destinations. By allowing repeated connection groups, different identification/authorisation sets allows line-hunting across different domains (which may require different Id/Auth sets). Also, an element PSTNInfo has been added specifically for the SCN to SCN VoIP scenario. Other changes have been fairly minor. TransactionIdentifier has been documented, and its serverData component has been changed to a sequence of nonStandardParameter to allow for the inclusion of server data from intervening domains (such as all domains in the aggregation point example in Annex G, Figure 6). Two multi-domain use cases have been added. One demonstrates the use of the Access Request to obtain address resolution and authorisation in the aggregation point type example. The other demonstrates the mechanism for line hunting, in GK-routed calls, both within a zone, and across domains. I hope these serve to further clarify some of the concepts within the protocol. I would be happy to answer further queries and provide further information. Regards, Douglas Clowes OzEmail Interline

1 0

Re: Tunneling in FACILITY
by Sengodan Senthil NRC/Boston 26 Nov '98

26 Nov '98

Pete, Your interpretation of the sentence would permit us to achieve what we want to do with no rewording. As Martin mentioned, we are trying to use the tokens and cryptoTokens field that comes with all H.225.0 message UUIEs to provide security services for H.245 messages. This then implies that whenever a H.245 message is to be sent, there is a "need" for transmission of a Q.931 message, since there is a "need" for using the tokens and cryptoTokens field of the Q.931 message UUIE. With that interpretation, we are set. Thanks. Regards, Senthil ---------- From: Mailing list for parties associ To: ITU-SG16 Subject: Re: Tunneling in FACILITY Date: Thursday, November 26, 1998 3:59PM The point is what we should do with the H.245 tunneling mode when there is no Facility message to be sent but we still want to secure the tunneled message with the ClearText and CryptoTokens. Idea is to send "dummy" information in the facility message containing at least some "useless" information. However, when the facility message would empty as specified in H.323v2 section 8.2.1 then the CryptoTokens and ClearTokens could not be used. Martin. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de | | Otto-Hahn-Ring 6 | 81730 Muenchen | __________________ | Germany ----------------------------------------------------------------------- > -----Original Message----- > From: Pete Cordell [SMTP:pete.cordell@BT-SYS.BT.CO.UK] > Sent: Donnerstag, 26. November 1998 12:48 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Tunneling in FACILITY > > Senthil, > > I think if what you are doing needs you send tokens etc., then the only > way to do this is to send a Q.931 message, which means that you need to > send a Q.931 message! Therefore I think the original version of the > sentence still holds. > > Or perhaps I am missing something! > > Regards, > > Pete > ================================= > Pete Cordell > BT Labs > E-Mail: pete.cordell(a)bt-sys.bt.co.uk > Tel: +44 1473 646436 > Fax: +44 1473 645499 > ================================= > > > >---------- > >From: Sengodan Senthil > >NRC/Boston[SMTP:sengodan@NASBPD01BS.NTC.NOKIA.COM] > >Reply To: Mailing list for parties associated with ITU-T Study Group > >16 > >Sent: 25 November 1998 21:37 > >To: ITU-SG16(a)MAILBAG.INTEL.COM > >Subject: Tunneling in FACILITY > > > >Folks, > > > >Section 8.2.1 of H.323 states: > > > >"If tunneling is being utilized and there is no need for transmission > >of a Q.931 message at the time an H.245 message must be transmitted, > >then a FACILITY message shall be sent with 'h323-message-body' set to > >'empty'." > > > >I would like to know - for the case where no Q.931 message needs to be > >sent - if there are any negative implications of setting the > >'h323-message-body' to 'facility' with 'reason' set to > >'undefinedReason'. This would enable the use of several fields that are > >available within the 'Facility-UUIE' structure - such as 'tokens' and > >'cryptotokens' - which would not be available if 'h323-message-body' is > >set to 'empty'. > > > >A rewording of the sentence as below would enable this: > > > >"If tunneling is .... a FACILITY message shall be sent and the > >'h323-message-body' should be set to 'empty'." > > > >Comments? > > > > - Senthil > > > >Senthil Sengodan > >Nokia Research Center, Boston > >

1 0

Re: Tunneling in FACILITY
by Euchner Martin 26 Nov '98

26 Nov '98

The point is what we should do with the H.245 tunneling mode when there is no Facility message to be sent but we still want to secure the tunneled message with the ClearText and CryptoTokens. Idea is to send "dummy" information in the facility message containing at least some "useless" information. However, when the facility message would empty as specified in H.323v2 section 8.2.1 then the CryptoTokens and ClearTokens could not be used. Martin. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de | | Otto-Hahn-Ring 6 | 81730 Muenchen | __________________ | Germany ----------------------------------------------------------------------- > -----Original Message----- > From: Pete Cordell [SMTP:pete.cordell@BT-SYS.BT.CO.UK] > Sent: Donnerstag, 26. November 1998 12:48 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Tunneling in FACILITY > > Senthil, > > I think if what you are doing needs you send tokens etc., then the only > way to do this is to send a Q.931 message, which means that you need to > send a Q.931 message! Therefore I think the original version of the > sentence still holds. > > Or perhaps I am missing something! > > Regards, > > Pete > ================================= > Pete Cordell > BT Labs > E-Mail: pete.cordell(a)bt-sys.bt.co.uk > Tel: +44 1473 646436 > Fax: +44 1473 645499 > ================================= > > > >---------- > >From: Sengodan Senthil > >NRC/Boston[SMTP:sengodan@NASBPD01BS.NTC.NOKIA.COM] > >Reply To: Mailing list for parties associated with ITU-T Study Group > >16 > >Sent: 25 November 1998 21:37 > >To: ITU-SG16(a)MAILBAG.INTEL.COM > >Subject: Tunneling in FACILITY > > > >Folks, > > > >Section 8.2.1 of H.323 states: > > > >"If tunneling is being utilized and there is no need for transmission > >of a Q.931 message at the time an H.245 message must be transmitted, > >then a FACILITY message shall be sent with 'h323-message-body' set to > >'empty'." > > > >I would like to know - for the case where no Q.931 message needs to be > >sent - if there are any negative implications of setting the > >'h323-message-body' to 'facility' with 'reason' set to > >'undefinedReason'. This would enable the use of several fields that are > >available within the 'Facility-UUIE' structure - such as 'tokens' and > >'cryptotokens' - which would not be available if 'h323-message-body' is > >set to 'empty'. > > > >A rewording of the sentence as below would enable this: > > > >"If tunneling is .... a FACILITY message shall be sent and the > >'h323-message-body' should be set to 'empty'." > > > >Comments? > > > > - Senthil > > > >Senthil Sengodan > >Nokia Research Center, Boston > >

1 0

Re: Tunneling in FACILITY
by Pete Cordell 26 Nov '98

26 Nov '98

Senthil, I think if what you are doing needs you send tokens etc., then the only way to do this is to send a Q.931 message, which means that you need to send a Q.931 message! Therefore I think the original version of the sentence still holds. Or perhaps I am missing something! Regards, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Sengodan Senthil >NRC/Boston[SMTP:sengodan@NASBPD01BS.NTC.NOKIA.COM] >Reply To: Mailing list for parties associated with ITU-T Study Group >16 >Sent: 25 November 1998 21:37 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Tunneling in FACILITY > >Folks, > >Section 8.2.1 of H.323 states: > >"If tunneling is being utilized and there is no need for transmission >of a Q.931 message at the time an H.245 message must be transmitted, >then a FACILITY message shall be sent with 'h323-message-body' set to >'empty'." > >I would like to know - for the case where no Q.931 message needs to be >sent - if there are any negative implications of setting the >'h323-message-body' to 'facility' with 'reason' set to >'undefinedReason'. This would enable the use of several fields that are >available within the 'Facility-UUIE' structure - such as 'tokens' and >'cryptotokens' - which would not be available if 'h323-message-body' is >set to 'empty'. > >A rewording of the sentence as below would enable this: > >"If tunneling is .... a FACILITY message shall be sent and the >'h323-message-body' should be set to 'empty'." > >Comments? > > - Senthil > >Senthil Sengodan >Nokia Research Center, Boston >

1 0

Tunneling in FACILITY
by Sengodan Senthil NRC/Boston 25 Nov '98

25 Nov '98

Folks, Section 8.2.1 of H.323 states: "If tunneling is being utilized and there is no need for transmission of a Q.931 message at the time an H.245 message must be transmitted, then a FACILITY message shall be sent with 'h323-message-body' set to 'empty'." I would like to know - for the case where no Q.931 message needs to be sent - if there are any negative implications of setting the 'h323-message-body' to 'facility' with 'reason' set to 'undefinedReason'. This would enable the use of several fields that are available within the 'Facility-UUIE' structure - such as 'tokens' and 'cryptotokens' - which would not be available if 'h323-message-body' is set to 'empty'. A rewording of the sentence as below would enable this: "If tunneling is .... a FACILITY message shall be sent and the 'h323-message-body' should be set to 'empty'." Comments? - Senthil Senthil Sengodan Nokia Research Center, Boston

1 0

Re: Gateway Decomposition Requirements
by Tom-PT Taylor 25 Nov '98

25 Nov '98

Thanks for getting this started. I have some discussion points for further clarification. > -----Original Message----- > From: Dale L. Skran [SMTP:dskran@ASCEND.COM] > Sent: Saturday, November 21, 1998 7:28 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Gateway Decomposition Requirements > [Taylor, Tom [CAR:B318-I:EXCH]] [snip] > B Interface: > > 1)It must be possible to request that the MGW do H.323 signaling to a > specified IP address, which might, for example, be a composed GW. Of > course, this > is an optional feature. > [Taylor, Tom [CAR:B318-I:EXCH]] The one misgiving I had when documenting the "H.323 Endpoint Type" in IPDC was that the SETUP message contains a lot more than we provided for, and in fact IPDC probably was broken for GW to GW operation (because of missing address information). In effect, the requirement is that interface B should pass all of the relevant contents of the SETUP message. Some things such as the CRV can obviously be left to the Media Gateway to handle. > 2)It must be possible to do this call by call, ie. for one call request > 323 signaling and for the next not request it. > > 3)Point 2 strongly suggests that the protocol for B and A should be the > same, > for example, as in IPDC. [Taylor, Tom [CAR:B318-I:EXCH]] Aside from its call by call operation, it seems to me that the chief requirement on B, C, and D is encapsulation of signalling protocol elements. This suggests you have to have stuff like call identifiers, endpoint identifiers, protocol identifiers, and provision for shipping across large blocks of opaque data. I'm not sure that is logically linked with the device control stuff (interface A). Could we come up with sample message flows that demonstrate an increase in efficiency through use of a common protocol? > C Interface: > > 1)It must be possible to bring call signaling up to the controller so that > signaling can be terminated there (optionally). This suggests a need to > map > different types of call signaling into a single protocol. Q.931 is an > obvious > solution. See Ascend's "Reliable Gateway Signaling Protocol" for an > example. [Taylor, Tom [CAR:B318-I:EXCH]] This seems to be a pretty good consensus on this for trunk signalling, except that apparently some R2 information has to be carried some other way. Our terms of reference don't cover line-side signalling. P.S. I thought the Ascend/Bay RSGP was intended for the D interface. > 2)It must be possible to terminate/generate the Q.931, etc. call signaling > on the gateway > (optionally). This is equivalent to having the MGW signal 323 on the > packet > size. > This allows a call from a MGW with IMT trunks to talk to a MGW with PRI/T1 > trunks > under SS7 control. [Taylor, Tom [CAR:B318-I:EXCH]] Implications for interface C? > 3)(1) is a kind of tunneling for Q.931, so it is not so clear that this > should be > the same protcol as A/B. > > 4)(2) seems like it should be a part of the A/B protcol. > > X requirements(common requirements on A/B/C): > > 1)A/B/C signaling must all travel over the same data network to the MGW. > > 2)It must be possible to use both UDP and TCP > > 3)Either the protocol is Message/ACK or we must use a reliable UDP like > Annex E. > > 4)Given the similiarity of B/C to A, all should use a similar message > format, > the same ports, etc. to ease implementation. Note that both B/C parts are > probably > optional, but they are part of the same protocol as A. The only exception > is the case > where you want to put SCN call signaling(Q.931, FAS SS7) in the > controller, > and > you need to tunnel it up. This stuff might be tunneled through the A/B/C > protocol, or it might be a separate protocol/port, i.e. Q.931 on Annex E > with > a different port. > > 5)Part of the A/B/C message set must include an MGW cap set so the > controller > knows what to expect [Taylor, Tom [CAR:B318-I:EXCH]] This can be argued two ways. If it's there, then as you suggest below we are looking at H.245. Alternatively caps could be set by other means (i.e. configuration). We're talking about boot-up messaging here, not per-call operation. > As noted at the meeting, you need to reflect the terms of reference in the > A > requirements. > > A couple of obvious ones: > > A Interface > > 1)Must include video/data (i.e. consider the possibility of incoming > H.320/H.324 > calls). > > 2)Must not duplicate H.323 functions, eg. cap exchange, conference > management, etc. > > 3)Must be elemental. This goes along with (2). cap exchange is not an > elemental > function. > > 4)Must be suitable for connecting an MC (MultiPoint Controller) to an MP > (Media > Processer) as defined in H.323. This implies a need for elemental > conferencing > primatives, but broken out by media stream, ie. data MP, voice MP, video > MP. > > I'm sure there is more that could be added by a careful review of the > terms of reference. > > > Dale Skran > Rapporteur, Q13 WP2 SG16 ITU-T > > > > > > >Can anyone get us down to another level of detail? > > > >Tom Taylor > >E-mail: taylor(a)nortelnetworks.com (internally Tom-PT Taylor) > >Tel.: +1 613 765 4167 (internally 395-4167) > >FAX: +1 613 763 7236 (internally 393-7236) > >

1 0

Re: H.323 Annex E
by Bell, Bob 25 Nov '98

25 Nov '98

I would second this proposal. The exchange of signalling transport requirements belongs in a CAPS type exchange. -----Original Message----- From: Yoav Medan [mailto:MEDAN@HAIFA.VNET.IBM.COM] Sent: Saturday, November 21, 1998 9:52 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 Annex E Kishore, IMHO this is more than just an interesting approach. I can see a backward compatibility problem only when endpoints are trying to engage in a peer-to-peer call setup (no GK, thank you). But in a GK routed call setup, why not negotiate UDP or TCP as part of the initial caps exchange? This applies to both endpoint-GK and to GK-GK communications, as you cleverly pointed out. I think we ought to design Internet "Green" (i.e. friendly) protocols that do not flood the network with redundant information unnecessarily. Let's be clever about it rather than smart. Regards Yoav Medan IBM Research, Haifa Lab, Israel Kishore Ramisetty <kish(a)TRILLIUM.COM> on 20-11-98 09:57:50 PM Please respond to Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)MAILBAG.INTEL.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM cc: (bcc: Yoav Medan/IBMHAIFA) Subject: H.323 Annex E H.323 Annex E proposes using simultaneous (or a little later) TCP and UDP transport connections to provide seamless interoperability with non-Annex E devices. This results in inefficiencies because we now have to transmit two kinds of PDUs for the same call. (Q.931 headers are present for TCP transport and they are absent for UDP). This again has the unfortunate consequence of mandating higher layers to be aware of the transport because upper layers have to deal with duplicates arriving from TCP and UDP connections. (Section E.5.3 para 4 and 5) A simpler solution to this problem is, Annex E compliant end points should register with gatekeeper about their capability of supporting Annex E in RRQ message and gatekeeper propogates this in ACF messages. So, it is easy to determine apriori whether to attempt UDP/TCP connection to the destination end points (because non Annex E devices won't register anything with gatekeepers). This will also require some additions to GK-GK communication so that such kinds of profiles can be communicated across zones. This solution of course requires V3 GKs. If a V3 GK (or GK itself) is absent, then end points could have the option of trying simultaneous connections or simply falling back to TCP. This solution would make sure that going forward to V3 we can get rid of this simultaneous connection establishment procedures. I would like some comments from the group. Thanks, -Kishore. ------------------------------------------------------------------ This message was spam-checked by an evaluation copy of MailShield. See http://www.mailshield.com for more information.

1 0

Rev..3 RE: [wg5-3: 2134] q11h17/apc1457 rev. 2
by Yoshihiro Kikuchi 25 Nov '98

25 Nov '98

Dear Q.11-15 experts, Attached find please the rev.3 of H.245 codepoints for MPEG-4 visual (q11h17/apc1457). The change from rev.2 is only on the default value of the drawingOrder as in the Q.11 meeting report. In the determination version (and in rev.2), the default value of the drawingOrder was 0. It is equal to the minimum value of the drawingOrder. It makes a limitation that a logical channel cannot has the smaller drawingOrder value than that of the logical channel formally opened without indicating drawingOrder. This means that a visual object cannot drawn Behind the visual object associated with the formally opened logical channel with default drawingOrder. I changed the default value to 32768, which is the middle of maximum and minimum values. Please note that the format of rev.3 is quit changed form rev.2 as the delta from H.245 ver.4, but the contents should be the same expect for the above change. If you have any comment on it, please send a message until the end of this week. I will make changes with reflecting all comments, and will send it to the H.245 editor (Mr. Mike Nilsson) next week. Best regards, Yoshihiro -----Original Message----- From: Yoshihiro Kikuchi <kiku(a)eel.rdc.toshiba.co.jp> To: itu-adv-video(a)mack.iterated.com <itu-adv-video(a)mack.iterated.com>; sg16.lbc(a)research.kpn.com <sg16.lbc(a)research.kpn.com> Cc: Yoshihiro Kikuchi <kiku(a)eel.rdc.toshiba.co.jp> Date: Sunday, November 22, 1998 6:47 PM Subject: [wg5-3: 2134] q11h17/apc1457 rev. 2 >Dear Gary, Mike and Q.11-15 experts, > >The attached mail is the one I tried to send last week during the Torino >meeting but not accomplished by a network trouble. I'm sending this >again. I'm also attaching the 2nd. revision of q11h17/apc1457 which is >the >last revision reviewed in the Torino meeting. > >As in the Q.11 meeting report, I should make another revision on the >default value of the drawingOrder. I will send the revised document >soon. > >Best regards, >Yoshihiro > >---- > Yoshihiro Kikuchi > E-mail: kiku(a)eel.rdc.toshiba.co.jp >Research and Development Center TEL: +81 +44 549 2151 >Toshiba Corp. FAX: +81 +44 520 1308 > > >

1 0

FW: Proposed IETF Working Group: MEdia GAteway COntrol (megaco)
by Tom-PT Taylor 24 Nov '98

24 Nov '98

This message has been cross-posted to the Bellcore SGCP list, the ITU SG16 AVC list, and the TIPHON list. All follow-ups to navdec(a)BayNetworks.COM, please. To join the navdec list (probably soon to be renamed megaco), send a message to majordomo(a)baynetworks.com with "subscribe navdec" (no quotes) in the body. At the bottom of this message is the device control working group charter as it currently stands. We can tweak it a bit in the December meeting. I am still working up the agenda and document list for that meeting, which will be on Friday morning, Dec. 11. In the meantime, I would like consideration given to the following: 1. What is the minimum we can put into a first protocol draft? I don't want us to drag this out for two years before we get our first standards-track RFC. Let me put this on the table: the core functionality is connection making and media stream manipulation. Event detection, insertion, and scripting are follow-up items. We might spend some of our time considering what kinds of connections and what kinds of media stream transformations the first protocol RFC should support. If people want to work in parallel on RFCs for specific applications, that's fine. 2. Scott appointed me partly because of my strong interest in trying to keep ETSI TIPHON, ITU-T Study Group 16, and our own working group working together. The other groups are particularly interested in trunking gateways in an H.323 context. SG 16 is interested in multimedia, not just audio. I would like suggestions on how we and they can organize our work to minimize conflict and maximize commonality. 3. Nancy Greene has done a lot of work on architecture and requirements in the past. I propose that she be Document Editor for the architecture and requirements RFC on our work list. More later. Tom Taylor taylor(a)nortelnetworks.com Ph. +1 613 765-4167 > -----Original Message----- > From: Steve Coya [SMTP:scoya@ns.cnri.reston.va.us] > Sent: Monday, November 23, 1998 12:05 PM > To: IETF-Announce > Cc: new-work(a)ietf.org > Subject: Proposed IETF Working Group: MEdia GAteway COntrol (megaco) > > A new IETF working group has been proposed in the Transport Area. > The IESG has not made any determination as yet. > > The following Description was submitted, and is provided for > informational purposes: > > > The working group will develop an informational RFC detailing the > architecture and requirements for controlling Media Gateways from > external control elements such as a Media Gateway Controller. A media > gateway is a network element that provides conversion between the > information carried on telephone circuits and data packets carried over > the Internet or over other IP networks. This work will be done in > consultation with other IETF working groups looking at similar issues. > The working group will also ensure that good information conduits exist > with groups in other standards groups with expertise in the relevant > PSTN technology. Other IETF working groups include PINT, IPTEL and > SIGTRAN. In addition the working group will ensure that reasonable > liaisons exist with similar activities in other standards bodies such as > the ITU-T and ETSI. > > This working group will also define standards track protocol(s) for > controlling media gateways from external control elements such as a > media gateway controller. > > Examples of media gateways are: > > * Trunking gateways that interface between the telephone > network and a Voice over IP network. Such gateways > typically manage a large number of digital virtual circuits. > * Access gateways that provide traditional analog or Primary > Rate (PRI) line interfaces to a Voice over IP network. > * Network Access Servers that can attach a "modem" to a > telephone circuit and provide data access to the > Internet. > > This working group assumes a separation of call control so the call > control "intelligence" is outside the media gateways and handled by a > media gateway controller. This group will NOT work on media gateway > controller to media gateway controller protocols, nor on media gateway > to media gateway protocols. > > Planned output: > > * Architecture & Requirements informational RFC > > * Standards Track RFC for the protocol between a media > gateway controller and a media gateway. > > * Standards Track RFC for the MG and MC MIBs > > * Informational RFC for application programming interface > for the MC to MG protocol

1 0