May 2001 - sg16-avd - lists.packetizer.com

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

AW: AW: Annex Gv2
by Klaghofer Karl ICN EN HC ID 71 23 May '01

23 May '01

Paul made a reasonable proposal. Regards, Karl -----Ursprüngliche Nachricht----- Von: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Gesendet: Dienstag, 22. Mai 2001 16:21 An: ITU-SG16(a)mailbag.cps.INTEL.COM Betreff: Re: AW: Annex Gv2 Ernst, I have proposed previously that we consider extracting Annex G from H.225.0 and letting it stand on its own (as H.22x, for example). If we did that, perhaps it would address some people's concerns. Paul ----- Original Message ----- From: "Horvath Ernst" <ernst.horvath(a)SIEMENS.AT> To: <ITU-SG16(a)mailbag.cps.INTEL.COM> Sent: Tuesday, May 22, 2001 5:38 AM Subject: AW: Annex Gv2 > Paul, > > I welcome the proposal not to approve H.225.0 annex G v2 now. > > In my contribution to Q.5/16 I suggest to make the mobility management > protocol a "profile" of the annex G protocol, after adding the few extras > that mobility management would require. However, some members strongly > oppose to calling mobility management "H.225.0 annex G". Since the arguing > is about names rather than content, it would be undesirable to duplicate the > work and define nearly identical protocols in two different recommendations. > > > Maybe we can define a "master protocol" in a separate recommendation and > then derive various profiles from this master protocol: for the current > annex G (reference point A), for reference point B (GK-BE), for mobility > management, etc. > > Regards, > Ernst Horvath > Siemens AG > > > -----Ursprüngliche Nachricht----- > > Von: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > > Gesendet am: Dienstag, 22. Mai 2001 06:14 > > An: ITU-SG16(a)mailbag.cps.intel.com > > Betreff: Re: Annex Gv2 > > > > Paul, > > > > I think the decisions made for H.225.0 Annex Gv2 as it > > relates to Q.5 work > > should be considered, but I stress even more the other two issues: the > > editor feels that the content has not changed significantly enough and > > comments I've received from others relating to reference > > point D. I believe > > the latter two issues are most significant. > > > > Two questions I hear from people often are "How does the GK > > talk to the BE?" > > and "What good does it do to have the usage information in > > Annex G when it > > can't be passed to/from the GK?" Consideration should be > > given to whether > > those questions are adequately answered (which they're not) > > and whether we > > want to answer those question within the protocol at this time. > > > > Paul > > > > ----- Original Message ----- > > From: "Reddy, Paul K" <paul.k.reddy(a)INTEL.COM> > > To: <ITU-SG16(a)mailbag.cps.INTEL.COM> > > Sent: Monday, May 21, 2001 7:48 PM > > Subject: Re: Annex Gv2 > > > > > > > Hi Radhika, > > > > > > With respect to your point on 2a, Q.5/16 has been defined > > the Objectives, > > > scope, work plan for study period 2001-2004 during last Rapporteur's > > meeting > > > in Lanceston, Australia. As far as the protocol for H.MMS.1 > > (Mobility for > > > Multimedia systems based on H.323) recommendation has not > > been decided as > > of > > > last meeting. Your contributions and other contributions > > have come in for > > > Porte Seguro's meeting in Brazil will consider for > > discussion on Mobility > > > protocols like H.MMS.General (based on H.225.0 AnnexG or > > other protocol > > > etc.) > > > > > > PS: Paul, I would recommend not to delay the approval of > > H.225.0 Annex > > Gv2, > > > if Annex Gv2 does not include the Mobility work. - Paul > > > > > > regards, > > > Paul > > > > > > Paul K. Reddy > > > Rapporteur for Q.5/16 > > > Intel Corporation, Mailstop:JF3-377 > > > 2111 N.E. 25th Avenue, > > > Hillsboro, OR - 97229, USA > > > Office Phone # +1 (503)-264-9896 > > > Mobile Phone # +1 (503)-807-9564 > > > Email: paul.k.reddy(a)intel.com > > > > > > > > > -----Original Message----- > > > From: Roy, Radhika R [mailto:rrroy@ATT.COM] > > > Sent: Monday, May 21, 2001 9:18 AM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Re: Annex Gv2 > > > > > > > > > Hi, Paul: > > > > > > Let me explain where H.225.0 Annex G may fit with respect > > to mobility as > > > well as non-mobility as follows: > > > > > > 1. Anything extension that does NOT deal with MOBILITY in > > H.225.0 Annex G > > > version 2 can be considered for approval. > > > > > > 2. Anything that deals with MOBILITY (or with an intention > > to support > > > mobility indirectly) in H.225.0 Annex G version 2 MUST NOT > > be considered > > for > > > approval because of the following: > > > > > > a. The scope and reference points of mobility Q.5/16 needs > > to be defined > > > that is consistent with its charter. > > > > > > b. H.MMS.x work will be defined and completed in accordance > > to item a. > > > > > > c. All applications can use the common protocol for > > HLF/VLF/AuF (and other > > > value-added services). It will be a new protocol and will > > NOT have any > > > application-specific name (e.g., H.225.0 Annex G). > > > > > > d. As soon as we complete item c, we will see what needs to > > be done for > > > H.323. In H.323, we may have to extend H.225.0 RAS + > > H.225.0 Annex G. > > These > > > are application-specific extensions to support MOBILITY > > (applicable for > > each > > > application as well: H.310, H.324, IMT-2000, etc.). > > > > > > This is what has been proposed by AT&T in all contributions. > > > > > > Hope this will help. > > > > > > Best regards, > > > Radhika R. Roy > > > AT&T > > > > > > -----Original Message----- > > > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > > > Sent: Sunday, May 20, 2001 10:06 PM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Annex Gv2 > > > > > > > > > Folks, > > > > > > The editor of Annex G has recommended that we not approve > > Annex G at this > > > meeting, citing that there is insufficient material to > > warrant approval. > > I > > > have also heard comments from some that additional work > > should be done in > > > the area of defining reference point D. Of course, we also > > have the open > > > question of where (if anywhere) Annex G fits into the H.MMS.x work. > > > > > > For the benefit of those not planning to attend the > > meeting, please tell > > me > > > if you would have objections to *not* approving Annex Gv2 > > at this meeting. > > > > > > Thanks, > > > Paul > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > 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 > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > 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 > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0