- sg16-avd - lists.packetizer.com

Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL
by Callaghan, Robert 01 Jun '01

01 Jun '01

Please note that the network layer QOS (e.g., RSVP, DiffServe, and/or MPLS) may or may not have the end-to-end significance. For example, an IP network may implement different QOS schemes in different domains (e.g., RVSP in one domain, DiffServ in another domain). However, the application layer QOS is end-to-end that remains the same. For example, an H.323 or SIP call that can traverse several IP domains where each domain may implement its own network layer QOS schemes while the H.323/SIP call carry the signaling messages and QOS parameters end-to-end independent of the underlying network layer QOS mechanisms. Yes, the application layer is end-to-end. But does it traverse the exact same route as RTP transport layer? I don't think so, in that this is not IP. IP routes each packet individually with the right to change routes independently for each stream, and each packet in a stream. This is the basis for load balancing, overload control, and link failure survivability. With this in mind, the application layer can negotiate an end-to-end QOS with the ends. It cannot control the intermediate routing nodes. A method is needed to accomplish the end-to-end QOS control via the RTP IP stream. Bob -------------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks 5500 Broken Sound Blvd, Boca Raton, Fl 33487 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

1 0

AW:
by Euchner Martin 01 Jun '01

01 Jun '01

I think that's correctly stated. Kind Regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M NT 5 mailto:Martin.Euchner@icn.siemens.de <mailto:Martin.Euchner@icn.siemens.de> | mailto:martin.euchner@ties.itu.int <mailto:martin.euchner@ties.itu.int> | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/network_technology/security/pki.htm | D-81359 Muenchen Internet: http://www.siemens.de <http://www.siemens.de> | __________________ | Germany ----------------------------------------------------------------------- -----Ursprüngliche Nachricht----- Von: ssilvy(a)HSS.HNS.COM [SMTP:ssilvy@HSS.HNS.COM] Gesendet am: Freitag, 1. Juni 2001 06:26 An: ITU-SG16(a)mailbag.cps.INTEL.COM Betreff: Hi, In case of initial RRQ when EPID is not available the table D.10 in H235v2 says that sendersID would be NULL. So the hash would be calculated with sendersID as NULL when the identification information i.e EPID is not available as in initial RRQ. Silvy. Nagesh Kumar B V 06/01/2001 10:40 AM To: Silvy Samuel/HSSBLR@HSSBLR, Ivan T Varghis/HSSBLR@HSSBLR cc: Subject: ---------------------- Forwarded by Nagesh Kumar B V/HSSBLR on 06/01/2001 09:46 AM --------------------------- "Paul, Manoj" <mpaul(a)TRILLIUM.COM> on 05/31/2001 06:35:31 PM Please respond to "Paul, Manoj" <mpaul(a)TRILLIUM.COM> To: ITU-SG16(a)mailbag.cps.INTEL.COM cc: (bcc: Nagesh Kumar B V/HSSBLR) Subject: Hi All, I have a question on the use of H.235 Annex D (Baseline Security Profile). According to this profile, except for GRQ/GCF messages, all other RAS messages shall contain a hash value computed using HMAC-SHA1-96 algorightm on the entire RAS message. Consider an endpoint sending RRQ to the Gk. In the clearToken field of RRQ message, the endpoint shall fill generalId as gkId (which it got in GCF) and senderId as it's own epId. EpId is generally returned to the endpoint by the gatekeeper in RCF. That means that an endpoint may not have an epId while sending RRQ to Gk. In such a case, how it is supposed to fill the senderId and compute the hash value on complete RRQ message? Any pointers are appreciated. thanks Manoj 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

1 0

None
by ssilvy＠HSS.HNS.COM 01 Jun '01

01 Jun '01

Hi, In case of initial RRQ when EPID is not available the table D.10 in H235v2 says that sendersID would be NULL. So the hash would be calculated with sendersID as NULL when the identification information i.e EPID is not available as in initial RRQ. Silvy. Nagesh Kumar B V 06/01/2001 10:40 AM To: Silvy Samuel/HSSBLR@HSSBLR, Ivan T Varghis/HSSBLR@HSSBLR cc: Subject: ---------------------- Forwarded by Nagesh Kumar B V/HSSBLR on 06/01/2001 09:46 AM --------------------------- "Paul, Manoj" <mpaul(a)TRILLIUM.COM> on 05/31/2001 06:35:31 PM Please respond to "Paul, Manoj" <mpaul(a)TRILLIUM.COM> To: ITU-SG16(a)mailbag.cps.INTEL.COM cc: (bcc: Nagesh Kumar B V/HSSBLR) Subject: Hi All, I have a question on the use of H.235 Annex D (Baseline Security Profile). According to this profile, except for GRQ/GCF messages, all other RAS messages shall contain a hash value computed using HMAC-SHA1-96 algorightm on the entire RAS message. Consider an endpoint sending RRQ to the Gk. In the clearToken field of RRQ message, the endpoint shall fill generalId as gkId (which it got in GCF) and senderId as it's own epId. EpId is generally returned to the endpoint by the gatekeeper in RCF. That means that an endpoint may not have an epId while sending RRQ to Gk. In such a case, how it is supposed to fill the senderId and compute the hash value on complete RRQ message? Any pointers are appreciated. thanks Manoj 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

1 0

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, Baker: It appears that a good amount discussion can be started to answer your questions (what has being discussed for the last couple of years in the ITU-T and TIPHON in particular). I am not trying to do so. Let me answer your questions summarizing the key points as follows: 1. Broadly, all applications can be considered in two categories: a. Real-time (e.g., audio, video [of H.323/SIP]) and b. Non-Real-time (e.g., data applications like file transfer, WWW, Mail, etc. - can a part of H.323/SIP). The performance parameters of both real-time (audio, video) and non-real-time (data) traffic can be abstracted in an universal way that can be used by all applications (e.g., H.323, SIP, WWW, mail, etc). However, the signaling messages used by each application are application-specific although the QOS parameters used by all of them still remain same (e.g., H.323 might use RAS/Q.931/Annex-G/H.245 signaling messages, SIP might use SDP). The QOS signaling messages that use QOS parameters can be termed as the application layer QOS signaling messages and are sent on end-to-end basis and the values of those QOS parameters do not change no matter what may be the underlying transport networks (e.g., IP, ATM). 2. The network layer QOS signaling messages carried over the network may not be end-to-end significance. For example, an end-to-end path of an IP network may consist of RSVP, DiffServ, MPLS, and RSVP. So, the network layer QOS parameters may get translated between the source-destination path and may not remain the same what has been negotiated on end-to-end basis in the application layer (item 1). The problems that are being addressed are as follows: A. How to develop the end-to-end QOS signaling mechanisms in the application layer B. How to relate the application layer QOS signaling to the network layer QOS signaling (e.g., RSVP, DifServ, MPLS, etc.) so that one-to-one consistency remain between the application and network layer QOS parameters. Hope this may clarify some of your questions. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Fred Baker [mailto:fred@cisco.com] Sent: Thursday, May 31, 2001 1:09 PM To: Roy, Radhika R, ALCTA Cc: Bob Braden; gratta(a)lucent.com; sob(a)harvard.edu; mankin(a)isi.edu; 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 At 06:08 AM 5/31/2001, Roy, Radhika R, ALCTA wrote: >All applications (e.g., H.323, SIP) uses signaling messages >among its functional entities (e.g., terminal, agents, >gatekeepers, proxies, gateways) for communications. I'm not sure we're on the same planet. Please help me out here. I can think of a few applications that have agents, gatekeepers, proxies, and gateways, mostly resulting from the imposition of firewalls or authentication systems, or from legacy applications like imitating the telephone system in a data network. The only one that *requires* any kind of gateway, to my knowledge, is H.323 teleconferencing, which represents a paltry fraction of traffic according to most current measurements. Anything else (75% of Internet traffic is http or FTP, most of the rest is mail, on private LANs applications like NFS are pretty common, and even SIP can be done without a gateway between consenting systems) could be hooked up in separate systems on a LAN and made to work without any such signalling at all. Could you be more specific on what QoS signalling is required by the world wide web, mail, FTP, common ERP applications like ERP and PeopleSoft, calendaring, and so on? If not, could you be more specific about what "all" applications you have in mind? And could you be more specific about what issues this proposal is addressing that have not already been addressed in de facto standards and deployed in operational systems? It would be very nice to understand what you are preparing to ask vendors to do, and whether operators are interested in deploying them. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

[Tsvwg] RE: [Sipping] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL M ECHANISM FOR E ND-TO-END QOS SERVICE CONTROL
by Rosen, Brian 31 May '01

31 May '01

Folks, this thread may or may not be the start of something good or evil, but it is going out to too many lists! Please, as of now, let's move it to one, and only one list. I nominate tsvwg. If you are replying to any message on this thread, PLEASE edit the to/cc to limit it to tsvwg(a)ietf.org Brian > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Thursday, May 31, 2001 1:09 PM > To: Roy, Radhika R, ALCTA > Cc: Bob Braden; gratta(a)lucent.com; sob(a)harvard.edu; mankin(a)isi.edu; > 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: [Sipping] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL > MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL > > > At 06:08 AM 5/31/2001, Roy, Radhika R, ALCTA wrote: > >All applications (e.g., H.323, SIP) uses signaling messages > >among its functional entities (e.g., terminal, agents, > >gatekeepers, proxies, gateways) for communications. > > I'm not sure we're on the same planet. Please help me out here. > > I can think of a few applications that have agents, > gatekeepers, proxies, > and gateways, mostly resulting from the imposition of firewalls or > authentication systems, or from legacy applications like > imitating the > telephone system in a data network. The only one that > *requires* any kind > of gateway, to my knowledge, is H.323 teleconferencing, which > represents a > paltry fraction of traffic according to most current > measurements. Anything > else (75% of Internet traffic is http or FTP, most of the > rest is mail, on > private LANs applications like NFS are pretty common, and > even SIP can be > done without a gateway between consenting systems) could be > hooked up in > separate systems on a LAN and made to work without any such > signalling at all. > > Could you be more specific on what QoS signalling is required > by the world > wide web, mail, FTP, common ERP applications like ERP and PeopleSoft, > calendaring, and so on? If not, could you be more specific > about what "all" > applications you have in mind? > > And could you be more specific about what issues this proposal is > addressing that have not already been addressed in de facto > standards and > deployed in operational systems? It would be very nice to > understand what > you are preparing to ask vendors to do, and whether operators are > interested in deploying them. > > > > _______________________________________________ > Sipping mailing list > Sipping(a)ietf.org > http://www.ietf.org/mailman/listinfo/sipping > _______________________________________________ tsvwg mailing list tsvwg(a)ietf.org http://www1.ietf.org/mailman/listinfo/tsvwg

1 0

None
by Paul, Manoj 31 May '01

31 May '01

Hi All, I have a question on the use of H.235 Annex D (Baseline Security Profile). According to this profile, except for GRQ/GCF messages, all other RAS messages shall contain a hash value computed using HMAC-SHA1-96 algorightm on the entire RAS message. Consider an endpoint sending RRQ to the Gk. In the clearToken field of RRQ message, the endpoint shall fill generalId as gkId (which it got in GCF) and senderId as it's own epId. EpId is generally returned to the endpoint by the gatekeeper in RCF. That means that an endpoint may not have an epId while sending RRQ to Gk. In such a case, how it is supposed to fill the senderId and compute the hash value on complete RRQ message? Any pointers are appreciated. thanks Manoj Paul. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 31 May '01

31 May '01

Hi Frank, You are right. Annex L does not use the supportedH248Packages to specify the H.248 package support. As you mentioned, it is meant to be associated with H.248 signals in serviceControlSession which Gk may use to feed tones to the endpoint. regards Manoj. -----Original Message----- From: frank.derks(a)philips.com [mailto:frank.derks@philips.com] Sent: Wednesday, May 30, 2001 11:38 PM To: mpaul(a)trillium.com Cc: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: Why use two different "H.248 mechanisms" in H.323? 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: H.323 Annex D v2
by Francois Audet 31 May '01

31 May '01

It is in ITU-T H.323v4 (2000): http://www.itu.int/itudoc/itu-t/approved/h/h323.html > -----Original Message----- > From: Hans Viens [mailto:hviens@MEDIATRIX.COM] > Sent: Thursday, May 31, 2001 8:04 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.323 Annex D v2 > > > Hi Folks! > Does anyone could tell me where I could found H.323 Annex D > v2 (with H.323 > v4) ? > Thanks, > Hans > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com >

1 0

Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL
by Fred Baker 31 May '01

31 May '01

At 06:08 AM 5/31/2001, Roy, Radhika R, ALCTA wrote: >All applications (e.g., H.323, SIP) uses signaling messages >among its functional entities (e.g., terminal, agents, >gatekeepers, proxies, gateways) for communications. I'm not sure we're on the same planet. Please help me out here. I can think of a few applications that have agents, gatekeepers, proxies, and gateways, mostly resulting from the imposition of firewalls or authentication systems, or from legacy applications like imitating the telephone system in a data network. The only one that *requires* any kind of gateway, to my knowledge, is H.323 teleconferencing, which represents a paltry fraction of traffic according to most current measurements. Anything else (75% of Internet traffic is http or FTP, most of the rest is mail, on private LANs applications like NFS are pretty common, and even SIP can be done without a gateway between consenting systems) could be hooked up in separate systems on a LAN and made to work without any such signalling at all. Could you be more specific on what QoS signalling is required by the world wide web, mail, FTP, common ERP applications like ERP and PeopleSoft, calendaring, and so on? If not, could you be more specific about what "all" applications you have in mind? And could you be more specific about what issues this proposal is addressing that have not already been addressed in de facto standards and deployed in operational systems? It would be very nice to understand what you are preparing to ask vendors to do, and whether operators are interested in deploying them. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H.323 Annex D v2
by Hans Viens 31 May '01

31 May '01

Hi Folks! Does anyone could tell me where I could found H.323 Annex D v2 (with H.323 v4) ? Thanks, Hans ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

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

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

Re: Annex Gv2
by Reddy, Paul K 22 May '01

22 May '01

Paul, With respect to two questions mentioned below on interaction between GK and BE, I agree with you that they are not addressed adequately at this time. Which are needed to be addressed in Q.5/16 (Mobility for Multimedia Systems and services) for H.MMS.1, H.MMS.2, H.MMS.3 recommendations. I welcome the relevant experts input and contributions on this topic to SG16 meeting at Porte Seguro,Brazil. regards, Paul Rapporteur for Q.5/16 -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Monday, May 21, 2001 9:14 PM To: Reddy, Paul K; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: 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

1 0

Some additional information regarding Brazil II
by Simao Campos-Neto 22 May '01

22 May '01

Dear colleagues, as promised, I am providing you with some details regarding the ground transportation in Porto Seguro. The company responsible for the event has contracted with a local company, "Pool Turismo", to provide a van service from the airport to the docks on the arrival day, and back to the airport in the departure day. This service will cost you R$20.00 (as stated in the Collective Letter 1/16). (NOTE: Additionally, there is a ferry that will transport you from the docks to the hotel and vice versa, which is free-of-cost to people staying in the Paradise Resort Hotel. To commute between the hotel and Porto Seguro proper, you will be using this ferry.) Back to the airport/docks/airport transportation: Pool Turismo is requesting that everyone interested in the service to provide them with some information: 1-Hotel Name: 2-Participant Names: 3-Number of People: 4-Arrival From: Arraival Day-In: Time to Arrival: Flight number: Airline Name: 5-Departure To: Departure Day-Out: Time to Departure: Flight number: Airline Name: This data should be filled in and emailed to itu-tsg16(a)uol.com.br <mailto:itu-tsg16@uol.com.br>. Additional information provided by the company: "- General Condition for the transfer service: E-mail with your confirmation. - Our representative will meet you in the airport. - The transfer charge for people is R$ 20,00 IN/OUT inclusive. - The fee should be paid on arrival at the airport to our representative from Pool Eventos. - Should you change your flight please inform us. - Use the official company to request your service We're here to help you. - If you woud like some optional touristic trips or rent a car, please inform us. - If you have any further enquires please contact us at e-mail. - Contact People in Pool Eventos: Maria Calabrese, Lucio Panerai." Best regards, Simão -- =========================================================================== Simão Ferraz de Campos Neto, Scientist *All comments are strictly my own* LMGT/COMSAT Laboratories Tel: +1-301-428-4516 22300 Comsat Drive Fax: +1-301-428-9287 Clarksburg MD 20871 - USA E-mail: simao.campos(a)labs.comsat.com =========================================================================== ******** Practice random kindness and senseless acts of beauty ******** ===========================================================================

2 2

AW: Annex Gv2
by Horvath Ernst 22 May '01

22 May '01

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

2 1

Backward compatability H245Tunneling V4 with V3,2,..
by danlee＠YNNMAIL.COM 22 May '01

22 May '01

According to ver.4 "If the called entity does not yet know if H.245 tunneling can be supported, it shall include the provisionalRespToH245Tunneling flag. This may happen, for example, when a Gatekeeper is responding to a calling entity with a message such as Call Proceeding before the called endpoint responds to the h245Tunneling flag. " The problem arises when the calling entity does not support this flag (i.e., does not yet support ver.4). E.g., 1. Calling entity (let's say ver.3 EP) is sending Setup with indication of the tunneling support. 2. The gatekeeper answers with Call Proceeding including h245Tunneling ==False and provisionalRespToH245Tunneling ==True. 3. The calling entity (that was implemented BEFORE ver.4) will understand this as "tunneling is not supported". 4. But the called entity can send tunneled messages. What we've decided is: 1. To check the supported version of the calling EP. 2. If the version is >=4 than above scenario may be used. 3. Otherwise Call Proceeding will be delayed until getting the information from the called EP. ______________________________________________________________________ Join YnnMail at http://www.ynnmail.com and get your free secure e-mail and 40,000+ newsgroup... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1