- sg16-avd - lists.packetizer.com

Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL
by Roy, Radhika R, ALCTA 31 May '01

31 May '01

Hi, Bob: All applications (e.g., H.323, SIP) uses signaling messages among its functional entities (e.g., terminal, agents, gatekeepers, proxies, gateways) for communications. The signaling messages that carry QOS parameters are treated as QOS signaling messages. The applications like SIP and H.323 send signaling messages end-to-end. H.323 uses H.225.0 RAS, Q.931, Annex G, and H.245 signaling protocols. SIP also uses SDP as a part of the signaling messages. The signaling messages that carry QOS related information can be treated as "End-to-End QOS signaling" messages. Kindly see the ongoing works of Q.F/16 of SG16. This will provide more information related to your questions. Hope this helps. Best regards, Radhika R. Roy -----Original Message----- From: Bob Braden [mailto:braden@ISI.EDU] Sent: Wednesday, May 30, 2001 7:39 PM To: gratta(a)lucent.com; sob(a)harvard.edu; mankin(a)ISI.EDU; Roy, Radhika R, ALCTA Cc: diffserv(a)ietf.org; iptel(a)lists.bell-labs.com; issll(a)mercury.lcs.mit.edu; megaco(a)fore.com; sip(a)lists.bell-labs.com; sipping(a)ietf.org; tsvwg(a)ietf.org; hiramatsu.yukio(a)lab.ntt.co.jp; rbuhrke(a)lucent.com; tsg11q8(a)ties.itu.ch; tsg11q9(a)ties.itu.ch; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL *> From owner-issll(a)mercury.lcs.mit.edu Wed May 30 14:59:58 2001 *> From: "Roy, Radhika R, ALCTA" <rrroy(a)att.com> *> To: gratta(a)lucent.com, sob(a)harvard.edu, mankin(a)ISI.EDU *> Cc: diffserv(a)ietf.org, iptel(a)lists.bell-labs.com, issll(a)mercury.lcs.mit.edu, *> megaco(a)fore.com, sip(a)lists.bell-labs.com, sipping(a)ietf.org, tsvwg(a)ietf.org, *> Yukio Hiramatsu *> <hiramatsu.yukio(a)lab.ntt.co.jp>, rbuhrke(a)lucent.com, *> tsg11q8(a)ties.itu.ch, tsg11q9(a)ties.itu.ch, ITU-SG16(a)mailbag.cps.INTEL.COM *> Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E *> ND-TO-END QOS SERVICE CONTROL *> Date: Wed, 30 May 2001 17:21:14 -0400 *> MIME-Version: 1.0 *> *> Hi, Everyone: *> *> Question Q.F/16 of ITU-T SG16 is fully dedicated for developing standards *> for "End-to-End QOS for Multimedia Applications". Contributions are also *> being under discussion in the ITU-T SG16 Brazil May 28 - June 8, 2001 *> meeting. This is very confusing. "End-to-End QOS for Multimedia Applications" is an really important topic, but this topic must be a superset of "End-to-End QOS signaling". There are much harder problems than signaling in providing E2E QoS. Can you explain how signaling relates to the title of this working party? Thanks, Bob Braden *> *> Applications like H.323, SIP, H.324, H.310, and others will also be able to *> use this Q.F/16's QOS signaling protocol. MEGACO/H.248 and BICC will also be *> able to use this when specs are fully developed and, TIPHON's QOS mechanisms *> can also be used as one of the mechanisms for implementations. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Generic Extensibility Framework elements in SETUP are different from those in other Call Signalling messages, why?
by Frank Derks 31 May '01

31 May '01

The SETUP messages contains the three elements neededFeatures, desiredFeatures and supportedFeatures. The other call signalling messages contain on single featureSet element that includes these three elements. Why does the SETUP message deviate frome the other call signalling messages? Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: Why use two different "H.248 mechanisms" in H.323?
by Frank Derks 31 May '01

31 May '01

Hi Manoj, am I to assume that the first "context" you mention is the use of H.248 _Signals_ in serviceControlSession elements and that the third "context" refers to the use of H248Packages in the supportedH248Packages element in the RRQ? I assumed, but this may be wrong on second thoughts, that these two uses were tied together. I.e. supportedH248Packages specifies from which packages _signals_ may be used. supportedH248Packages is not required (and should not be used) for Annex L, as an Audit command can be used to obtain the supported packages. Regards, Frank ----------------------------------------------------- Frank Derks |Tel +31 35 6893238 | ServWare |Fax +31 35 6891030 | Philips Business Communications|P.O. Box 32 | |1200 JD Hilversum | |The Netherlands | ----------------------------------------------------| E-mail: mailto:frank.derks@philips.com | WWW: http://www.sopho.philips.com | ----------------------------------------------------- mpaul(a)trillium.com on 30-05-2001 19:04:57 To: ITU-SG16@mailbag.cps.INTEL.COM@SMTP Frank Derks/HVS/BE/PHILIPS@EMEA2 cc: Subject: RE: Why use two different "H.248 mechanisms" in H.323? Classification: Hi Frank, H.248 appears in H.323 in three contexts 1) Credit card tones and announcements from Gk. 2) Annex L 3) Endpoints reporting their H248 PackageDescriptors to Gks in RRQ. Although Annex L defined H.248 messages as Octet Strings, the other two imported H.248 syntax. There was a proposal in last SG16 meeting to change them to Octet Strings as well for the reasons- Those who were not willing to support H.248 functionality, would not have to import the H.248 syntax (For Signals and Pacakges for (1) and (3) above). Also these octet strings were proposed to contain PER encoded H.248. (Text in addition for Annex L) to allow single encoding and decoding scheme, namely PER for H.323. I believe, it is due to lightweight reasons (as you pointed out), that ServiceControlSession also contained H.248 Signals which could as well be transported using Annex L. regards Manoj. -----Original Message----- From: Frank Derks [mailto:frank.derks@PHILIPS.COM] Sent: Wednesday, May 30, 2001 12:24 AM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Why use two different "H.248 mechanisms" in H.323? There are two ways in which H.248 can be used in H.323. One way is through Annex L Stimulus Signalling, which basically "tunnels" H.248 messages in H.225.0 Call Signalling Messages (although Annex L only speaks about "commands", I assume that "replies" may also be carried). Another way of carrying H.248 is through the serviceControlSession element, which can be transported in most of the Call Signalling messages and some of the RAS messages. Using this mechanism, however, introduces a limitation in that only H.248 _signals_ may be transported. If the idea behind the second approach is to have a "lightweight" way of using only some of H.248's functionality, then I wonder why H.248 _events_ were not included as part of the solution. Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Why use two different "H.248 mechanisms" in H.323?
by Paul, Manoj 30 May '01

30 May '01

Hi Frank, H.248 appears in H.323 in three contexts 1) Credit card tones and announcements from Gk. 2) Annex L 3) Endpoints reporting their H248 PackageDescriptors to Gks in RRQ. Although Annex L defined H.248 messages as Octet Strings, the other two imported H.248 syntax. There was a proposal in last SG16 meeting to change them to Octet Strings as well for the reasons- Those who were not willing to support H.248 functionality, would not have to import the H.248 syntax (For Signals and Pacakges for (1) and (3) above). Also these octet strings were proposed to contain PER encoded H.248. (Text in addition for Annex L) to allow single encoding and decoding scheme, namely PER for H.323. I believe, it is due to lightweight reasons (as you pointed out), that ServiceControlSession also contained H.248 Signals which could as well be transported using Annex L. regards Manoj. -----Original Message----- From: Frank Derks [mailto:frank.derks@PHILIPS.COM] Sent: Wednesday, May 30, 2001 12:24 AM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Why use two different "H.248 mechanisms" in H.323? There are two ways in which H.248 can be used in H.323. One way is through Annex L Stimulus Signalling, which basically "tunnels" H.248 messages in H.225.0 Call Signalling Messages (although Annex L only speaks about "commands", I assume that "replies" may also be carried). Another way of carrying H.248 is through the serviceControlSession element, which can be transported in most of the Call Signalling messages and some of the RAS messages. Using this mechanism, however, introduces a limitation in that only H.248 _signals_ may be transported. If the idea behind the second approach is to have a "lightweight" way of using only some of H.248's functionality, then I wonder why H.248 _events_ were not included as part of the solution. Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

AW: Status of H.323 Annex L
by Horvath Ernst 30 May '01

30 May '01

Frank, H.323 Annex L was approved using the new approval procedure after the November 2000 meeting of SG16, and can be found on the latest CD-ROM from ITU-T. Ernst > -----Ursprüngliche Nachricht----- > Von: Frank Derks [mailto:frank.derks@PHILIPS.COM] > Gesendet am: Dienstag, 29. Mai 2001 19:51 > An: ITU-SG16(a)mailbag.cps.INTEL.COM > Betreff: Status of H.323 Annex L > > The latest version of H.323 Annex L that I could find is the > one that was > submitted to the Osaka meeting in May 2000. At the November > 2000 meeting in > Geneva a document (APC-2025) was submitted, that raises some > concerns about > the then current state of the Annex. > > What is the state of this Annex today? > > Regards, > > Frank > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Why use two different "H.248 mechanisms" in H.323?
by Frank Derks 30 May '01

30 May '01

There are two ways in which H.248 can be used in H.323. One way is through Annex L Stimulus Signalling, which basically "tunnels" H.248 messages in H.225.0 Call Signalling Messages (although Annex L only speaks about "commands", I assume that "replies" may also be carried). Another way of carrying H.248 is through the serviceControlSession element, which can be transported in most of the Call Signalling messages and some of the RAS messages. Using this mechanism, however, introduces a limitation in that only H.248 _signals_ may be transported. If the idea behind the second approach is to have a "lightweight" way of using only some of H.248's functionality, then I wonder why H.248 _events_ were not included as part of the solution. Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Status of H.323 Annex L
by Frank Derks 29 May '01

29 May '01

The latest version of H.323 Annex L that I could find is the one that was submitted to the Osaka meeting in May 2000. At the November 2000 meeting in Geneva a document (APC-2025) was submitted, that raises some concerns about the then current state of the Annex. What is the state of this Annex today? Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

What is the purpose of UserInputSupportIndication in UserInputIndication and where are the string types used?
by Frank Derks 29 May '01

29 May '01

Through the UserInputCapability (during the capabilities exchange), an EP can signal which string type(s) it supports for "user input". The UserInputSupportIndication in the UserInputIndication message carries similar information, but it is not clear for what purpose it is included in the UserInputIndication. Furthermore, the "signal" element in the UserInputIndication can only carry an IA5String type and the extendedAlphanumeric element can only carry strings of type GeneralString, so what is the purpose of informing the other party about supported string types that will never be used anyway? Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Documents for the Porto Seguro meeting
by OKUBO Sakae 24 May '01

24 May '01

Dear SG16 experts, The following documents have been placed at <http://standard.pictel.com/ftp/avc-site/0105_Por/> for your review: TITLE: Response to Liaison Statement to SG16 on Work Programme of Study Group 9 File: liaison_Response_to_Liaison.zip SOURCE: Rapporteur for Q.G/16 Title: H.248 Implementors' Guide for approval (D130) File: DC-xxx_H248_Implementors_Additions_v7.doc Source: Editor Title: H.248 Annex L for approval (D128) File: DC-xxx_Annex_L.doc Source: Editor Title: H.248 Annex M.2 Congestion Package for approval (D131) File: DC-xxx_Load_Control_package_v1.doc Source: Editor Title: Extendable Context Properties for H.248 v2 File: DC-xxx_Context_Property_v2.doc Source: LM Ericsson Note: ABNF will be added Title: Handling of multiple pending transactions in H.248 File: TD-xxx_Transaction_Pending.doc Source: LM Ericsson Title: H.248v2 File: TD-xxx_H248_v2.doc Source: Editor Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 ********************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Support of H.248 in H.323 - No events?
by Frank Derks 23 May '01

23 May '01

As from version 4 of H.323, stimulus signalling using H.248 is possible with H.323. The H.225.0 ASN.1 has been extended with an H248PackagesDescriptor (PackagesDescriptor from H.248) and an H248SignalsDescriptor (SignalsDescriptor from H.248) to make this possible. The first allows for the specification of the package(s) from which signals/event may be used. The second, however, would seem to restrict the use of H.248 to signals only. I.e. H.248 events can not be carried by H.323 because there is no field for the EventsDescriptor. Is this intentional and if so why? (Or do I misinterpret things?) Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1