December 1997 - sg16-avd - lists.packetizer.com

Issues related to H.225.0 and H.450
by Orit Levin 03 Dec '97

03 Dec '97

Karl and Editors! I agree with your point #2 (H.450.2 Clause 10.6.1.1). My only request is to expand the OPTIONAL possibilities of the FACILITY message NOW. H.450.x are new evolving, and therefore flexible, series. On the other hand, who knows when H.323v3 will be available! Orit Levin RADVision Inc. E Mail: orit(a)radvision.com 575 Corporate Dr., Suite 420 Tel: 201-529-4300 ext. 230 Mahwah, NJ 07430 Fax: 201-529-3516 ---------- From: Karl Klaghofer [SMTP:karl.klaghofer@MCH.PN.SIEMENS.DE] Sent: Wednesday, December 03, 1997 4:41 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Limitation of nonStandardData and other issues related toH.450 Some comments related to H.450.x have been placed to the reflector the last days. 1) H.450.2 Clause 10.5 (item 1 of Levin Orit´s comments, dated Dec.1) I agree, 2nd paragraph, third line: ...and conferenceGoal="invite"... should be deleted. 2) H.450.2 Clause 10.6.1.1 (item 4 of Levin Orit´s comments, dated Dec.1) The procedures defined for this gatekeeper active transfer case right now are very much based on the gatekeeper having H.225 as well as H.245 control (i.e. H.225 as well as H.245 routed via gk). The model you are referring to (H.225 via gk; H.245 direct routed) was not investigated in conjunction with active gk transfer, since this model is (as Pete sayd) still marked as "for further study" in H.323V2 ! Using the direct H.245 model in conjunction with active transfer by gatekeeper would introduce a further, alternative method of handling the logical channel closing and reopening issue at the transferred endpoint B. Remark: In Sunriver September meeting, the goal was to have just one method (we picked the "empty terminalCapabilitySet" method and dropped the "requestChannelClose with reopen" method in order to reach this goal. Proposal for further proceeding: First the H.245 direct model has to be investigated for H.323 (maybe H.323V3). Then, H.450.2 (maybe V2) might be updated to get this model also to work for active gk transfer. 3) Limitation of nonStandardData (Comment from Pete Cordell, dated Dec.2) Currently we have in H.450.x constructs like the following: argumentExtension CHOICE {extensionSeq ExtensionSeq, nonStandardData NonStandardParameter } OPTIONAL ExtensionSeq ::= SEQUENCE OF Extension{{ExtensionSet}} ExtensionSet EXTENSION ::= {...} -- Actual values defined by individual manufacturers This means: either one value nonStandardParameter or a SEQ of an arbitrary number of values of type Extension may be inserted. 1st possible change: allow more than one nonStandardParameter: argumentExtension CHOICE {extensionSeq ExtensionSeq, nonStandardData SEQUENCE OF NonStandardParameter } OPTIONAL which means either a SEQ of Extensions or a SEQ of NonStandardParameter may be inserted. This 1st possibility would be a H.450 change corresponding to Pete´s proposal for H.225/H.245. 2nd possible change: argumentExtension SEQUENCE OF MixedExtension OPTIONAL MixedExtension ::= CHOICE {extension Extension{{ExtensionSet}}, nonStandardData NonStandardParameter } This 2nd possibility would be a H.450 change corresponding to Pete´s proposal for H.225/H.245, which adds a further dimension of allowing mixing of any number of NonStandardParameter and ISO like Extensions within one pdu. This may have advantages e.g. in the case that an ISO like Extension is contained within a received pdu in a gk and the gk wants to add further extensions of the NonStandardParamter type (or vice versa) to the same pdu. Proposal for further proceeding. The 2nd possibility mentioned above should be added to a H.450V2. ================================================== Karl Klaghofer Siemens AG Munich, Hofmannstr. 51, D-81359 Munich, Germany Dptmnt: PN VS LP3, Building/Room: 1760/455 Tel.: +49 89 722 31488 Fax.: +49 89 722 23977 email: karl.klaghofer(a)mch.pn.siemens.de ==================================================

1 0

FW: Remarks on H.450.x and H.225.0
by Orit Levin 02 Dec '97

02 Dec '97

Dear Pete and all others ! My additional comments are below: >3. H.225.0 Annex H - ASN.1 >All ,but UI-UUIE, XXX-UUIE messages have callIdentifier field. ------------------------------------------------------------------------------------- We agree with Pete's proposal. It is more general but requires more changes in the standard. Let fix it one way or another, but till Geneva! ------------------------------------------------------------------------------------- > >4. H.450.2 Clause 10.6.1.1 >This clause is talking about Call Transferring in case of GK Call >Routed model and both Q.931 Signaling and H.245 protocol are "routed" >by the GK. According to H.323V.2 GK's Call Routed model where Q.931 >Signaling is routed by the GK, but H.245 messages flow directly is >legal and more efficient. It seems that the clause above doesn't cover >this case. In order to provide a working solution for this case, an >additional OPTIOANAL field "h245Address" should be added to >Facility-UUIE message ... ------------------------------------------------------------------------------------- Three things on this: Firstly, Pete, you are right about the "future study". Still this mode is more efficient and we shouldn't cancel it without serious considerations. In this case (of H.450.2) with this optional field we could support it. Do we want to cancel the possibility of using this mode without even studying it ? Secondly, the facility message, described in H.450.2 section, may contain Facility-UUIE as a part of it. Currently this Facility-UUIE is empty, but it can be used and have a new h245Address field. Thirdly, I will try to explain the relevant scenario using H.450.2 terminology. Suppose, A and B are in the GK routed call, while H.245 and UDP streams flow directly between them. All "transferring logic" is performed by the GK on behalf of B. None of the mentioned messages (specifically CONNECT message) reaches B. Still, when the call is transferred from A to C, B has to receive (a new) H.245 address of C. The proposed way to receive it, is by means of FACILITY message containing Facility-UUIE. Pay attention that B, who doesn't perform the "transferring logic" itself, upon arrival of the FACILITY message containing a new H.245 address, has to close the old H.245 channel and open a new one (towards C). ------------------------------------------------------------------------------------- (I am starting to enjoy it, but I am serious.) >>Thanks, > >Orit Levin >RADVision Inc. E Mail: orit(a)radvision.com >575 Corporate Dr., Suite 420 Tel: 201-529-4300 ext. 230 >Mahwah, NJ 07430 Fax: 201-529-3516 >

1 0

Re: Limitation of nonStandardData
by Scott Petrack 02 Dec '97

02 Dec '97

This problem has bothered me for a long time. I considered many times introducing into the VoIP Forum an OID which would be used precisely as Jim suggests, so that the entire industry could signal a SEQUENCE of NonStandardParameter. One example of why this is necessary is so that when someone else uses our stack we can both pass non-standard parameters. Question to all "industry techie-leaders" (by definition people reading this message ;-)). Is there any chance of gettting agreement on this or is it too late? Of course we can do it privately (and we do), but it would be very useful to have everyone do it together, no? I would offer an OID in the VoIP forum's space, but I really could not care less about ownership. If there is a way to put this into the standard, that would be fantastic. Scott jtoga(a)ideal.jf.intel.com on 12/01/97 09:42:53 PM Please respond to ITU-SG16(a)mailbag.jf.intel.com To: ITU-SG16(a)mailbag.jf.intel.com cc: (bcc: Scott Petrack) Subject: Re: Limitation of nonStandardData Pete, An easy fix for backward compatability is to simply define a particular 'nonStandardParameter' as a "SEQUENCE OF nonStandardParameter". Regards, jimt. At 07:02 PM 12/1/97 -0000, you wrote: >Dear All, > >I have noticed that there is a limitation in H.225 (and H.245) on how >nonStandardData is included in messages. Basically only one >non-standard element can be included in each PDU. This is because of >the syntax: > > nonStandardData NonStandardParameter, > >What is really required for a truly extensible protocol is: > > nonStandardData SEQUENCE OF NonStandardParameter, > >This is especially important if a gatekeeper wants to insert >nonStandardData into a message that already has nonStandardData added in >to it by an endpoint. > >This may be too late to fix for H.225, but we can fix this for the >H.450.x protocols. > >Pete >================================= >Pete Cordell >BT Labs >E-Mail: pete.cordell(a)bt-sys.bt.co.uk >Tel: +44 1473 646436 >Fax: +44 1473 645499 >================================= > > ************************************************************************* *** +1-503-264-8816(voice) +1-503-264-3485(fax) *** *** jtoga(a)ibeam.intel.com Intel - Hillsboro, OR. *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41*** *************************************************************************

2 1

Re: Limitation of nonStandardData
by Douglas Clowes 02 Dec '97

02 Dec '97

I had also noted this potential limitation. While the 'SEQUENCE OF' is ther nicest fix for it, an alternative possibility is to wrap (encapsulate) the original nonStandardData in the new one (as part of the data) and unwrap it later. This would work where the message path is EP-GK-GK-EP and the EP's are exchanging nonStandardData plus the GK's are also. Douglas At 19:02 1/12/97 -0000, you wrote: >Dear All, > >I have noticed that there is a limitation in H.225 (and H.245) on how >nonStandardData is included in messages. Basically only one >non-standard element can be included in each PDU. This is because of >the syntax: > > nonStandardData NonStandardParameter, > >What is really required for a truly extensible protocol is: > > nonStandardData SEQUENCE OF NonStandardParameter, > >This is especially important if a gatekeeper wants to insert >nonStandardData into a message that already has nonStandardData added in >to it by an endpoint. > >This may be too late to fix for H.225, but we can fix this for the >H.450.x protocols. > >Pete >================================= >Pete Cordell >BT Labs >E-Mail: pete.cordell(a)bt-sys.bt.co.uk >Tel: +44 1473 646436 >Fax: +44 1473 645499 >================================= > >

1 0

Re: Limitation of nonStandardData
by Jim Toga 01 Dec '97

01 Dec '97

Pete, An easy fix for backward compatability is to simply define a particular 'nonStandardParameter' as a "SEQUENCE OF nonStandardParameter". Regards, jimt. At 07:02 PM 12/1/97 -0000, you wrote: >Dear All, > >I have noticed that there is a limitation in H.225 (and H.245) on how >nonStandardData is included in messages. Basically only one >non-standard element can be included in each PDU. This is because of >the syntax: > > nonStandardData NonStandardParameter, > >What is really required for a truly extensible protocol is: > > nonStandardData SEQUENCE OF NonStandardParameter, > >This is especially important if a gatekeeper wants to insert >nonStandardData into a message that already has nonStandardData added in >to it by an endpoint. > >This may be too late to fix for H.225, but we can fix this for the >H.450.x protocols. > >Pete >================================= >Pete Cordell >BT Labs >E-Mail: pete.cordell(a)bt-sys.bt.co.uk >Tel: +44 1473 646436 >Fax: +44 1473 645499 >================================= > > ************************************************************************* *** +1-503-264-8816(voice) +1-503-264-3485(fax) *** *** jtoga(a)ibeam.intel.com Intel - Hillsboro, OR. *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41*** *************************************************************************

1 0

Limitation of nonStandardData
by Pete Cordell 01 Dec '97

01 Dec '97

Dear All, I have noticed that there is a limitation in H.225 (and H.245) on how nonStandardData is included in messages. Basically only one non-standard element can be included in each PDU. This is because of the syntax: nonStandardData NonStandardParameter, What is really required for a truly extensible protocol is: nonStandardData SEQUENCE OF NonStandardParameter, This is especially important if a gatekeeper wants to insert nonStandardData into a message that already has nonStandardData added in to it by an endpoint. This may be too late to fix for H.225, but we can fix this for the H.450.x protocols. Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 =================================

1 0

Re: Remarks on H.450.x and H.225.0
by Pete Cordell 01 Dec '97

01 Dec '97

Dear All, Please see comments below: Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Orit Levin[SMTP:orit@RADVISION.COM] >Sent: 01 December 1997 15:59 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Remarks on H.450.x and H.225.0 > >Hello, Editors! > >We are working know on the Supplementary Services stuff and came across >some pitfalls in the last (Geneva) versions of the above protocols. It >would be helpful to fix them before Geneva. I am listing them below: > >1. H.450.2 Clause 10.5 ><<FACILITY message containing a callTransferInitiate invoke APDU and >conferenceGoal = "invite">> is mentioned here. There is no >conferenceGoal in FACILITY message. Possibly this mistake derives from >the SETUP message, mentioned later in the same clause, which indeed has >conferenceGoal field. > >2. H.225.0 Annex H - ASN.1 >InfoRequestResponse ::= SEQUENCE --(IRR) >{ > nonStandardData NonStandardParameter OPTIONAL, > . > . > perCallInfo SEQUENCE OF SEQUENCE > { > . > . > originator BOOLEAN, > . > . > } OPTIONAL, > ..., > . > . >} > >The field "originator" is no longer OPTIONAL (the way it was defined in >V.1), which makes the situation NOT backward compatible. Was there any >reason for that change, or it just a mistake? In any case, because of >the ASN.1 encoding rules, this situation highly undesirable. This looks correct. I'm partly responsible for this as I asked Glen to take out OPTIONAL from a number of BOOLEANS. However, we can only do this for BOOLEANS that we have added for V2. I've looked through and this is the only instance where I can see this has been done. > >3. H.225.0 Annex H - ASN.1 >All ,but UI-UUIE, XXX-UUIE messages have callIdentifier field. We >propose to add this field for UI-UUIE message as well ("for future >sake"): >UI-UUIE ::=SEQUENCE >{ > protocolIdentifier ProtocolIdentifier, > ... > callIdentifier CallIdentifier > >} Since CallIdentifier is becoming such an important parameter then we really need to put it in a place where we can get it in a message independent way, i.e. H323-UserInformation, or H323-UU-PDU. This will also mean that it is in all messages and we don't have to reference it in any new messages we create (i.e. as above). e.g.: H323-UserInformation ::= SEQUENCE -- root for all Q.931 related ASN.1 { h323-uu-pdu H323-UU-PDU, user-data SEQUENCE { protocol-discriminator INTEGER (0..255), user-information OCTET STRING (SIZE(1..131)), ... } OPTIONAL, ..., callIdentifier CallIdentifier } P.S. Can I confirm that even when CallIdentifier is present, the CRV will still have the use and mean that it does in V1? > >4. H.450.2 Clause 10.6.1.1 >This clause is talking about Call Transferring in case of GK Call >Routed model and both Q.931 Signaling and H.245 protocol are "routed" >by the GK. According to H.323V.2 GK's Call Routed model where Q.931 >Signaling is routed by the GK, but H.245 messages flow directly is >legal and more efficient. It seems that the clause above doesn't cover >this case. In order to provide a working solution for this case, an >additional OPTIOANAL field "h245Address" should be added to >Facility-UUIE message as follows: > >H.225.0: Add "h245Address" field to the Facility message: > >Facility-UUIE ::= SEQUENCE >{ > protocolIdentifier ProtocolIdentifier, > alternativeAddress TransportAddress OPTIONAL, > alternativeAliasAddress SEQUENCE OF AliasAddress OPTIONAL, > conferenceID ConferenceIdentifier OPTIONAL, > reason FacilityReason, > ..., > callIdentifier CallIdentifier, > destExtraCallInfo SEQUENCE OF AliasAddress >OPTIONAL, > remoteExtensionAddress AliasAddress OPTIONAL, > tokens SEQUENCE OF ClearToken >OPTIONAL, > cryptoTokens SEQUENCE OF CryptoH323Token >OPTIONAL, > conferences SEQUENCE OF ConferenceList >OPTIONAL, > h245Address TransportAddress OPTIONAL > >} Three things on this: Firstly the call model you described is marked as for further study in 7.3.2/H.323. This was presumably done for a good reason and we shouldn't change it without understanding why we did it. (I think Mark was the one who said why the model wouldn't work, but I'm not sure.) Secondly, the facility message described in H.450.2 section is not the same as the Facility-UUIE that you mention above. Thirdly, the H.245 address would not be needed in the Facility-UUIE because it is determined using the usual means of getting it, e.g. in SETUP, ALERTING, CONNECT etc. > >Thanks, > >Orit Levin >RADVision Inc. E Mail: orit(a)radvision.com >575 Corporate Dr., Suite 420 Tel: 201-529-4300 ext. 230 >Mahwah, NJ 07430 Fax: 201-529-3516 >

1 0

Remarks on H.450.x and H.225.0
by Orit Levin 01 Dec '97

01 Dec '97

Hello, Editors! We are working know on the Supplementary Services stuff and came across some pitfalls in the last (Geneva) versions of the above protocols. It would be helpful to fix them before Geneva. I am listing them below: 1. H.450.2 Clause 10.5 <<FACILITY message containing a callTransferInitiate invoke APDU and conferenceGoal = "invite">> is mentioned here. There is no conferenceGoal in FACILITY message. Possibly this mistake derives from the SETUP message, mentioned later in the same clause, which indeed has conferenceGoal field. 2. H.225.0 Annex H - ASN.1 InfoRequestResponse ::= SEQUENCE --(IRR) { nonStandardData NonStandardParameter OPTIONAL, . . perCallInfo SEQUENCE OF SEQUENCE { . . originator BOOLEAN, . . } OPTIONAL, ..., . . } The field "originator" is no longer OPTIONAL (the way it was defined in V.1), which makes the situation NOT backward compatible. Was there any reason for that change, or it just a mistake? In any case, because of the ASN.1 encoding rules, this situation highly undesirable. 3. H.225.0 Annex H - ASN.1 All ,but UI-UUIE, XXX-UUIE messages have callIdentifier field. We propose to add this field for UI-UUIE message as well ("for future sake"): UI-UUIE ::=SEQUENCE { protocolIdentifier ProtocolIdentifier, ... callIdentifier CallIdentifier } 4. H.450.2 Clause 10.6.1.1 This clause is talking about Call Transferring in case of GK Call Routed model and both Q.931 Signaling and H.245 protocol are "routed" by the GK. According to H.323V.2 GK's Call Routed model where Q.931 Signaling is routed by the GK, but H.245 messages flow directly is legal and more efficient. It seems that the clause above doesn't cover this case. In order to provide a working solution for this case, an additional OPTIOANAL field "h245Address" should be added to Facility-UUIE message as follows: H.225.0: Add "h245Address" field to the Facility message: Facility-UUIE ::= SEQUENCE { protocolIdentifier ProtocolIdentifier, alternativeAddress TransportAddress OPTIONAL, alternativeAliasAddress SEQUENCE OF AliasAddress OPTIONAL, conferenceID ConferenceIdentifier OPTIONAL, reason FacilityReason, ..., callIdentifier CallIdentifier, destExtraCallInfo SEQUENCE OF AliasAddress OPTIONAL, remoteExtensionAddress AliasAddress OPTIONAL, tokens SEQUENCE OF ClearToken OPTIONAL, cryptoTokens SEQUENCE OF CryptoH323Token OPTIONAL, conferences SEQUENCE OF ConferenceList OPTIONAL, h245Address TransportAddress OPTIONAL } Thanks, Orit Levin RADVision Inc. E Mail: orit(a)radvision.com 575 Corporate Dr., Suite 420 Tel: 201-529-4300 ext. 230 Mahwah, NJ 07430 Fax: 201-529-3516

1 0

Re: $$ BOOKS, SOFTWARE, CD'S, VIDEO ETC. - DEEP DISCOUNTS $$
by sross 01 Dec '97

01 Dec '97

Please remove me from from mailing list. At 03:59 AM 11/28/97 -0800, you wrote: >Do you buy a lot of books, CDs, cassettes, videos and software? Would you >like to save BIG money on ALL of these products you buy, not just a few titles >as offered by the better known online book and video stores? > >We carry all subject categories. Audio tapes, books on tape, hardcover, >paperbacks, music CDs, cassettes, movie videos and software too. Our >discounts apply to even special orders, unlike the better known online stores. >You get discounts on EVERYTHING !!! > >Send us the titles, author, ISBN number or any of these and we will get back >to you with REAL discounts !!! > >We ship all over the world at the CHEAPEST rates we can get. You save even >more money. > >Be sure to put "books etc inquiry" in subject line to get to the right department. > >Thank you >alternatives(a)alternativeproducts.com > ____________________________________________________ Scott A. Ross, Director of Software Zydacron, Inc. 7 Perimeter Rd, Manchester, N.H. 03103 Phone:(603)647-1000 Fax: (603)647-9470 E-mail: sross(a)zydacron.com VideoPhone: 1(700)734-7993

1 0

GCL ftp site is currently in trouble
by Sakae Okubo 01 Dec '97

01 Dec '97

Dear Q.12-14/16 experts, GCL ftp site (ftp://itu-t:sg15!avc@ftp.gctech.co.jp) is currently in trouble. Until we can solve the problem, please access its mirror site (many thanks to PictureTel efforts to maintain this mirror site): ftp://standard.pictel.com/avc-site/ Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ********************************************************************

1 0