- sg16-avd - lists.packetizer.com

TD-50/Osaka - Changes to the conferenceGoal field
by Rich Bowen 19 Jun '00

19 Jun '00

All, In Osaka we agreed to add support for packages to H.225.0 along the lines of TD-50 (ftp://standard.pictel.com/avc-site/0005_Osa/TD-50.zip). There was some concern raised about the proposed modifications to the conferenceGoal field in the Setup message. The meeting report states: "Some issues were raised about conflicts in the usage of the conference goal field between this new method and H.450.x. A possible solution is to create a new field in the ASN.1 to avoid conflicts. The editors are empowered to work with interested parties to resolve these conflicts in the ASN.1 before the white paper is issued." The modification proposed in TD-50 was the addition of the "neededFeatures" field to the confereceGoal field of the Setup-UUIE: conferenceGoal CHOICE { create NULL, join NULL, invite NULL, ..., capability-negotiation NULL, callIndependentSupplementaryService NULL, --> neededFeatures NeededFeatureGoal }, where the NeededFeatureGoal structure is defined as: NeededFeatureGoal ::= SEQUENCE { basicGoal CHOICE { create NULL, join NULL, invite NULL, capability-negotiation NULL, callIndependentSupplementaryService NULL, ... } OPTIONAL, features SEQUENCE OF SupportedFeatures, ... } An alternative approach would be to add a neededFeatures field at the highest level of the Setup-UUIE ASN.1 instead of inside the conferenceGoal structure, similar to the way the desirededFeatures and supportedFeatures fields will be added (see TD-50), like this: Setup-UUIE ::= SEQUENCE { [snip] --> neededFeatures SEQUENCE OF SupportedFeatures OPTIONAL, desiredFeatures SEQUENCE OF SupportedFeatures OPTIONAL, supportedFeatures SEQUENCE OF SupportedFeatures OPTIONAL } The motivation for adding neededFeatures to the conferenceGoal field was to force a call failure when trying to setup a call to pre-v4 endpoint and there is some v4 or later feature that is *required* for the call. The mechanism is intended to work like this: o The v4 EP sends Setup to the pre-v4 endpoint, and specifies some required feature in the neededFeatures field of the conferenceGoal. o The pre-v4 EP doesn't recognize the neededFeatures field as a supported CHOICE for a conferenceGoal, so it sends Release Complete. There would not be any conflicts with H.450, as suggested in the meeting report, because if the callIndependentSupplementaryService was needed, it would still be specified. The difference is that, if a neededFeature was also required, the H.450 goals would be specified inside the NeededFeatureGoal structure, which v4 and later endpoints would be aware of. These are the pros and cons of adding neededFeatures to the conferenceGoal vs. adding it to Setup-UUIE, IMO: o Advantages: - *May* force an early call release if a required feature is not supported by a pre-v4 endpoint. o Disadvantages: - ASN.1 and thus implementation would be more complex. Potentially have to check the conferenceGoal in two structures instead of one. - If pre-v4 EP sends Release Complete, there is no way to know whether it was sent because of an unrecognized conferenceGoal, because there is no ReleaseCompleteReason defined for that purpose. - H.323 does not require failing a call if the conferenceGoal is unrecognized, so the mechanism may not work at all. Although I think this mechanism is a good idea (and I supported it in Osaka), at this point I don't think it would work reliably enough to justify the added complexity. So I would prefer the alternative approach described above, adding the neededFeatures field directly to the Setup-UUIE. Okay, fire away. :-) Regards, Rich -------------------------------------------------------------------- Richard K. Bowen Cisco Systems, Inc. VoIP Session Protocols Research Triangle Park, NC, USA -------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

SG16 meeting on 15 June
by Sakae OKUBO 18 Jun '00

18 Jun '00

Dear Q12-14/16 experts, This is to forward Mr. Freundlich's message regarding the subject matter. 1) H.248 was approved. 2) Two day meeting on 9-10 November was approved. This will be run according to the Rapporteur meeting procedures, not those of SG16 meeting. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

TD-54a/Osaka: New ReleaseCompleteReason for Annex M?
by Rich Bowen 18 Jun '00

18 Jun '00

Mr. Holm and others, In Osaka it was suggested during the discussion of TD-54a (Draft Annex M.2, ISUP tunneling) that a new ReleaseCompleteReason is needed to support tunnelling. The reason would indicate that the called endpoint is dropping the call because it rejects tunnelling and the tunnellingRequired flag was set in the Setup message. My notes indicate that I was to look into whether this was needed in H.225.0 v4. The existing reasons are: ReleaseCompleteReason ::= CHOICE { noBandwidth NULL, -- bandwidth taken away or ARQ denied gatekeeperResources NULL, -- exhausted unreachableDestination NULL, -- no transport path to the destination destinationRejection NULL, -- rejected at destination invalidRevision NULL, noPermission NULL, -- called party's gatekeeper rejects unreachableGatekeeper NULL, -- terminal cannot reach gatekeeper for ARQ gatewayResources NULL, badFormatAddress NULL, adaptiveBusy NULL, -- call is dropping due to LAN crowding inConf NULL, -- no address in AlternativeAddress undefinedReason NULL, ..., facilityCallDeflection NULL, -- call was deflected using a Facility message securityDenied NULL, -- incompatible security settings calledPartyNotRegistered NULL, -- used by gatekeeper when endpoint has -- preGrantedARQ to bypass ARQ/ACF callerNotRegistered NULL, -- used by gatekeeper when endpoint has -- preGrantedARQ to bypass ARQ/ACF newConnectionNeeded NULL, -- indicates that the Setup was not accepted on this -- connection, but that the Setup may be accepted on -- a new connection nonStandardReason NonStandardParameter, replaceWithConferenceInvite ConferenceIdentifier -- call dropped due to subsequent -- invitation to a conference -- (see H.323 8.4.3.8) } So I'll ask ... is a new reason needed? If so, Mr. Holm's draft contains an editor's note that suggests a reason code of "tunnelRejected". Should I incorporate that value as a ReleaseCompleteReason? If so, what Q.931/Q.850 mapping should I add to Table 5/H.225.0 for this reason? Some suggestions: 63 - Service or option not available, unspecified 88 - Incompatible destination 111 - Interworking, unspecified Thanks, Rich -------------------------------------------------------------------- Richard K. Bowen Cisco Systems, Inc. VoIP Session Protocols Research Triangle Park, NC, USA -------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H.248 Annex F, Facsimile, text conversation and call discrimination packages, white doc candidate for Q9/16 meeting
by Gunnar Hellstrom 18 Jun '00

18 Jun '00

Attached you can find a revised version of the H.248 packages for fax, text and call discrimination. They are to be reviewed in the Q9/16 and Q4/16 meeting in Edinburgh June 28-30. Comments from Q4/8 for fax are incorporated. Expected output: A white doc for proposed decision in November. Please review. The documents for the Q9/16 meeting are also available in www.omnitor.se/English/standards Regards Gunnar Hellstrom ------------------------------------------ Gunnar Hellstrom LM Ericsson E-mail gunnar.hellstrom(a)omnitor.se Tel +46 8 556 002 03 Mob +46 708 204 288 fax +46 8 556 002 06

1 0

White contributions for the November 2000 meeting of SG16
by Sakae OKUBO 17 Jun '00

17 Jun '00

Dear Q12-14/16 experts, Draft Recommendations for decision in November 2000 are placed at the following directory: ftp://standard.pictel.com/avc-site/0011_Gen/ or http://standard.pictel.com/ftp/avc-site/0011_Gen/ H.323 Annex M.1 and H.450.9 texts have been moved there. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Auto Replied Message
by eltonj＠SAMSUNG.CO.KR 16 Jun '00

16 Jun '00

Hello, Thank you for the message . . . I am away from office (maybe on a business trip). However, I have an e-mail access (both Single and regular e-mail) wherever I am (as far as I have a phone line). Let me just get back to you shortly. BTW, I might be reached at (XXX) XXX-XXXX. Thank you, DS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H.323 Annex M.1 White Paper
by Francois Audet 16 Jun '00

16 Jun '00

I have sent the Whitepaper for H.323 Annex M.1 on QSIG tunnelling to Mr. Bigi. The document is available in: ftp://standard.pictel.com/avc-site/Incoming/. ----- François Audet Tel:+1 408 565 5675 mailto:audet@NortelNetworks.com Nortel Networks Fax:+1 408 565 2375 http://www.NortelNetworks.com

1 0

H.450.9 Whitepaper Call Completion service
by Klaghofer Karl ICN SIB NL D1 16 Jun '00

16 Jun '00

As agreed in the Osaka meeting, I have sent my input for the Whitepaper to Mr. Bigi already today. The document I sent to ITU as my whitepaper input is a clean copy of the document I have put on the pictel site for your review on May 31 ( ftp://standard.pictel.com/avc-site/0011_Gen/ ). I.e. there had been no changes since that. Regards, Karl Klaghofer, Siemens AG - Editor of H.450.9 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: H.323 URL
by Callaghan, Robert 16 Jun '00

16 Jun '00

Orit, In my opinion, an email-ID alias conforms to RFC-822 and is interpreted according the rules stated in H.225.0. An H.323-URL-ID conforms to TD-40a/Osaka and is interpreted according to the rules stated in TD-40a. An H.323-ID is a character string without any rules of interpretation. I see no need to blend these contexts. All three addressing modes can be use; each in its own context. However, these are my opinion. Maybe more work is needed in Portland. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Orit Levin [mailto:orit@radvision.com] Sent: Wednesday, June 14, 2000 11:45 AM To: Callaghan, Robert; 'Paul E. Jones' Cc: Mailing list for parties associated with ITU-T Study Group 16 (E-mail) Subject: Re: H.323 URL Hello Bob and Paul! I don't see backwards compatibility problem, when the URL says explicitly H323-URL. An appropriate change may be to state, that the default meaning of url, encoded into email-ID alias, is according to RFC-822. Now, I feel a need to put a chapter explaining what is the meaning of email URL (apart from its syntax) when used in H.323 Network. There is some explanation in H.225.0 Appendix IV. Do you find it clear and sufficient? Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit(a)radvision.com -----Original Message----- From: Callaghan, Robert <Robert.Callaghan(a)icn.siemens.com> To: 'Paul E. Jones' <paulej(a)PACKETIZER.COM>; 'Orit Levin' <orit(a)radvision.com> Cc: Mailing list for parties associated with ITU-T Study Group 16 (E-mail) <ITU-SG16(a)mailbag.cps.intel.com> Date: Wednesday, June 14, 2000 9:56 AM Subject: H.323 URL >Paul, > >I have a backward compatibility item for you to think about. > >TD-40/Osaka states that the H323-URL may be coded into the email-ID for >alias address. However, H.225.0 states that the email-ID shall conform to >RFC822. This is an exclusionary requirement in that other standards may not >be used. Also, Note 4 of the BNF definition of the H323-URL clearly states >that that the H323-URL is *not* compatible with RFC822. > >Therefor, I propose that the H323-URL cannot be coded into the email-ID for >alias address because of compatibility problems. > >Bob > >------------------------------------------------------------------ >Robert Callaghan >Siemens Enterprise Networks >Tel: +1.561.923.1756 Fax: +1.561.923.1403 >Email: Robert.Callaghan(a)ICN.Siemens.com >------------------------------------------------------------------ > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

3 2

h.323+java clients
by Apoorv Misra 15 Jun '00

15 Jun '00

Does H.323 support JAVA clients? Shachi Singh, Developer, PARSEC Technologies India Ltd. India. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1