- 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