- sg16-avd - lists.packetizer.com

CSRC Usage
by Leano, Bob 11 Jun '01

11 Jun '01

Hello: I need some clarification on the use of the CSRC field with respect to audio conferencing by the MC/MCU. Is it optional or mandatory? the only entry in any spec that I saw was in h.225.0 where it talked about csrc count, not csrc list. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Porto Seguro output documents
by OKUBO Sakae 10 Jun '01

10 Jun '01

Dear Rapporteurs and Editors, Could you please upload to /incoming or send to me draft Recommendations you produced in Porto Seguro? Since the PictureTel site is unofficial and set up for experts activities, I cannot simply copy ITU's TDs to there. 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

WP2 reports of the SG16 Porto Seguro meeting
by OKUBO Sakae 10 Jun '01

10 Jun '01

Dear SG16 experts, I have placed the WP2 reports of Mr. Tosco, Chairman of WP2, at the following place: http://standard.pictel.com/ftp/avc-site/0105_Por/WP2_Report_010608.zip It comprises the following six documents: Report Docs 6.01.doc -- Index Report Part I 6.01.doc -- Report Part I - General Report Part II 6.01.doc -- Report Part II - Recommendations to AAP and texts for approval Liaison Stat 6.01.doc -- Liaison Statements Meetings Rep 6.01.doc -- Planned Rapporteur Meetings Status Report 6.01.doc -- Status Report for Recommendations of WP2/16 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

Re: Selecting Codecs with dynamic RTP Payload Type
by Tom-PT Taylor 10 Jun '01

10 Jun '01

I assume you're talking about Megaco/H.248 with binary encoding. This is an interesting issue -- you may have to an object identifier after the fashion of H.245, or we'll have to extend the range of acodec. I'm passing this one on to the SG 16 list for comment. -----Original Message----- From: Nierhaus, Florian [mailto:Florian.Nierhaus@icn.siemens.com] Sent: Friday, June 08, 2001 9:49 PM To: 'megaco(a)fore.com' Subject: Selecting Codecs with dynamic RTP Payload Type Hi, I want to add a Termination and select GSM EFR as codec. Can someone tell me what is the correct way to do this? The Payload Type for GSM EFR is dynamic. ACodec seems to only support ITU codecs. Thanks, Florian Nierhaus

1 0

Information on H235V2 End Points
by Babu Varghese 08 Jun '01

08 Jun '01

Hi, I would like to know if there are any H.323 End Points (H235 V2 Complaint - Commerical/ Evaluation copy) available. H235V2 discuss that GateKeeper can make use of Back End Server (BES) support (using Radius) to authenticate messages. It would be very useful (For interoperabilty) if there are end-point available that support BES security profile. If any end-point support BES, it should handle the Radius "challenge" by sending "Challenge Response", which is part of "ClearToken". Some Information on the availabilty endpoints that support Supplementary Services such as Call Transfer, Call Hold and Call Waiting also will be definitely useful. Thanks, Babu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Using a MAC address as the Alias
by Frank Derks 08 Jun '01

08 Jun '01

Francois, obviously that can be done. But there is no way of explicitely knowing that h323-ID contains a MAC address. This can only be inferred. Frank audet@NORTELNETWORKS.COM@SMTP@MAILBAG.INTEL.COM on 07-06-2001 18:21:36 Please respond to audet@NORTELNETWORKS.COM@SMTP Sent by: ITU-SG16(a)MAILBAG.INTEL.COM To: ITU-SG16@MAILBAG.INTEL.COM@SMTP cc: Subject: Re: Using a MAC address as the Alias Classification: Of course, there is nothing that prevents you from putting the mac address as a character string in the h323-ID. And it would work with existing versions of H.323 (and other vendors). I don't see much benefits in adding yet another field. > -----Original Message----- > From: Paul E. Jones [SMTP:paulej@PACKETIZER.COM] > Sent: Thursday, June 07, 2001 08:21 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Using a MAC address as the Alias > > Frank, > > At first glance, it seems odd that one would want to report that to the > GK. > Certainly, it doesn't seem useful to report that though LRQ or other > address > resolution mechanisms. However, there are cases where it might be nice if > the GK knew the MAC address-- especially since V4 now allows multiple > endpoints to have the same alias. There are obvious benefits to having a > unique alias in the list. > > Paul > > ----- Original Message ----- > From: <frank.derks(a)philips.com> > To: <paulej(a)PACKETIZER.COM> > Cc: <ITU-SG16(a)mailbag.cps.INTEL.COM> > Sent: Thursday, June 07, 2001 3:00 AM > Subject: Re: Using a MAC address as the Alias > > > > Paul, > > > > it's good to know that I am not the only person that considers the use > of > a > > MAC address as an "alias" as being useful. It therefore strikes me as > being > > somewhat odd that this is not included in the massive amount of options > that > > H.323 already has. Any ideas why this was never included? > > > > Frank > > > > > > > > > > > > paulej@PACKETIZER.COM@SMTP@MAILBAG.INTEL.COM on 07-06-2001 05:45:35 > > Please respond to paulej@PACKETIZER.COM@SMTP > > Sent by: ITU-SG16(a)MAILBAG.INTEL.COM > > To: ITU-SG16@MAILBAG.INTEL.COM@SMTP > > cc: > > Subject: Re: Using a MAC address as the Alias > > Classification: > > > > > > Frank, > > > > Yes, I have, and there are very valid cases for doing this. > > > > Paul > > > > ----- Original Message ----- > > From: "Frank Derks" <frank.derks(a)PHILIPS.COM> > > To: <ITU-SG16(a)mailbag.cps.INTEL.COM> > > Sent: Tuesday, June 05, 2001 10:05 AM > > Subject: Using a MAC address as the Alias > > > > > > > Today, there are many possibilities for a H.323 User/Terminal to > register > > with a GK. Many of these > > > Aliases are an alias for the user. When the MobileUIM structure is > used, > > it is also possible to specify > > > an equipment identifier. Has anybody ever given any thought to the > > possibility of specifying the MAC > > > address of Terminal as an Alias? > > > > > > 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 > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com

2 1

Re: Using a MAC address as the Alias
by frank.derks＠philips.com 07 Jun '01

07 Jun '01

Paul, it's good to know that I am not the only person that considers the use of a MAC address as an "alias" as being useful. It therefore strikes me as being somewhat odd that this is not included in the massive amount of options that H.323 already has. Any ideas why this was never included? Frank paulej@PACKETIZER.COM@SMTP@MAILBAG.INTEL.COM on 07-06-2001 05:45:35 Please respond to paulej@PACKETIZER.COM@SMTP Sent by: ITU-SG16(a)MAILBAG.INTEL.COM To: ITU-SG16@MAILBAG.INTEL.COM@SMTP cc: Subject: Re: Using a MAC address as the Alias Classification: Frank, Yes, I have, and there are very valid cases for doing this. Paul ----- Original Message ----- From: "Frank Derks" <frank.derks(a)PHILIPS.COM> To: <ITU-SG16(a)mailbag.cps.INTEL.COM> Sent: Tuesday, June 05, 2001 10:05 AM Subject: Using a MAC address as the Alias > Today, there are many possibilities for a H.323 User/Terminal to register with a GK. Many of these > Aliases are an alias for the user. When the MobileUIM structure is used, it is also possible to specify > an equipment identifier. Has anybody ever given any thought to the possibility of specifying the MAC > address of Terminal as an Alias? > > 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

4 5

Re: Using a MAC address as the Alias
by Francois Audet 07 Jun '01

07 Jun '01

Of course, there is nothing that prevents you from putting the mac address as a character string in the h323-ID. And it would work with existing versions of H.323 (and other vendors). I don't see much benefits in adding yet another field. > -----Original Message----- > From: Paul E. Jones [SMTP:paulej@PACKETIZER.COM] > Sent: Thursday, June 07, 2001 08:21 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Using a MAC address as the Alias > > Frank, > > At first glance, it seems odd that one would want to report that to the > GK. > Certainly, it doesn't seem useful to report that though LRQ or other > address > resolution mechanisms. However, there are cases where it might be nice if > the GK knew the MAC address-- especially since V4 now allows multiple > endpoints to have the same alias. There are obvious benefits to having a > unique alias in the list. > > Paul > > ----- Original Message ----- > From: <frank.derks(a)philips.com> > To: <paulej(a)PACKETIZER.COM> > Cc: <ITU-SG16(a)mailbag.cps.INTEL.COM> > Sent: Thursday, June 07, 2001 3:00 AM > Subject: Re: Using a MAC address as the Alias > > > > Paul, > > > > it's good to know that I am not the only person that considers the use > of > a > > MAC address as an "alias" as being useful. It therefore strikes me as > being > > somewhat odd that this is not included in the massive amount of options > that > > H.323 already has. Any ideas why this was never included? > > > > Frank > > > > > > > > > > > > paulej@PACKETIZER.COM@SMTP@MAILBAG.INTEL.COM on 07-06-2001 05:45:35 > > Please respond to paulej@PACKETIZER.COM@SMTP > > Sent by: ITU-SG16(a)MAILBAG.INTEL.COM > > To: ITU-SG16@MAILBAG.INTEL.COM@SMTP > > cc: > > Subject: Re: Using a MAC address as the Alias > > Classification: > > > > > > Frank, > > > > Yes, I have, and there are very valid cases for doing this. > > > > Paul > > > > ----- Original Message ----- > > From: "Frank Derks" <frank.derks(a)PHILIPS.COM> > > To: <ITU-SG16(a)mailbag.cps.INTEL.COM> > > Sent: Tuesday, June 05, 2001 10:05 AM > > Subject: Using a MAC address as the Alias > > > > > > > Today, there are many possibilities for a H.323 User/Terminal to > register > > with a GK. Many of these > > > Aliases are an alias for the user. When the MobileUIM structure is > used, > > it is also possible to specify > > > an equipment identifier. Has anybody ever given any thought to the > > possibility of specifying the MAC > > > address of Terminal as an Alias? > > > > > > 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 > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com

2 1

Re: Using a MAC address as the Alias
by Frank Derks 07 Jun '01

07 Jun '01

Pete, one of the uses of a MAC address could be a "standardised" way to identify a piece of equipment in a simple way. Obviously there is a vendorIdentifier element for this purpose, but its contents are rather "non-standard" (OCTET STRING), which makes it a bit harder to determine the piece of equipment. Furthermore, I would expect the vendorIdentifier field to be identical for every product of the same type, so the only thing a could infer from this element is the type of the product and not the specific piece of equipment. Why would I want to know the MAC address? Since the MAC address is tightly coupled to a piece of equipment, I could use this information to do something equipment specific. This can also be achieved through the vendorIdentifier element, but this would mean that any piece of equipment of this type would qualify and not a specific piece of equipment. If I want to do something based on the physical location of the equipment, then the vendorIdentifier is no great help. If I keep some administration about the location of equipment and their MAC addresses,then I could e.g. pinpoint the location from which a call was placed. Since Aliases usually represent users, they are rather loosely coopled to a specific piece of equipment. Frank pete(a)tech-know-ware.com on 07-06-2001 15:09:23 To: ITU-SG16@mailbag.cps.INTEL.COM@SMTP Frank Derks/HVS/BE/PHILIPS@EMEA2 cc: Subject: Re: Using a MAC address as the Alias Classification: I think the main reason is simply that no one has so far made a case for them! (I can't see the value myself, but then no one has explained it to me! I'm prepared to be enlightened.) What I would say is that, if you do want to add it as a new alias type, then I would suggest that it be added as a URL. Something like: .mac:blah-blah-blah (where l=0 and h=5 !!!) I've preceded it with a dot to indicate that it is a 323 defined URL and so avoid any conflicts with officially defined URLs. Any new aliases should probably also include what steps should be taken to enable backwards compatible operation with entities that do not understand the alias. Pete. ============================================= Pete Cordell Tech-Know-Ware pete(a)tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: Frank Derks <frank.derks(a)PHILIPS.COM> To: <ITU-SG16(a)mailbag.cps.INTEL.COM> Sent: 07 June 2001 08:00 Subject: Re: Using a MAC address as the Alias > Paul, > > it's good to know that I am not the only person that considers the use of a > MAC address as an "alias" as being useful. It therefore strikes me as being > somewhat odd that this is not included in the massive amount of options that > H.323 already has. Any ideas why this was never included? > > Frank > > > > > > paulej@PACKETIZER.COM@SMTP@MAILBAG.INTEL.COM on 07-06-2001 05:45:35 > Please respond to paulej@PACKETIZER.COM@SMTP > Sent by: ITU-SG16(a)MAILBAG.INTEL.COM > To: ITU-SG16@MAILBAG.INTEL.COM@SMTP > cc: > Subject: Re: Using a MAC address as the Alias > Classification: > > > Frank, > > Yes, I have, and there are very valid cases for doing this. > > Paul > > ----- Original Message ----- > From: "Frank Derks" <frank.derks(a)PHILIPS.COM> > To: <ITU-SG16(a)mailbag.cps.INTEL.COM> > Sent: Tuesday, June 05, 2001 10:05 AM > Subject: Using a MAC address as the Alias > > > > Today, there are many possibilities for a H.323 User/Terminal to register > with a GK. Many of these > > Aliases are an alias for the user. When the MobileUIM structure is used, > it is also possible to specify > > an equipment identifier. Has anybody ever given any thought to the > possibility of specifying the MAC > > address of Terminal as an Alias? > > > > 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 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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

terminalAlias and terminalAliasPattern in RCF
by Frank Derks 07 Jun '01

07 Jun '01

The RCF message may include the terminalAlias and terminalAliasPattern elements. According to the description of the terminalAlias element, it is used to: 1. Inform the terminal about alias addresses by which other terminals may identify the terminal 2. To assign an alias (or multiple aliases) to a terminal when it does not specify an alias in the RRQ According to the description of the terminalAliasPattern element, it is used to: 1. Inform the terminal about the alias(es), from the list of aliases in the RRQ, that are accepted 2. To assign an alias (or multiple aliases) to a terminal when it does not specify an alias in the RRQ It is not clear whether the contents of terminalAlias "override" the alias(es) in the RRQ. I.e. should (or shall) the terminal only use an alias(es) from the list returned in the RCF and forget about the alias(es) that it used in the RRQ? Or is this information provided so the terminal will accept incoming calls destined for these returned aliases? For terminalAliasPattern, this seems to be somewhat clearer, as the description says something about "acceptable aliases from the RRQ". Still, the text doesn't go at great lengths to explain what acceptable means. Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: [imtch323implementors] H32x-Series and ASN1 TO JAVA
by Elangovan Angannan 07 Jun '01

07 Jun '01

Dear Michael, OpenH323 project provides encoding/decoding library. With a minimum effort you can access it from JAVA through JNI. Regards Elango > > Right now I am searching for tools in order to get > the standards > specified in ASN1 into Java. Does anyone have some > recommendations > or hints how to do the encoding and decoding of the > messages in > order to get them across the wire. > > There are a lot of commercial tools available, but > isn't there > a open source or free implemenation/source code of a > compiler 4 java. > > > thank you very much for your effort, > > michael > > > --- > You are currently subscribed to imtch323implementors > as: h323elango(a)yahoo.com > To unsubscribe send a blank email to leave-imtch323implementors-46711Q(a)mail.imtc.org ===== Amoeba Telecom India http://www.amoebatel.com __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H32x-Series and ASN1 TO JAVA
by Michael "Samson" Stini 07 Jun '01

07 Jun '01

Hi, my name is Michael Stini and I decided to do my diploma thesis on the H323-standard. So I hope I am not bugging you with boring questions. Right now I am searching for tools in order to get the standards specified in ASN1 into Java. Does anyone have some recommendations or hints how to do the encoding and decoding of the messages in order to get them across the wire. There are a lot of commercial tools available, but isn't there a open source or free implemenation/source code of a compiler 4 java. thank you very much for your effort, michael ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Using a MAC address as the Alias
by Frank Derks 06 Jun '01

06 Jun '01

Today, there are many possibilities for a H.323 User/Terminal to register with a GK. Many of these Aliases are an alias for the user. When the MobileUIM structure is used, it is also possible to specify an equipment identifier. Has anybody ever given any thought to the possibility of specifying the MAC address of Terminal as an Alias? Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Keep the Change # A2B
by Greg T. Moores 05 Jun '01

05 Jun '01

***** This is an HTML Message ! *****

1 0

Regarding use of gateway control commands in H.341.
by Rohit T. 05 Jun '01

05 Jun '01

Hi All, I am a new entrant to this mailing list and appreciate the time and effort you spend on it. I am in a slight quandary. I am writing an agent for a network element that is an H323 gatekeeper. For this I am using the Gatekeeper MIB as given in Annex1.4 of ITU-T H.341 Recommendation "Multimedia Management Information Base". This MIB defines the h323GatekeeperControlCommands as "A value that represents a command for the gateway.For the list of possible command refer to MmControlCommands" At another place in the same MIB for h323GatekeeperStatisticsTotalErrors it reads "Total number of GK errors that have occured in the the gateway since last startup" My concern is - How can a gatekeeper issue a commanad for the gateway which is a separate entity in the network?? And how does Gk maintains error count that have occured in the gateway?? Is it a typo error and gateway here actually refers to gatekeeper?? Please clarify regarding the same. Any and all comments will be appreciated. Best Regards, --Rohit. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 05 Jun '01

05 Jun '01

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. 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. BICC and MEGCAO/H.248 are only used as the protocol between the gateways, NOT end-to-end (although SIP/H.323 or other protocols may be used between the gateways). The "End-to-End QOS for Multimedia Applications" of SG16 can also be termed as "Application Layer QOS." Q.F/16's end-to-end application layer QOS can also be implemented over the network layer QOS like RSVP, DiffServe, and/or MPLS after proper mapping. Similar is the case for the ATM network. 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. Let us work together. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Greg Ratta [mailto:gratta@lucent.com] Sent: Wednesday, May 30, 2001 4:22 PM To: 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; rbuhrke(a)lucent.com; tsg11q8(a)ties.itu.ch; tsg11q9(a)ties.itu.ch Subject: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL This message was agreed to at ITU-T Study Group 11 meeting (Geneva, May 2001) and is being transmitted on behalf of Yukio Hiramatsu, Chairman of ITU-T SG 11. For further technical clarification, contact the Rapporteur for Q9/11 (Rolfe Buhrke, Tel: + 1 630 713 7022, { HYPERLINK mailto:rburke@lucent.com }rbuhrke(a)lucent.com) FULL TITLE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL AND SIGNALLING PROTOCOL DEVELOPMENT BASED ON IP TRANSFER CAPABILITIES AND IP QOS CLASSES General Within ITU-T SG11 work has started on requirements for a generic protocol mechanism for end-to-end QoS service control. It was agreed within SG11 to proceed with this work utilising deliverables of ETSI TIPHON on end- to-end QoS service control as base material. It is the opinion of SG11 that this generic protocol mechanism for BICC intends to apply also to other protocols like SIP/SDP and H.323 next to generic extensions to the H.248/MEGACO protocol. It was noted that also QoS related work is in progress in IETF. Please find attached an initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. Please note the rationale for this activity and the framework for end-to-end QoS service control and network QoS control. The framework illustrates the field of application of the QoS handling at different levels and the different protocols involved. Proposals on end-to-end QoS service control It is proposed to start a joint activity with IETF on a generic protocol mechanism for end- to-end QoS service control. This refers to the potential work in IETF on the following topics: - Identification of the signalling requirements based on the ETSI TIPHON defined speech QoS service classes for VoIP and the signalling and control of end-to-end QoS for VoIP. The attachment provides the initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. - The definition of a generic call/bearer control mechanism in H.225/H.245, SIP/SDP and BICC CS3 for end-to-end QoS service control in the application plane. - The definition of generic extensions to H.248/MEGACO for end-to-end QoS service control between the application plane and the transport plane. - The translation between the generic protocol QoS information elements in H.248/MEGACO and the technology specific QoS parameters and QoS mechanisms in IP, ATM, MPLS, etc. Proposals on IP QoS classes and IP Transfer Capabilities ITU-T SG11 would like to inform IETF that it is investigating signalling requirements for protocol development based on the IP Transfer Capabilities and IP QoS classes, as being defined by ITU-T SG13 in Y.1541 and Y.iptc. The plan is to build upon signalling approaches developed by IETF. We would like to stress that the work on IP QoS classes and IP Transfer Capabilities by ITU-T SG13 is co- ordinated with IETF. ATTACHMENT Initial draft text of the BICC CS3 signalling requirements for end-to-end QoS service control. The ETSI specifications referenced as base material are available at the following URLs: ETSI TS 301 329 part 2, http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05009/V1.1.1/ts_10 1329-2v111p.doc - ETSI TS 301 329 part 3 see http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05003/DTS05003v096.zi p Further information about the ETSI TIPHON project is available at the following URL: - http://webapp.etsi.org/tbhomepage/TBDetails.as p?TB_ID=291&TB_NAME=TIPHON __________________ BICC CS3 signalling requirements for end-to- end QoS service control EDITORS' NOTE: This requirements text for end-to-end QoS service control is a first draft text and requires extensive updating based on liaison activities with other groups 1 Rationale The rationale of the BICC CS3 requirements for end-to-end service control is based on the analysis made by ETSI TIPHON (see the presentation available at the URL: http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/ARCHIVES/2000/05- 200012- Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt ). It shows the inter-relationship between the different QoS factors that finally determine the perceived speech quality by the end- users. This perceived speech quality does not only depend on network quality of service (network packet loss, network jitter and network delay) but on the terminal implementation (jitter buffers and codec performance) as well. A second rationale is that end-to-end QoS requirements can be regarded as end-to-end quality budgets related to the media flows. To achieve the required end-to-end QoS these quality budgets must be allocated between the domains, including the user equipment (see Figure 7 in ETSI TS 301 329 part 3). The Transport QoS Parameters specify the QoS budgets for each Transport Domain. It is assumed that the performance of each domain is statistically independent from any other. Therefore end-to-end QoS service control at the call control level (i.e. application plane) is required based on generic signalling procedures in protocols like BICC, SIP/SDP, H.323 and H.248/MEGACO for end-to- end QoS service control. 2 Framework for end-to-end QoS service control and network QoS control. A framework for QoS control may be considered at different levels: call control (BICC, SIP/SDP, H.323), vertical control (H.248/MEGACO, CBC), bearer control (IP BCP) and bearer (DiffServ, IntServ/RSVP or MPLS/LDP). 1) Call-control a) End-to-end QoS service control is negotiated/communicated end-to-end at the call control level. ETSI TIPHON has defined a set of speech QoS classes, and signalling requirements and flows for this purpose. The idea is that call control protocols are enhanced with a generic end-to-end QoS service control mechanism to negotiate these speech QoS classes and associated parameters (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size). Such a generic end-to-end QoS service control mechanism should be defined independent of the underlying technology (ATM or IP) and operate across network domains and including terminal characteristics to negotiate/communicate the requested listener speech quality that will be perceived by the end-users (i.e. "mouth-to-ear"). b) BICC (Q.190x) is one of the call control protocols that may be enhanced this way. Similar enhancements may be applicable to other call-control protocols like SIP/SDP and H.323. 2) Vertical control a) QoS service control is also negotiated/communicated at the vertical control level. The ETSI TIPHON defined signalling requirements and flows include the vertical interface. The idea is that vertical control protocols are enhanced to negotiate/communicate the QoS settings (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size) in the bearer core network based on generic H.248/MEGACO extensions. These QoS settings should be defined independent of the underlying technology (ATM or IP) of the bearer core network. b) CBC (Q.1950) is one of the vertical control protocols that may be enhanced this way. 3) Bearer control a) Network QoS is negotiated/communicated at the bearer control level. ATM signalling does already intrinsically support network QoS. SG13 has recently defined IP QoS classes and IP Transfer Capabilities. The idea is that bearer control protocols for IP are enhanced with a mechanism to negotiate the network QoS by using IP QoS classes and IP Transfer Capabilities. b) IP BCP (Q.1970) is an IP bearer control protocol that may be enhanced this way. 4) Bearer a) Network QoS is negotiated/communicated at the bearer level, i.e. as part of the protocols associated with the bearers in the core network. The idea is that IP QoS classes and IP Transfer Capabilties, as defined by SG13, are used to differentiate between different types of IP traffic. b) IP QoS classes and IP Transfer Capabilities may be used to enhance existing IP mechanisms like DiffServ, IntServ/RSVP and MPLS/LDP. 3 QoS information flows applicable to BICC A general model is considered for QoS information flows with BICC when making a translation of the relevant parts in Figure 8 in ETSI TS 301 329 part 3. Section 4 details the Q.BICC related QoS primitives and parameters based on the QoS primitives and parameters in the ETSI deliverable. Similarly, section 5 provides the Q.CBC related QoS primitives and parameters. 4 Q.BICC related QoS primitives and parameters The Q.BICC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. 4.1 Q.BICC related QoS primitives This information flow (QC2 in ETSI TS 101 329 part 3) communicates the QoS related bearer information between the domains of different service providers. Q.BICC QoS request (Qbicc.QoSreq) requests the establishment of a bearer conforming to a particular ETSI TIPHON Class of Service or with defined QoS characteristics. NOTE Identical to QoSM request (QC2.QoSMreq) in ETSI TS 101 329 part 3 clause 8.1.1. Q.BICC QoS confirm (Qbicc.QoSconf) acknowledges the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. NOTE Identical to QoSM confirm (QC2.QoSMconf) in ETSI TS 101 329 part 3 clause 8.1.1. Q.BICC QoS reject (Qbicc.QoSrej) rejects the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. NOTE Identical to QoSM reject (QC2.QoSMrej) in ETSI TS 101 329 part 3 clause 8.1.1. Q.BICC release request (Qbicc.QoSrelreq) requests the release of a bearer. NOTE Identical to QoSM release request (QC2.QoSMrelreq) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. QoSM release confirm (Qbicc.QoSrelconf) confirms the release of a bearer. NOTE Identical to QoSM release confirm (QC2.QoSMrelconf) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. 4.2 Q.BICC related QoS parameters Table 1 lists the parameters used in the Q.BICC related QoS primitives not yet covered by the Q.BICC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in the Q.1902 series. NOTE The contents of Table 1 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.3. Table 1: Identification of Q.BICC related parameters for end-to-end QoS service control Qbicc.QoSreq QoS Service Class Optional Codec Type and Packetisation Mandatory Transport QoS Parameters Mandatory Traffic Descriptor Optional Transport Addresses Mandatory Application Data Transport Protocol Optional [Default RTP] Packet Transport Protocol Optional [Default UDP] QoS Mechanism Optional Qbicc.QoSconf QoS Service Class Optional Codec Type and Packetisation Mandatory Transport QoS Parameters Mandatory Transport Addresses Mandatory Application Data Transport Protocol Optional [Default RTP] Packet Transport Protocol Optional [Default UDP] Qbicc.QoSrej Reason [TBD] Mandatory 5 Q.CBC related QoS primitives and parameters The Q.CBC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. 5.1 Q.CBC related QoS primitives This information flow (QT2 in ETSI TS 101 329 part 3) communicates the QoS related transport flow information between a service domain and an associated transport domain. This information contains the QoS related characteristics required of the transport flows that will carry the media flow and the properties of the media flow. Q.CBC QoS request (Qcbc.QoSreq) requests the establishment of a transport flow with defined QoS characteristics across a Transport Domain or the reservation of Transport Domain resource. NOTE Identical to TRM QoS request (QT2.TRMQreq) in ETSI TS 101 329 part 3 clause 8.1.3. Q.CBC QoS confirm (Qcbc.QoSconf) acknowledges the creation of a requested transport flow or the reservation of Transport Domain resource. NOTE Identical to TRM QoS confirm (QT2.TRMQconf) in ETSI TS 101 329 part 3 clause 8.1.3. Q.CBC QoS reject (Qcbc.QoSrej) rejects the creation of a requested transport flow or the reservation of Transport Domain resource. NOTE Identical to TRM QoS reject (QT2.TRMQrej) in ETSI TS 101 329 part 3 clause 8.1.3. Q.CBC QoS release request (Qcbc.QoSrelreq) requests the release of a transport flow. NOTE Identical to TRM QoS release request (QT2.TRM QoS relreq) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. Q.CBC QoS release confirm (Qcbc.QoSrelconf) confirms the release of a transport flow. NOTE Identical to TRM QoS release confirm (QT2.TRM QoS relconf) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. Q.CBC QoS performance notification (Qcbc.QoSperfnotif) notifies the Service Domain of the performance of the Transport Domain in meeting the requested QoS levels. This may be a periodic event or an urgent alarm. Note: this primitive is a management primitive and its use is for further study. NOTE Identical to TRM QoS performance notification (QT2.TRM QoS perfnotif) in ETSI TS 101 329 part 3 clause 8.1.3. For further study. 5.2 Q.CBC related QoS parameters Table 2 lists the parameters used in the Q.CBC related QoS primitives not yet covered by the Q.CBC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in Q.1950. NOTE The contents of Table 2 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.5. Table 2: Identification of Q.CBC related parameters for end-to-end QoS service control QT2.TRMQreq Transport QoS Parameters Mandatory Traffic Descriptor Mandatory Transport Addresses Mandatory Packet Transport Protocol Optional [Default UDP] QT2.TRMQconf Transport QoS Parameters Mandatory Transport Addresses Mandatory Packet Transport Protocol Optional [Default UDP] QoS Mechanism Optional QT2.TRMQrej Reason [TBD] Mandatory 6 Parameter contents Table 3 specifies the information to be covered by the parameters listed in sections 4.2 and 5.2 based on the QoS parameter groups in ETSI TS 101 329 part 3 clause 8.2.1. Table 3: Identification of parameter contents for end-to-end QoS service control QoS Service Class Describes the end-to-end ETSI TIPHON Best, High, Medium class of a beareror Best Effort Transport QoS Specifies the QoS characteristics Maximum Delay Parameters required of the transport flow carrying the media flow. Maximum Packet Delay Variation Maximum Packet Loss Traffic Descriptor Characterises the resource Peak Bit requirements of an application data flow (excludes transport flow Maximum Packet Size resource requirements). Parameters specifying the ETSI TIPHON QoS Class as defined in ETSI TS 101 329 Part 2 The maximum delay permitted (ms) over either a segment of the transport flow or the remaining part of the transport flow. The maximum packet delay variation permitted (ms) over either a segment of the transport flow or the remaining part of the transport flow. The maximum packet loss permitted (%) over either a segment of the transport flow or the remaining part of the transport flow. [N.B. This measure assumes randomly distributed packet loss] Maximum bit rate (bit/s) of the media flow. Maximum size of the media packets 7 Information flows and signalling procedures for end-to-end QoS service control EDITORS' NOTE The information flows and signalling procedures for end-to-end QoS service control may be considered to follow the same principles as the already existing procedures for end-to-end codec negotiation in BICC CS1 and BICC CS2. Similarly mid-call procedures for end-to-end QoS modification and mid-call QoS modification may be considered because the perceived QoS is highly related to the codec type employed end- to-end as part of the connection. The exact scope and properties of these procedures and protocol message flows needs further discussion. Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and protocols Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta(a)lucent.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL
by Bob Braden 02 Jun '01

02 Jun '01

*> 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

2 1

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

01 Jun '01

It is good that we have some help from the network layer by RSVP. Similarly, DiffServ and MPLS can do something similar to this. So, the application layer QOS just needs to find a way how to relate an end-to-end call to the lower layer QOS signaling when a call path traverses via RVSP-DifServ-MPLS-RSVP domain keeping the consistency between the upper and lower layer. -----Original Message----- From: Francois Audet [mailto:audet@NORTELNETWORKS.COM] Sent: Friday, June 01, 2001 12:56 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL 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. This seem to me to be exactly what RSVP does. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 Francois Audet 01 Jun '01

01 Jun '01

> 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. > This seem to me to be exactly what RSVP does.

1 0

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

01 Jun '01

Hi, Gary: Let me make it clear: No specific suggestions have been made to extend/exploit the existing messages/parameters. So, if a requirement is there that an emergency call need to be handled by the GK, we can do the following analysis of the requirements: 1. A call needs to be differentiated based on Emergency, High Priority, etc. 2. Allow a preemption of a low priority call by a high priority one if resources are not available. May be new signaling messages in H.323 are needed to meet the above requirements. If we take the above two, as an example, and if the signaling messages are there to signal those two appropriately, I believe, a GK will be able to take the proper decision. Please note that I have NOT used the word "policy" per se (a GK may create its own policy by de-fault [proprietary] based on those criteria). However, if we want to create a standard for "policy" for the inter-domain calls, for example between the carriers, we need to do more. We may consider a policy server is behind the GK (something like COPS of the IETF). Best regards, Radhika -----Original Message----- From: Gary Thom [mailto:gthom@delta-info.com] Sent: Friday, June 01, 2001 12:21 PM To: Roy, Radhika R, ALCTA; 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 My comment was that if the gatekeeper has an addmission pollicy that states that it only allows 20 calls or 2Mbps of bandwidth, and a high or emergancy priority call request is being made, the Gateway may stretch it policy to allow that call. I also agree that bandwidth requesta are already indicated in the ARQ, so maybe it is not appropriate to indicate them again in the qos signalling. -------------------------------------------- Name : Gary A. Thom Company: Delta Information Systems, Inc. Address: 300 Welsh Rd., Bldg 3 Horsham, PA 19044 USA Phone : +1-215-657-5270 x123 Fax : +1-215-657-5273 E-mail : gthom(a)delta-info.com Website: www.delta-info.com -------------------------------------------- -----Original Message----- From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com] Sent: Friday, June 01, 2001 12:15 PM To: gthom(a)delta-info.com; 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 Hi, Bob and Gary: There is already an optional requirement in H.323 that the GK does the admission control. For example, the bandwidth parameters are there where the GK decides whether the request can be accepted or not. We can extend/exploit those notions more with respect to the GK admission control in addition to the SLA. Best regards, Radhika -----Original Message----- From: Gary Thom [mailto:gthom@DELTA-INFO.COM] Sent: Friday, June 01, 2001 12:04 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Bob, I agree with your discussion of gatekeeper behavior, but there are gatekeeper actions that need to be taken regardless of the call model. For example admission policy will be affected by the desired service class. A service level agreement may relieve addmission restrictions for high priority calls. Gary -------------------------------------------- Name : Gary A. Thom Company: Delta Information Systems, Inc. Address: 300 Welsh Rd., Bldg 3 Horsham, PA 19044 USA Phone : +1-215-657-5270 x123 Fax : +1-215-657-5273 E-mail : gthom(a)delta-info.com Website: www.delta-info.com -------------------------------------------- -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@icn.siemens.com] Sent: Friday, June 01, 2001 10:57 AM To: 'gthom(a)delta-info.com'; 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 Gary, In the direct call routed model, Gatekeepers only register and authorize endpoints can calls. The call control messages do not involve the gatekeepers and therefore cannot control the gatekeeper handling of the call. Even in a gatekeeper routed model, there is no need for more than two gatekeepers (originating and terminating). There can be a lot of space and networks between the two. Firewalls tend to be used to isolate an enterprise network from a public network. The public network involves many providers and network segments without any firewalls. The application layer signaling data stream may be able to control its QOS. In that the RTP streaming data transport is separately routed from the application data stream. And it is not possible for one stream to control another stream without a fundamental change to the Internet fabric. I doubt that this will happen. If it does happen, it will not be fully implements for a very long time. (One of the IETF people proposed that this is not an engineering problem but the basis for a research project.) 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 ----------------------------------------------------------------- -----Original Message----- From: Gary Thom [mailto:gthom@delta-info.com] Sent: Friday, June 01, 2001 10:24 AM To: 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 The application layer QOS should be an indication of the abstract quality and priority requirements or capabilities. This should really be called "Application Level Service Class" because it affects more than just the transpost level QOS mechanisms. It also affects Gatekeeper and Gateway behaviour. This should be independent of the transport layer mechanisms. The mapping of service class to transport level QOS and Gatekeeper and Gateway behavior is an implementation issue or is subject to service level agreements. Gary -------------------------------------------- Name : Gary A. Thom Company: Delta Information Systems, Inc. Address: 300 Welsh Rd., Bldg 3 Horsham, PA 19044 USA Phone : +1-215-657-5270 x123 Fax : +1-215-657-5273 E-mail : gthom(a)delta-info.com Website: www.delta-info.com -------------------------------------------- -----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@MAILBAG.INTEL.COM]On Behalf Of Roy, Radhika R, ALCTA Sent: Friday, June 01, 2001 9:44 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Hi, Bob: You are right that the application layer does not control the lower layers (e.g., RTP, UDP, IP). So, there is a requirement how the lower layers can be coupled for implementation in cooperation with the higher layer. The fact of the matter is that the lower layers are responsible for sending the media streams between the source and destination path. This is the area for implementations and we have to see how far the SG16 is going to dig to address this problem because our works will be limited mostly in the upper application layer. AT&T contributions in the SG16 Brazil (May-June'01) meeting provide a framework how to address this problem. Any contributions along this line will be highly appreciated. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@icn.siemens.com] Sent: Friday, June 01, 2001 9:24 AM To: Roy, Radhika R, ALCTA; 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 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL
by Roy, Radhika R, ALCTA 01 Jun '01

01 Jun '01

Hi, Bob and Gary: There is already an optional requirement in H.323 that the GK does the admission control. For example, the bandwidth parameters are there where the GK decides whether the request can be accepted or not. We can extend/exploit those notions more with respect to the GK admission control in addition to the SLA. Best regards, Radhika -----Original Message----- From: Gary Thom [mailto:gthom@DELTA-INFO.COM] Sent: Friday, June 01, 2001 12:04 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Bob, I agree with your discussion of gatekeeper behavior, but there are gatekeeper actions that need to be taken regardless of the call model. For example admission policy will be affected by the desired service class. A service level agreement may relieve addmission restrictions for high priority calls. Gary -------------------------------------------- Name : Gary A. Thom Company: Delta Information Systems, Inc. Address: 300 Welsh Rd., Bldg 3 Horsham, PA 19044 USA Phone : +1-215-657-5270 x123 Fax : +1-215-657-5273 E-mail : gthom(a)delta-info.com Website: www.delta-info.com -------------------------------------------- -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@icn.siemens.com] Sent: Friday, June 01, 2001 10:57 AM To: 'gthom(a)delta-info.com'; 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 Gary, In the direct call routed model, Gatekeepers only register and authorize endpoints can calls. The call control messages do not involve the gatekeepers and therefore cannot control the gatekeeper handling of the call. Even in a gatekeeper routed model, there is no need for more than two gatekeepers (originating and terminating). There can be a lot of space and networks between the two. Firewalls tend to be used to isolate an enterprise network from a public network. The public network involves many providers and network segments without any firewalls. The application layer signaling data stream may be able to control its QOS. In that the RTP streaming data transport is separately routed from the application data stream. And it is not possible for one stream to control another stream without a fundamental change to the Internet fabric. I doubt that this will happen. If it does happen, it will not be fully implements for a very long time. (One of the IETF people proposed that this is not an engineering problem but the basis for a research project.) 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 ----------------------------------------------------------------- -----Original Message----- From: Gary Thom [mailto:gthom@delta-info.com] Sent: Friday, June 01, 2001 10:24 AM To: 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 The application layer QOS should be an indication of the abstract quality and priority requirements or capabilities. This should really be called "Application Level Service Class" because it affects more than just the transpost level QOS mechanisms. It also affects Gatekeeper and Gateway behaviour. This should be independent of the transport layer mechanisms. The mapping of service class to transport level QOS and Gatekeeper and Gateway behavior is an implementation issue or is subject to service level agreements. Gary -------------------------------------------- Name : Gary A. Thom Company: Delta Information Systems, Inc. Address: 300 Welsh Rd., Bldg 3 Horsham, PA 19044 USA Phone : +1-215-657-5270 x123 Fax : +1-215-657-5273 E-mail : gthom(a)delta-info.com Website: www.delta-info.com -------------------------------------------- -----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@MAILBAG.INTEL.COM]On Behalf Of Roy, Radhika R, ALCTA Sent: Friday, June 01, 2001 9:44 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Hi, Bob: You are right that the application layer does not control the lower layers (e.g., RTP, UDP, IP). So, there is a requirement how the lower layers can be coupled for implementation in cooperation with the higher layer. The fact of the matter is that the lower layers are responsible for sending the media streams between the source and destination path. This is the area for implementations and we have to see how far the SG16 is going to dig to address this problem because our works will be limited mostly in the upper application layer. AT&T contributions in the SG16 Brazil (May-June'01) meeting provide a framework how to address this problem. Any contributions along this line will be highly appreciated. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@icn.siemens.com] Sent: Friday, June 01, 2001 9:24 AM To: Roy, Radhika R, ALCTA; 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 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

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

Gary, In the direct call routed model, Gatekeepers only register and authorize endpoints can calls. The call control messages do not involve the gatekeepers and therefore cannot control the gatekeeper handling of the call. Even in a gatekeeper routed model, there is no need for more than two gatekeepers (originating and terminating). There can be a lot of space and networks between the two. Firewalls tend to be used to isolate an enterprise network from a public network. The public network involves many providers and network segments without any firewalls. The application layer signaling data stream may be able to control its QOS. In that the RTP streaming data transport is separately routed from the application data stream. And it is not possible for one stream to control another stream without a fundamental change to the Internet fabric. I doubt that this will happen. If it does happen, it will not be fully implements for a very long time. (One of the IETF people proposed that this is not an engineering problem but the basis for a research project.) 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 ----------------------------------------------------------------- -----Original Message----- From: Gary Thom [mailto:gthom@delta-info.com] Sent: Friday, June 01, 2001 10:24 AM To: 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 The application layer QOS should be an indication of the abstract quality and priority requirements or capabilities. This should really be called "Application Level Service Class" because it affects more than just the transpost level QOS mechanisms. It also affects Gatekeeper and Gateway behaviour. This should be independent of the transport layer mechanisms. The mapping of service class to transport level QOS and Gatekeeper and Gateway behavior is an implementation issue or is subject to service level agreements. Gary -------------------------------------------- Name : Gary A. Thom Company: Delta Information Systems, Inc. Address: 300 Welsh Rd., Bldg 3 Horsham, PA 19044 USA Phone : +1-215-657-5270 x123 Fax : +1-215-657-5273 E-mail : gthom(a)delta-info.com Website: www.delta-info.com -------------------------------------------- -----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@MAILBAG.INTEL.COM]On Behalf Of Roy, Radhika R, ALCTA Sent: Friday, June 01, 2001 9:44 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Hi, Bob: You are right that the application layer does not control the lower layers (e.g., RTP, UDP, IP). So, there is a requirement how the lower layers can be coupled for implementation in cooperation with the higher layer. The fact of the matter is that the lower layers are responsible for sending the media streams between the source and destination path. This is the area for implementations and we have to see how far the SG16 is going to dig to address this problem because our works will be limited mostly in the upper application layer. AT&T contributions in the SG16 Brazil (May-June'01) meeting provide a framework how to address this problem. Any contributions along this line will be highly appreciated. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@icn.siemens.com] Sent: Friday, June 01, 2001 9:24 AM To: Roy, Radhika R, ALCTA; 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 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

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

01 Jun '01

Hi, Gary: Yes, this is the idea as you have indicated. With respect to service classes let me add as follows: The service classes are nothing but composed of some attributes that have the implications for a group of performance parameters. 1. Dynamic and Pre-defined Service Classes Grouping Performance Parameters with no "values" of any Parameters So, endusers will be able to signal any group of performance parameters (that may imply a given service class) as they wish and the negotiation capability will be provided to choose the common set of performance parameters as they like to accept. This is called the creation of service classes dynamically. (For example, class 1 = (delay, jitter, losses), class 2 = (delay, jitter), class 3 = (delay), etc.) If needed, the flexibility can also be provided for a pre-defined service classes as well. 2. Dynamic and Pre-defined Service Classes Grouping Performance Parameters with specific "values" of all Parameters In addition to item 1, the service classes can be further be created dynamically or pre-defined assigning some specific value for each parameter and then group them together. (For example, delay = 50 mSecs (Class 3/Gold), delay = 100 (class 3 - silver), delay = 150 mSecs (class 3 - bronze), etc.) We can keep so many flexibilities in defining service classes. Best regards, Radhika -----Original Message----- From: Gary Thom [mailto:gthom@delta-info.com] Sent: Friday, June 01, 2001 10:24 AM To: Roy, Radhika R, ALCTA; ITU-SG16(a)MAILBAG.INTEL.COM Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL The application layer QOS should be an indication of the abstract quality and priority requirements or capabilities. This should really be called "Application Level Service Class" because it affects more than just the transpost level QOS mechanisms. It also affects Gatekeeper and Gateway behaviour. This should be independent of the transport layer mechanisms. The mapping of service class to transport level QOS and Gatekeeper and Gateway behavior is an implementation issue or is subject to service level agreements. Gary -------------------------------------------- Name : Gary A. Thom Company: Delta Information Systems, Inc. Address: 300 Welsh Rd., Bldg 3 Horsham, PA 19044 USA Phone : +1-215-657-5270 x123 Fax : +1-215-657-5273 E-mail : gthom(a)delta-info.com Website: www.delta-info.com -------------------------------------------- -----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@MAILBAG.INTEL.COM]On Behalf Of Roy, Radhika R, ALCTA Sent: Friday, June 01, 2001 9:44 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Hi, Bob: You are right that the application layer does not control the lower layers (e.g., RTP, UDP, IP). So, there is a requirement how the lower layers can be coupled for implementation in cooperation with the higher layer. The fact of the matter is that the lower layers are responsible for sending the media streams between the source and destination path. This is the area for implementations and we have to see how far the SG16 is going to dig to address this problem because our works will be limited mostly in the upper application layer. AT&T contributions in the SG16 Brazil (May-June'01) meeting provide a framework how to address this problem. Any contributions along this line will be highly appreciated. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@icn.siemens.com] Sent: Friday, June 01, 2001 9:24 AM To: Roy, Radhika R, ALCTA; 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 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 01 Jun '01

01 Jun '01

Hi, Bob and Gary: Bob is right that there are many problems: Firewalls, NATs, RTP signaling to UDP to IP, etc. However, RSVP, DiffServ, and MPLS schemes are there that are being used in the network layer. So, the application layer is not supposed to do anything NEW other than to establish a relationship between the existing network layer QOS so that the consistency remains on end-to-end basis. (Bob is right that the problems of addressing the public Internet QOS are not so easy - may be "best-effort" is the easy way to do something!!) Best regards, Radhika -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] Sent: Friday, June 01, 2001 10:57 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Gary, In the direct call routed model, Gatekeepers only register and authorize endpoints can calls. The call control messages do not involve the gatekeepers and therefore cannot control the gatekeeper handling of the call. Even in a gatekeeper routed model, there is no need for more than two gatekeepers (originating and terminating). There can be a lot of space and networks between the two. Firewalls tend to be used to isolate an enterprise network from a public network. The public network involves many providers and network segments without any firewalls. The application layer signaling data stream may be able to control its QOS. In that the RTP streaming data transport is separately routed from the application data stream. And it is not possible for one stream to control another stream without a fundamental change to the Internet fabric. I doubt that this will happen. If it does happen, it will not be fully implements for a very long time. (One of the IETF people proposed that this is not an engineering problem but the basis for a research project.) 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 ----------------------------------------------------------------- -----Original Message----- From: Gary Thom [mailto:gthom@delta-info.com] Sent: Friday, June 01, 2001 10:24 AM To: 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 The application layer QOS should be an indication of the abstract quality and priority requirements or capabilities. This should really be called "Application Level Service Class" because it affects more than just the transpost level QOS mechanisms. It also affects Gatekeeper and Gateway behaviour. This should be independent of the transport layer mechanisms. The mapping of service class to transport level QOS and Gatekeeper and Gateway behavior is an implementation issue or is subject to service level agreements. Gary -------------------------------------------- Name : Gary A. Thom Company: Delta Information Systems, Inc. Address: 300 Welsh Rd., Bldg 3 Horsham, PA 19044 USA Phone : +1-215-657-5270 x123 Fax : +1-215-657-5273 E-mail : gthom(a)delta-info.com Website: www.delta-info.com -------------------------------------------- -----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@MAILBAG.INTEL.COM]On Behalf Of Roy, Radhika R, ALCTA Sent: Friday, June 01, 2001 9:44 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Hi, Bob: You are right that the application layer does not control the lower layers (e.g., RTP, UDP, IP). So, there is a requirement how the lower layers can be coupled for implementation in cooperation with the higher layer. The fact of the matter is that the lower layers are responsible for sending the media streams between the source and destination path. This is the area for implementations and we have to see how far the SG16 is going to dig to address this problem because our works will be limited mostly in the upper application layer. AT&T contributions in the SG16 Brazil (May-June'01) meeting provide a framework how to address this problem. Any contributions along this line will be highly appreciated. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@icn.siemens.com] Sent: Friday, June 01, 2001 9:24 AM To: Roy, Radhika R, ALCTA; 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 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL
by Roy, Radhika R, ALCTA 01 Jun '01

01 Jun '01

Hi, Bob: You are right that the application layer does not control the lower layers (e.g., RTP, UDP, IP). So, there is a requirement how the lower layers can be coupled for implementation in cooperation with the higher layer. The fact of the matter is that the lower layers are responsible for sending the media streams between the source and destination path. This is the area for implementations and we have to see how far the SG16 is going to dig to address this problem because our works will be limited mostly in the upper application layer. AT&T contributions in the SG16 Brazil (May-June'01) meeting provide a framework how to address this problem. Any contributions along this line will be highly appreciated. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@icn.siemens.com] Sent: Friday, June 01, 2001 9:24 AM To: Roy, Radhika R, ALCTA; 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 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

2 1