- sg16-avd - lists.packetizer.com

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 01 Dec '97

01 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

$$ BOOKS, SOFTWARE, CD'S, VIDEO ETC. - DEEP DISCOUNTS $$
by Alternative Products 30 Nov '97

30 Nov '97

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

3 2

Draft WP2 workplna for Jan-Feb meeting
by Sakae Okubo 26 Nov '97

26 Nov '97

/// Attachment has been replaced with the text version. Thank you /// /// Meesrs. Kawahara and Haskell for your advice. /// Dear Q.12-14/16 experts, Attached please find Mr. Tosco's initial draft of the coming WP2/16 meeting starting 26 January 1998. Mr. DeGrasse kindly converted Mr. Tosco's fax message into a Word document to which I added the topics of joint sessions as notes. This plan will be finalized after reflecting Rapporteurs' comments and negotiating with WP1 and WP3. 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 ******************************************************************** DRAFT MEETING SCHEDULE FOR THE WP2/16 MEETING Date AM Schedule PM Schedule 26 - Mon SG16 Plenary WP2 Plenary 27 - Tue Q11, Q12, Q13 SG 16 Plenary 28 - Wed Q3, Q11, Q12, Q13 Q3, Q11, Q12, Q13 29 - Thr Q1, Q3, Q11, Q1, Q3, Q11, (Q12,13,14)#1 (Q12,13,14)#1 30 - Fri Q1, Q11, Q1, (Q3,12,13,14)#3 ! Q1, * (Q3,12,13,14)#2 ! (Q11,12,13)#4 2 - Mon Q1, Q3, Q1, Q3, ! Q1, Q3, * (Q11,12,13,14)#5 (Q11,12,13,14,15)#6 !(Q11,15)#7 3 - Tue Q2, Q11, Q12, Q14 Empty 4 - Wed WP2 Plenary WP2 Plenary 5 - Thr empty SG16 Plenary 6 - Fri SG16 Plenary SG16 Plenary Notes: *30 Fri and 2 Mon have split PM Schedules. (Qxx, Qyy) - Questions in parentheses meet in joint session. #1 - H.235V2, H.MediaMIB, T.130/H.AVC #2 - T.120 series Audio/Video requirements #3 - T.120 security, first 1/4 day in the afternoon #4 - Discussion of future directions, last 1/4 day in the afternoon #5 - Conference control, H.245V4, H.246 addition and other common protocols #6 - Video issues, first 1/4 day in the afternoon #7 - Future direction of advance video as it relates to H.324L, last 1/4 day in the afternoon

1 0

Draft WP2 workplna for Jan-Feb meeting
by Sakae Okubo 26 Nov '97

26 Nov '97

Dear Q.12-14/16 experts, Attached please find Mr. Tosco's initial draft of the coming WP2/16 meeting starting 26 January 1998. Mr. DeGrasse kindly converted Mr. Tosco's fax message into a Word document to which I added the topics of joint sessions as notes. This plan will be finalized after reflecting Rapporteurs' comments and negotiating with WP1 and WP3. 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

Draft WP2 workplna for Jan-Feb meeting
by Sakae Okubo 26 Nov '97

26 Nov '97

/// Please discart my previous mail; I forgot to make attachment. /// Dear Q.12-14/16 experts, Attached please find Mr. Tosco's initial draft of the coming WP2/16 meeting starting 26 January 1998. Mr. DeGrasse kindly converted Mr. Tosco's fax message into a Word document to which I added the topics of joint sessions as notes. This plan will be finalized after reflecting Rapporteurs' comments and negotiating with WP1 and WP3. 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 ******************************************************************** begin 666 WP2_PLAN.DOC MT,\1X*&Q&N$ .P # /[_"0 & ! M 0 $ @ $ #^____ #_____________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M_______________________]____!P /[___\$ !0 8 ( M_O____[___\* "P P - #@ \ 0 $0 /[_____ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M_____________________________________________P!2 M M " 4 __________\# D" # 1@ M ( PVM)Z^KP! P * 0!# &\ ;0!P $\ 8@!J M M !( @'_______________\ M 7 !7 &\ <@!D $0 ;P!C '4 ;0!E &X = M &@ " ?__ M__\$ _____P M D N$ $\ 8@!J &4 8P!T % ;P!O &P M 6 $! 0 ( #_ M____ FD'2>OJ\ 0":0=)Z^KP! M 0 /[_____________________________________________ M____________________________________________________________ M__________________________________________________________\A M (@ ", D )0 "8 G _O______________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M______________________________\! /[_ @ ! /____\ "0( , M !&' $UI8W)O<V]F="!7;W)D(#8N,"!$;V-U;65N= #^____3D(V M5Q !7;W)D+D1O8W5M96YT+C8 [ /__@ ) 8 M 0 $ 0 '____^ #_________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M_____________________________________________________P M M M ;P1,;45D!$-33VT$ M='1X= 1&5$-H!$U34U4$15A/1 135&DP!&)B:W($;5-%5 1-4U=$!'!C0TL$ M:V%J<@1%4%-)!%-%3C$$.$))301.24M+!&II9WH$1G*-,0180T5,!%1A<F\$ M34HQ,@124T5$!$U$4$P$161T-P0_/S\_!$9-4$H$1DA$4P1%6%12!$Y#4T$$ M1WII< 1P6DE0!$)35U4$875S= 17<F%P!%-)5"$$2V-V= 1+1D)9!$-!4D\$ M;5!!2P13251X!%9WE'H$34]34P1625,S!$)L5V0$34%#4P1*1414!$1$05 $ M.$E.290#BK* F #BD120494($U%151)3D<@4T-(14153$4@1D]2 M(%1(12!74#(O,38@345%5$E.1PT-#41A=&4@!T%-(%-C:&5D=6QE!U!-(%-C M:&5D=6QE!P<R-B#0($UO;@=31S$V(%!L96YA<GD'5U R(%!L96YA<GD'!S(W M("U4=64'43$Q+"!1,3(L(%$Q,P=31R Q-B!0;&5N87)Y!P<R." M(%=E9 =1 M,RP@43$Q+"!1,3(L(%$Q,P=1,RP@43$Q+"!1,3(L(%$Q,P<',CD@+2!4:'(' M43$L(%$S+"!1,3$L("A1,3(L,3,L,30I(S$'43$L(%$S+"!1,3$L("A1,3(L M,3,L,30I(S$'!S,P(- @1G)I("H'43$L(%$Q,2P@*%$S+#$R+#$S+#$T*2,R M!U$Q+" H43,L,3(L,3,L,30I(S,'43$L("A1,3$L,3(L,3,I(S0'!S(@T"!- M;VX@*@=1,2P@43,L("A1,3$L,3(L,3,L,30I(S4'43$L(%$S+" H43$Q+#$R M+#$S+#$T+#$U*2,V!U$Q+"!1,RP@*%$Q,2PQ-2DC-P<',R M(%1U90=1,BP@ M43$Q+"!1,3(L(%$Q- =%;7!T>0<'-"#0(%=E9 =74#(@4&QE;F%R>0=74#(@ M4&QE;F%R>0<'-2#0(%1H<@=E;7!T>0=31S$V(%!L96YA<GD'!S8@T"!&<FD' M4T<Q-B!0;&5N87)Y!U-',38@4&QE;F%R>0<'#4YO=&5S.B @*C,P($9R:2!A M;F0@,B!-;VX@:&%V92!S<&QI="!032!38VAE9'5L97,N( T)*%%X>"P@47EY M*2#0(%%U97-T:6]N<R!I;B!P87)E;G1H97-E<R!M965T(&EN(&IO:6YT('-E M<W-I;VXN#0DC,2 M($@N,C,U5C(L($@N365D:6%-24(L(%0N,3,P+T@N059# M#0DC,B M(%0N,3(P('-E<FEE<R!!=61I;R]6:61E;R!R97%U:7)E;65N=',- M"2,S("T@5"XQ,C @<V5C=7)I='DL(&9I<G-T(#$O-"!D87D@:6X@=&AE(&%F M=&5R;F]O;@T)(S0@+2!$:7-C=7-S:6]N(&]F(&9U='5R92!D:7)E8W1I;VYS M+"!L87-T(#$O-"!D87D@:6X@=&AE(&%F=&5R;F]O;@T)(S4@+2!#;VYF97)E M;F-E(&-O;G1R;VPL($@N,C0U5C0L($@N,C0V(&%D9&ET:6]N(&%N9"!O=&AE M<B!C;VUM;VX@<')O=&]C;VQS#0DC-B M(%9I9&5O(&ES<W5E<RP@9FER<W0@ M,2\T(&1A>2!I;B!T:&4@869T97)N;V]N#0DC-R M($9U='5R92!D:7)E8W1I M;VX@;V8@861V86YC92!V:61E;R!A<R!I="!R96QA=&5S('1O($@N,S(T3"P@ M;&%S=" Q+S0@9&%Y(&EN('1H92!A9G1E<FYO;VX-#0T) *$! *30+Z7@/=#/ M$>"AL1KA [ /__@ ) 8 M 04 4P!U &T ;0!A '( >0!) &X 9@!O '( ;0!A '0 :0!O &X M H ( ________________ M ( .0! M M #_______________\ M M M /_______________P M M M ________________ M _O\ ,* 0 0 M /*?A>!/^1!HJY$( "LGL]DP M $ \ ' F ( #C M! !D! ( *0$ $ Y 0 # #\! + 2P$ T !7 M 0 #P &,! 0 :P$ H !S 0 $@ '\! . F@$ D M "B 0 $P *P! $ ! $ __________\> 0P M $UA8VEN=&]S:"!(1#I!<'!L:6-A=&EO;G,Z@X^!6X-H@W:#C8-:@V*#5#I7 M;W)D(#8Z5&5M<&QA=&5S.DYO<FUA; > +@ $120494($U%151)3D<@ M4T-(14153$4@1D]2(%1(12!74#(O,38@345%5$E.1P > " &%K87-A M:V$ '@ @ !A:V%S86MA ( 1)T ZF/J=_J\ 4 @';3 M\LSG 4 8J6U>OJ\ 0, P ! > M $P $UI8W)O<V]F="!7;W)D(#8N, # !X " ,@ # M #__X "0 & $ ! #<I6@ 0\ )! M !E ! ! $ P 10< "X0 100 M X &P #@ M; &P. ; X !L#@ &P. ; X !0 "6 M#@ )8. E@X "6#@ )8. E@X H M "@#@ $ )8. ,P\ %0 "P#@ + . L X M "P#@ + . L X "P#@ + . M"P\ ( -#P T/ #0\ -#P T/ M #0\ "8 "'#P 6 -\/ !/ ,P\ M ; X "P#@ ! % $ @"P#@ + . M + . L X S#P + . M ; X !L#@ + . M + . L X "P#@ + . L X !L#@ M + . ; X "P#@ L/ M ( . ( B X X !L#@ &P. ; X M !L#@ + . "P\ "P#@ 6P + . M M !$4D%&5"!- M145424Y'(%-#2$5$54Q%($9/4B!42$4@5U R+S$V($U%151)3D<-#0U$871E M( =!32!38VAE9'5L90=032!38VAE9'5L90<',C8@T"!-;VX'4T<Q-B!0;&5N M87)Y!U=0,B!0;&5N87)Y!P<R-R M5'5E!U$Q,2P@43$R+"!1,3,'4T<@,38@ M4&QE;F%R>0<',C@@+2!7960'43,L(%$Q,2P@43$R+"!1,3,'43,L(%$Q,2P@ M43$R+"!1,3,'!S(Y("T@5&AR!U$Q+"!1,RP@43$Q+" H43$R+#$S+#$T*2,Q M!U$Q+"!1,RP@43$Q+" H43$R+#$S+#$T*2,Q!P<S,"#0($9R:2 J!U$Q+"!1 M,3$L("A1,RPQ,BPQ,RPQ-"DC,@=1,2P@*%$S+#$R+#$S+#$T*2,S!U$Q+" H M43$Q+#$R+#$S*2,T!P<R(- @36]N("H'43$L(%$S+" H43$Q+#$R+#$S+#$T M*2,U!U$Q+"!1,RP@*%$Q,2PQ,BPQ,RPQ-"PQ-2DC-@=1,2P@43,L("A1,3$L M,34I(S<'!S,@+2!4=64'43(L(%$Q,2P@43$R+"!1,30'16UP='D'!S0@T"!7 M960'5U R(%!L96YA<GD'5U R(%!L96YA<GD'!S4@T"!4:'('96UP='D'4T<Q M-B!0;&5N87)Y!P<V(- @1G)I!U-',38@4&QE;F%R>0=31S$V(%!L96YA<GD' M!PU.;W1E<SH@("HS,"!&<FD@86YD(#(@36]N(&AA=F4@<W!L:70@4$T@4V-H M961U;&5S+B -"2A1>'@L(%%Y>2D@T"!1=65S=&EO;G,@:6X@<&%R96YT:&5S M97,@;65E="!I;B!J;VEN="!S97-S:6]N+@T)(S$@+2!(+C(S-58R+"!(+DUE M9&EA34E"+"!4+C$S,"](+D%60PT)(S(@+2!4+C$R,"!S97)I97,@075D:6\O M5FED96\@<F5Q=6ER96UE;G1S#0DC,R M(%0N,3(P('-E8W5R:71Y+"!F:7)S M=" Q+S0@9&%Y(&EN('1H92!A9G1E<FYO;VX-"2,T("T@1&ES8W5S<VEO;B!O M9B!F=71U<F4@9&ER96-T:6]N<RP@;&%S=" Q+S0@9&%Y(&EN('1H92!A9G1E M<FYO;VX-"2,U("T@0V]N9F5R96YC92!C;VYT<F]L+"!(+C(T-58T+"!(+C(T M-B!A9&1I=&EO;B!A;F0@;W1H97(@8V]M;6]N('!R;W1O8V]L<PT)(S8@+2!6 M:61E;R!I<W-U97,L(&9I<G-T(#$O-"!D87D@:6X@=&AE(&%F=&5R;F]O;@T) M(S<@+2!&=71U<F4@9&ER96-T:6]N(&]F(&%D=F%N8V4@=FED96\@87,@:70@ M<F5L871E<R!T;R!(+C,R-$PL(&QA<W0@,2\T(&1A>2!I;B!T:&4@869T97)N M;V]N#0T-"0"A 0"DT"^EX#W_____________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M_________________P # !. P 3P, '$# !R P E@, )<# #$ P MQ0, 0$ %! 3P0 % $ "B! HP0 ,,$ #$! Y 0 .4$ M!0 04 ",% E!0 10< % ' #] /T _0#] /T _0#] /T _0#] /T M_?L M M M M M M M M "=0$ UT 8 , "X# O P , , M #8# !" P 3@, $\# !8 P 90, '$# !R P >@, (@# "6 P MEP, * # "R P Q , ,4# #. P Z0, 0$ %! $ 0 "D$ ] M! 3P0 % $ !:! <P0 (\$ "B! HP0 *L$ "]! PP0 ,0$ M #,! _@ !P"'< /X < AW #^ ' (=P ^P !@ 3< /L :8(W #[ %B M$-P Z0 !8A#< /L 8 $W #[ &F"-P ^P !8A#< .D 6(0W #[ & !-P M^P !I@C< /L 6(0W #I %B$-P ^P !@ 3< /L :8(W #[ %B$-P Z0 ! M8A#< /L 8 $W #[ *F"-P ^P !8A#< .D 6(0W #[ & !-P ^P !I@C< M /L 5H)W #[ $P!MP U@ !, ;< /L 8 $W #[ &F"-P ^P "6@G< /L M C &W #6 (P!MP ^P !@ 3< /L :8(W #[ %B$-P Z0 !8A#< /L 8 $ MW 2 8 1D!N&P NPD "0 ) D "0 ) +X, 24_^P$:@Z<&*0? M !$ !@!&0&X; "["0 ) D "0 ) D O@H Y3_[ 1J#J0? ( !@! $ M ";,! V 0 .0$ #E! [00 /,$ !0 04 D% 6!0 (P4 M "0% E!0 604 )<% "^!0 Z@4 !\& !D!@ L08 .0& !#!P M1 < $4' #] &F"-P _0 !8A#< .L 6(0W #] & !-P _0 !I@C< /T M 6(0W #K %B$-P _0 !@ 3< /T :8(W #] %B$-P ZP !8A#< .D < A M\ #I ' (=P Z0 !P"'< .D < AW #I ' (=P Z0 !P"'< .D < AW #I M ' (=P Z0 !P"'< .D < AW #I ' (=P Z0 !P"'< M M M M M 0 !$ !@!&0&X; "["0 ) D "0 ) D MO@H Y3_[ 1J#J0? ( !@!%PX #P ( $ 2P / P < ! \?\" !P M!DYO<FUA; " !@!=! !A"00 B $% \O^A M "( %D1E9F%U;'0@4&%R86=R87!H($9O;G0 !%! M! !%!P 0#_____ 0 $(/__ 0 100 # !0!P ! M P S 0 $4' % 8 6P '86MA<V%K82Y-86-I;G1O<V@@2$0Z5&5M<&]R M87)Y($ET96US.E=O<F0@5V]R:R!&:6QE($$@!V%K87-A:V$94D%-((-F@T*# M6(-..E=0,E]03$%.+D1/0_] X ! $0$ !$! " ! $ 1 0 !" M! 0 ! . "A@)4 !4&D %- %1I;65S($YE=R!2;VUA;@ ,!@ @!3>6UB M;VP "P8 $T 07)I86P "P:0 4T 5&EM97, %A"0 0 *@FR"<B"67Y*I %1I M;65S B 0 0",& T ( &@! )_3&V:STQMF ( % M ! "#$ M 0 M 3P "U$4D%&5"!-145424Y'(%-#2$5$54Q%($9/4B!42$4@5U R+S$V M($U%151)3D< '86MA<V%K80=A:V%S86MA -#/$>"AL1KA M [ /__@ ) 8 0 $ M 0 ( !_____@ ________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ (____________ end

2 1

H.323 gatekeeper problems
by Chia-Ming Tu 25 Nov '97

25 Nov '97

Hello everybody, Does anybody know the advantages/disadvantages between H.323 gatekeeper's　 "Gatekeeper routed call signalling" and "direct endpoint call signalling"? Thanks a lot! -- ======================= = Chia-Ming Tu　　　　　　　 = = bluejays(a)iii.org.tw = ======================= 　

1 0

Re: Inconsistent references to H.281
by Dave Lindbergh 25 Nov '97

25 Nov '97

At 09:11 AM 11/25/97 -0800, Toby Nixon wrote: >I think I've stated my position on the reflector regarding V.chat/T.chat -- >that it is clearly a "data" application, and it ought to be a T.120 app and >not ride directly on a logical channel or be in H.245 (at least in the >context of H.323). I tend to agree, except that so many people felt that T.120 is such a "burden" that it seemed that few would implment V.CHAT if it required T.120. That was the motiviation to allow it to be used without T.120, in a point-to-point mode. >I don't think I feel that way about camera control; it >just seems so closely tied to the video media stream, and not really "data". >It strikes me as more like chair/floor control than like chat. > >When would you ever have multipoint camera control -- I mean, wanting to >send camera commands to multiple endpoints simultaneously? I know you'd want >to be able to separately control multiple cameras. You'd use multipoint camera control anytime you are in a multipoint call and want to control the camera on a _particular_ far-end machine. This requires addressing of camera commands, and probably arbitration and locking if more than one person tries to control the same camera. This could be done in H.245, but that would require the MC/MCU to both support the new H.245 messages (an upgrade) and do some message routing and arbitration to make it work. This is adding new functionality to the MC/MCU H.245 stack, when these functions are already in the T.120 infrastructure. So it seems simpler to just use T.120 when mutlipoint function is need. Since T.120 is considererd "a burden" by some, and isn't needed for point-to-point, we can just run the same protocol by itself in a H.245 LC (ala V.CHAT). Keeping the core protocol separate from H.245 allows the SAME protocol to be used both point-to-point (in a H.245 LC) and multipoint (in T.120). If we put it in H.245 directly, we'd end up with two sets of syntax to keep sychnronized in ITU-T, one in H.245 and another in T.120. >Anyway, I think we can break the camera control out of T.130 and make it a >separate recommendation, and carry the PDU stream on a separate TCP >connection negotiated using H.245. Basically, parallel what was done for >H.224. Should it go through the MC, or directly to the controlled endpoint? For point-to-point I'm not sure. For multipoint, it would go in T.120 to the T.120 peer (probably the MC). >In Sunriver, didn't we officially move T.130 from Q3 to Q14? That would seem >to argue for presenting this to Q14 instead. > >Would we want all of the remote device control stuff, including speaker >volume, microphone gain and mute, etc.? I would think so. > >Do you want to move this discussion back out into public view and get input >from others? I'm cc:ing this to the H.323 list. --Dave L. > > -- Toby > >> -----Original Message----- >> From: Dave Lindbergh [SMTP:lindbergh@itu.ch] >> Sent: Monday, November 24, 1997 4:26 PM >> To: Toby Nixon >> Cc: duckworthm(a)pictel.com >> Subject: RE: Inconsistent references to H.281 >> >> Toby, >> >> At 02:37 PM 11/24/97 -0800, you wrote: >> >I'd be interested in working with you on this. Do we need some sort of >> >proposal for a work item at the next SG 16 meeting? Or just bring in a >> first >> >draft? I think this would go into Q14; do you agree? >> >> You could bring in a draft, but it would probably be better to >> start with a general discussion in the group to see if there's >> consensus on this direction, before a lot of work goes into it. >> Maybe that will happen on the reflector. >> >> I think we'd be interested in working with you on it. >> >> We were thinking about putting in a contribution into the Q3 meeting >> in Geneva, since we thought it belonged in the Q3 group more than >> in Q14. You could argue either way, I've no strong preference. >> >> >What's the compelling reason for opening a separate logical channel for >> >camera control instead of just issuing the commands directly in H.245? >> >> The main reasons are (a) keep down the clutter in H.245 (already bad), >> and (b) make it easier to have a T.120 "wrapper" around the RDC >> stuff for multipoint use. We'd like to see a solution that doesn't >> require upgrading all the MCUs and gateways every time we add a new >> terminal feature; T.120 does this nicely for multipoint (there is no issue >> for point-to-point). This is the same path ITU took for V.CHAT/T.CHAT, >> it seems like a good model for this, too. >> >> What do you think? Mark Duckworth here at PCTL has been looking >> at this from the Q3 viewpoint, I'm cc:ing him on this. >> >> --Dave L. >> >> >> >> > >> >> -----Original Message----- >> >> From: Dave Lindbergh [SMTP:lindbergh@ITU.CH] >> >> Sent: Sunday, November 23, 1997 3:22 PM >> >> To: ITU-SG16(a)MAILBAG.INTEL.COM >> >> Subject: Re: Inconsistent references to H.281 >> >> >> >> Toby/all, >> >> >> >> The H.224 codepoint in DataApplicationCapability.application.h224 of >> >> H.245 was put there for use with H.324; you can use H.224/H.281 >> >> to do far-end camera control in H.324. (H.224 itself negotiates >> >> the use of H.281; that's why you don't see H.281 in H.245.) >> >> >> >> My feeling (and I think this has been the view of the group >> >> as a whole) is that H.224/H.281 won't work for H.323. The H.281 >> >> control model is timing based: You send a message to start moving >> >> the camera (presumably at some slow, fixed rate), then another >> >> to stop it. Even with H.320 or H.324, this requires the user to >> >> "lead" the camera to compensate for end-to-end round trip delay. >> >> >> >> With H.323, any inconsistency in packet delivery times will make >> >> it impossible for the user to predictably control the camera. This >> >> could be partially fixed by adding timestamps to the messages, but >> >> only at the expense of buffering for the worst-case packet delivery >> >> time. >> >> >> >> I think the RDC portion of T.130 is a much better approach: It is >> >> not timing based, but based on absolute positioning of the camera >> >> ("turn left 24 degrees"). >> >> >> >> Since T.130 is stalled, I suggest we think about extracting the >> >> RDC portion of T.130 (clearly needed for H.323) and approving it >> >> as a separate Recommendation (not necessarily using T.120). We >> >> could follow much the same approach as with V.CHAT/T.CHAT: A simple >> >> stand-alone protocol (the RDC ASN.1 structures from T.130) which >> >> can be used point-to-point in a H.245 LC, and a multipoint version >> >> that makes use of a T.120 "wrapper" (ala T.CHAT) around the same >> >> simple protocol. >> >> >> >> --Dave Lindbergh >> >> >> >> >> >> >> >> At 03:01 PM 11/21/97 -0800, you wrote: >> >> >We were poking around a bit for information on far-end camera control, >> >> and >> >> >ended up searching for references to H.281 in most of the documents >> being >> >> >decided in January. As a result, we uncovered some inconsistencies >> that >> >> may >> >> >require editorial correction of the decided texts of H.245, H.246, and >> >> >H.323. >> >> > >> >> >(1) H.245 section 2 refers to 1996 versions of H.281 and H.224. We can >> >> find >> >> >only versions published in 1994. However, I note that although H.224 >> and >> >> >H.281 are listed as references, they are not actually referenced in >> the >> >> text >> >> >of H.245 anywhere, either by name or by the reference number. Either >> >> these >> >> >references should be deleted from section 2, or the dates changed to >> >> >"(1994)". >> >> > >> >> >(2) H.246 refers to H.281 and H.224 in section A.9, but they are not >> >> >included in the references in section 2. The solution here could be to >> >> >simply remove section A.9, since it is "for further study"; if this is >> >> not >> >> >done, H.281 and H.224 should be added to section 2. >> >> > >> >> >(3) H.323 version 2 refers to H.281 and H.224 in section 6.2.7, but >> >> neither >> >> >of these are included in the references in section 2. H.281 and H.224 >> >> should >> >> >be added to section 2. Note that H.323 version 1 had the same problem. >> >> > >> >> >The reference in H.323 and the presence of >> >> >DataApplicationCapability.application.h224 in H.245 seem to imply that >> >> >H.281/H.224 can be used in H.323 terminals. It would seem fairly >> >> >straight-forward to open a camera control data logical channel >> associated >> >> >with a video channel and send H.281 commands. Does anybody actually do >> >> that >> >> >today? Has it even been prototyped? Have details been worked out, such >> as >> >> >whether it would be a TCP or UDP connection? Or was this intentionally >> >> >postponed while T.130 work proceeded? If that's the case, should it be >> >> >resurrected considering the state of T.130? Is H.281 simply considered >> >> not >> >> >suitable for use on IP/Internet (due to latencies)? If so, is there >> >> desire >> >> >to work out H.245 extensions to do the same things? I'm sure you've >> all >> >> >discussed this before I was around; sorry. >> >> > >> >> > -- Toby >> >> >___________________________________________________________ >> >> >Toby Nixon, Program Manager - NetMeeting >> >> >http://www.microsoft.com/netmeeting >> >> >Microsoft Corporation, Applications and Internet Client Group, Redmond >> >> WA >> >> >USA >> >> >+1 (425) 936-2792 Fax: +1 (425) 936-7329 >> >> mailto:tnixon@microsoft.com >> >> > >> >> ------------------------------------------------------------------- >> >> Dave Lindbergh Email: lindbergh(a)pictel.com >> >> Manager, Technical Standards Group Voice: +1 978 623 4351 >> >> PictureTel Corporation Fax: +1 978 749 2804 >> >> 100 Minuteman Road - M/S 635 H.320: +1 978 437 0265 (twice) >> >> Andover MA 01810 USA http://standards.pictel.com >> >> PGP fingerprint: C8 3E 28 69 53 0A 4B 87 EF E0 11 CD AC 87 4D CD >> >> ------------------------------------------------------------------- >> > >> ------------------------------------------------------------------- >> Dave Lindbergh Email: lindbergh(a)pictel.com >> Manager, Technical Standards Group Voice: +1 978 623 4351 >> PictureTel Corporation Fax: +1 978 749 2804 >> 100 Minuteman Road - M/S 635 H.320: +1 978 437 0265 (twice) >> Andover MA 01810 USA http://standards.pictel.com >> PGP fingerprint: C8 3E 28 69 53 0A 4B 87 EF E0 11 CD AC 87 4D CD >> ------------------------------------------------------------------- > ------------------------------------------------------------------- Dave Lindbergh Email: lindbergh(a)pictel.com Manager, Technical Standards Group Voice: +1 978 623 4351 PictureTel Corporation Fax: +1 978 749 2804 100 Minuteman Road - M/S 635 H.320: +1 978 437 0265 (twice) Andover MA 01810 USA http://standards.pictel.com PGP fingerprint: C8 3E 28 69 53 0A 4B 87 EF E0 11 CD AC 87 4D CD -------------------------------------------------------------------

1 0

Re: Inconsistent references to H.281
by Dave Lindbergh 23 Nov '97

23 Nov '97

Toby/all, The H.224 codepoint in DataApplicationCapability.application.h224 of H.245 was put there for use with H.324; you can use H.224/H.281 to do far-end camera control in H.324. (H.224 itself negotiates the use of H.281; that's why you don't see H.281 in H.245.) My feeling (and I think this has been the view of the group as a whole) is that H.224/H.281 won't work for H.323. The H.281 control model is timing based: You send a message to start moving the camera (presumably at some slow, fixed rate), then another to stop it. Even with H.320 or H.324, this requires the user to "lead" the camera to compensate for end-to-end round trip delay. With H.323, any inconsistency in packet delivery times will make it impossible for the user to predictably control the camera. This could be partially fixed by adding timestamps to the messages, but only at the expense of buffering for the worst-case packet delivery time. I think the RDC portion of T.130 is a much better approach: It is not timing based, but based on absolute positioning of the camera ("turn left 24 degrees"). Since T.130 is stalled, I suggest we think about extracting the RDC portion of T.130 (clearly needed for H.323) and approving it as a separate Recommendation (not necessarily using T.120). We could follow much the same approach as with V.CHAT/T.CHAT: A simple stand-alone protocol (the RDC ASN.1 structures from T.130) which can be used point-to-point in a H.245 LC, and a multipoint version that makes use of a T.120 "wrapper" (ala T.CHAT) around the same simple protocol. --Dave Lindbergh At 03:01 PM 11/21/97 -0800, you wrote: >We were poking around a bit for information on far-end camera control, and >ended up searching for references to H.281 in most of the documents being >decided in January. As a result, we uncovered some inconsistencies that may >require editorial correction of the decided texts of H.245, H.246, and >H.323. > >(1) H.245 section 2 refers to 1996 versions of H.281 and H.224. We can find >only versions published in 1994. However, I note that although H.224 and >H.281 are listed as references, they are not actually referenced in the text >of H.245 anywhere, either by name or by the reference number. Either these >references should be deleted from section 2, or the dates changed to >"(1994)". > >(2) H.246 refers to H.281 and H.224 in section A.9, but they are not >included in the references in section 2. The solution here could be to >simply remove section A.9, since it is "for further study"; if this is not >done, H.281 and H.224 should be added to section 2. > >(3) H.323 version 2 refers to H.281 and H.224 in section 6.2.7, but neither >of these are included in the references in section 2. H.281 and H.224 should >be added to section 2. Note that H.323 version 1 had the same problem. > >The reference in H.323 and the presence of >DataApplicationCapability.application.h224 in H.245 seem to imply that >H.281/H.224 can be used in H.323 terminals. It would seem fairly >straight-forward to open a camera control data logical channel associated >with a video channel and send H.281 commands. Does anybody actually do that >today? Has it even been prototyped? Have details been worked out, such as >whether it would be a TCP or UDP connection? Or was this intentionally >postponed while T.130 work proceeded? If that's the case, should it be >resurrected considering the state of T.130? Is H.281 simply considered not >suitable for use on IP/Internet (due to latencies)? If so, is there desire >to work out H.245 extensions to do the same things? I'm sure you've all >discussed this before I was around; sorry. > > -- Toby >___________________________________________________________ >Toby Nixon, Program Manager - NetMeeting >http://www.microsoft.com/netmeeting >Microsoft Corporation, Applications and Internet Client Group, Redmond WA >USA >+1 (425) 936-2792 Fax: +1 (425) 936-7329 mailto:tnixon@microsoft.com > ------------------------------------------------------------------- Dave Lindbergh Email: lindbergh(a)pictel.com Manager, Technical Standards Group Voice: +1 978 623 4351 PictureTel Corporation Fax: +1 978 749 2804 100 Minuteman Road - M/S 635 H.320: +1 978 437 0265 (twice) Andover MA 01810 USA http://standards.pictel.com PGP fingerprint: C8 3E 28 69 53 0A 4B 87 EF E0 11 CD AC 87 4D CD -------------------------------------------------------------------

1 0

Inconsistent references to H.281
by Toby Nixon 21 Nov '97

21 Nov '97

We were poking around a bit for information on far-end camera control, and ended up searching for references to H.281 in most of the documents being decided in January. As a result, we uncovered some inconsistencies that may require editorial correction of the decided texts of H.245, H.246, and H.323. (1) H.245 section 2 refers to 1996 versions of H.281 and H.224. We can find only versions published in 1994. However, I note that although H.224 and H.281 are listed as references, they are not actually referenced in the text of H.245 anywhere, either by name or by the reference number. Either these references should be deleted from section 2, or the dates changed to "(1994)". (2) H.246 refers to H.281 and H.224 in section A.9, but they are not included in the references in section 2. The solution here could be to simply remove section A.9, since it is "for further study"; if this is not done, H.281 and H.224 should be added to section 2. (3) H.323 version 2 refers to H.281 and H.224 in section 6.2.7, but neither of these are included in the references in section 2. H.281 and H.224 should be added to section 2. Note that H.323 version 1 had the same problem. The reference in H.323 and the presence of DataApplicationCapability.application.h224 in H.245 seem to imply that H.281/H.224 can be used in H.323 terminals. It would seem fairly straight-forward to open a camera control data logical channel associated with a video channel and send H.281 commands. Does anybody actually do that today? Has it even been prototyped? Have details been worked out, such as whether it would be a TCP or UDP connection? Or was this intentionally postponed while T.130 work proceeded? If that's the case, should it be resurrected considering the state of T.130? Is H.281 simply considered not suitable for use on IP/Internet (due to latencies)? If so, is there desire to work out H.245 extensions to do the same things? I'm sure you've all discussed this before I was around; sorry. -- Toby ___________________________________________________________ Toby Nixon, Program Manager - NetMeeting http://www.microsoft.com/netmeeting Microsoft Corporation, Applications and Internet Client Group, Redmond WA USA +1 (425) 936-2792 Fax: +1 (425) 936-7329 mailto:tnixon@microsoft.com

1 0

Re: Where can I find the draft documents of ....
by Pete Cordell 21 Nov '97

21 Nov '97

The first one you should find at: ftp://itu-t:sg15!avc@ftp.gctech.co.jp/9801_Gen/h246whte.zip The other two are probably at: ftp://standard.pictel.com/lbc-site/ but you will have to look around a bit as they are probably in working document form and so not easily identifiable. Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Chen, Kuo-Yu[SMTP:cky902@N100.CCL.ITRI.ORG.TW] >Sent: 21 November 1997 02:53 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Where can I find the draft documents of .... > >hi, > >Where can I find the draft documents of H.246, H.DISPATCH, H.MULTILINK? > >Thank You! > > >Best Regards! > > > Kuo-Yu Chen > E-mail: cky902(a)isdn2.ccl.itri.org.tw > Tel: 886-3-5914805 > Fax: 886-3-5820081 > Digital Communication Dept., > Computer & Communication Research Lab., > Industrial Technology Research Institute, > Taiwan, ROC >

1 0

Where can I find the draft documents of ....
by Chen, Kuo-Yu 20 Nov '97

20 Nov '97

hi, Where can I find the draft documents of H.246, H.DISPATCH, H.MULTILINK? Thank You! Best Regards! Kuo-Yu Chen E-mail: cky902(a)isdn2.ccl.itri.org.tw Tel: 886-3-5914805 Fax: 886-3-5820081 Digital Communication Dept., Computer & Communication Research Lab., Industrial Technology Research Institute, Taiwan, ROC

1 0

Q.12-14/16 meeting in April 1998
by Sakae Okubo 20 Nov '97

20 Nov '97

Dear Q.12-14/16 experts, Please note that Japan hosting committee is going to invite the subject meeting to Yokosuka during 14-17 April 1998. Fill this date in your 1998 calendar. 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

SG16 meeting during 26 January - 6 February 1998
by Sakae Okubo 20 Nov '97

20 Nov '97

/// This may reach you twice since it was posted during Mr. Toga's /// // effort to solve the looping problem. /// Dear Q.12-14/16 experts, Please note that information regarding the next SG16 meeting (26 January - 6 February 1998) is available as follows: TSB Collective-letter 3/16 http://www.itu.ch/itudoc/itu-t/com16/coll/003_41377.html TSB Circular 73 http://www.itu.ch/itudoc/itu-t/circ/circ2/073_41826.html 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

List problems cleared?
by Jim Toga 19 Nov '97

19 Nov '97

Hello, I would like to apologize for the recent hiccup (maybe more like accute nausea) that occured on the sg-16 list. It resulted from a site which was responding to errors back to the list as opposed to the original sender. We have tightend up loop checking on the list server which should terminate these exchanges. Please let me know (many of you already do...!) if you see anything 'funny' in the future. In addition I would like to request that anyone that has subscribed to the sg-16 list with an address that is an internal mail list exploder, verify that it behaves 'well' on internal errors. In other words, errors from internal members are not generated towards the sg-16 listserv. Best Regards, jimt. ************************************************************************* *** +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

MultipointCapability's in H2250Capability
by Hong Linh Truong 19 Nov '97

19 Nov '97

Could anybody help me to shed more light into the meaning of the various MultipointCapability's that have to be coded within the H2250Capability? I went through its specification in H245 and the related sections in H323 and came to the following conclusions, which I'd like to ask for comments: Point 1: receiveMultipointCapability This "indicates the receive capabilities of a terminal in a multipoint conference" (H.245 section 7.2.2.4). If I understand H323 correctly, an endpoint should only support the following four multipoint capabilities (H323 section 6.8): (i) centralized audio and centralized video, (ii) distributed audio and distributed video, (iii) centralized audio and distributed video, and (iv) distributed audio and centralized video. Control and data are always centralized. The above capabilities are coded within the mediaDistributionCapability of the receiveMultipointCapability. "Centralized" means the endpoint cannot mix/switch the media stream; the mixing/switching has to be done by means of an MP. "Distributed" means the endpoint can do the mixing itself. In case of "centralized" the endpoint can receive the mixed/switched media stream either via an unicast or a multicast address; multi-unicast is not relevant in this context. In case of "distributed" the endpoint can receive the multiple media streams either via multi-unicast or via a multicast address and do the mixing/switching itself. The support of multicast address or multi-unicast is indicated in multicastCapability and multiUniCastConference. Resumee: The H245 receiveMultipointcapability is appropriate to describe the receive capabilities of a terminal in a multipoint conference. Point 2: transmitMultipointCapability This "indicates the transmit capabilities of a terminal in a multipoint conference". >From a transmit point of view "centralized" or "distributed" are not relevant. Relevant are only whether the endpoint support multicast and/or multi-unicast. Therefore the mediaDistributionCapability (mandatory) within the transmitMultipointCapability has no meaning and I'd propose to ignore it. Point 3: receiveAndTransmitMultipointCapability After having coded the receiveMultipointCapability and transmitMultipointCapability I don't know what kind of "new" information should an endpoint put into this parameter. Since all three are mandatory I'd propose to ignore that parameter! Point 4: H323 Section 6.8.1 "Centralized multipoint capability", last sentence: "Optionally, distributedAudio and distributedVideo may be used to indicate multicast distribution of media streams". I don't understand the meaning of that sentence, which is new added to H323 version 2. I thought, distributedAudio and distributedVideo indicate the endpoint capability of mixing/switching the media streams itself. The indication of whether multicast and/or multi-unicast is supported is done by means of multicastcapability and multiUniCastConference, and not by mediaDistributioncapability as stated in that sentence. I'd appreciate if somebody could give me an explanation of that sentence. I'd also appreciate any comments to the conclusions I put together above. Regards, Linh ----------------------------------------------------------- TRUONG Hong Linh email: hlt(a)zurich.ibm.com IBM Zurich Research Laboratory tel : +41 1 724 8434 CH-8803 Rueschlikon / Switzerland fax : +41 1 724 8955

1 0

test message
by Jim Toga 18 Nov '97

18 Nov '97

Sorry about the noise - please ignore. ************************************************************************* *** +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

Test message, ignore.
by Jim Toga 18 Nov '97

18 Nov '97

************************************************************************* *** +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

Re: Problems with the ASN.1 Syntax in H.235
by Jim Toga 31 Oct '97

31 Oct '97

Claudio, (Thanks for the comments) Yes, I am aware of this syntax error.... in the rush to file the white paper it snuck through. It along with anything else will be corrected in Geneva. As for the second point, hmmm.....? You are correct in that the implication is that timeStamp and generalID are to be required for use in the PwdCertToken. I'll have to go back and look at the recommendation, but I thought that the current construct implies that they must be present (along with any other optional values desired). If this is incorrect, it will certainly be fixed. Regards, jimt. At 02:58 PM 10/31/97 +0100, you wrote: >While working with the H.235 ASN.1 Symtax, I found a syntax error and >also a definition which seems to be wrong: > >1. A closing ')' is missing in the line > > EncodedGeneralToken ::= TYPE-IDENTIFIER.&Type (ClearToken) -- general usage token > --------^ > >2. PwdCertToken ::= ClearToken (WITH COMPONENTS {..., timeStamp, generalID }) > > As far as I understand this line, timeStamp and generalID should be > mandatory inside a PwdCertToken (if they should still be optional > there is no need to use a WITH COMPONENTS). Without the '...' we would > have a 'FullSpecification' and in this case the above line would > mean that timeStamp and generalID are now mandatory. However, this is > a 'PartialSpecification;, in which case no PresenceConstraint means that > no constraint is imposed (see x680, 45.8.9.3). > > The correct line would therefore be > > PwdCertToken ::= ClearToken > (WITH COMPONENTS {..., timeStamp PRESENT, generalID PRESENT}) > > Is this assumption correct? > >Thanks, > >Claudio Fleiner (cfl(a)zurich.ibm.com) > > ************************************************************************* *** +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