- sg16-avd - lists.packetizer.com

Re: Documents for the SG16 meeting in Porto Seguro
by OKUBO Sakae 15 May '01

15 May '01

Dear Mr. Gilman, Mr. Sayer and all, Your contributions have been placed at the /0105_Por directory of the ftp site. SOURCE: Avaya TITLE: Basic H.248 Packages for Support of External Signal Sources http://standard.pictel.com/ftp/avc-site/0105_Por/extsigpkg.zip SOURCE: Lucent Technologies TITLE: Multimedia Support Using the Decomposed H.323/H.3XX Gateway Architecture http://standard.pictel.com/ftp/avc-site/0105_Por/DelayedConLucentToQ3.zip 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

2 1

Re: E-mail reflectors
by Sebestyen Istvan ICN M SR 3 15 May '01

15 May '01

Well, the best Source of Info are the slides from the ITU-T IP - MEDIACOM2004 Workshop (under www.itu.int --> ITU-T Standardization). There were two full sessions dealing with those general topics, and it was decided by each group to set up a reflector to continue the discussion they have started during the workshop. Regards, Istvan Sebestyen -------------------------------------------------------------------------- Dr. Istvan Sebestyen Siemens AG, ICN M SR 3, Hofmannstr. 51, D-81359 Munich, Germany Tel:+49-89-722-47230 Fax:+49-89-722-47713 E-Mail office: istvan.sebestyen(a)icn.siemens.de; istvan(a)sebestyen.de E-mail private: istvan_sebestyen(a)yahoo.com; Siemens Intranet:http://intranet.icn.siemens.de/marketing/cs27/ Siemens FTP: ftp://mchhpn006a.mch.pn.siemens.de/ ---------------------------------------------------------------------------- ---------------- > ---------- > From: Weijun Jiang[SMTP:jiang@PACKETVIDEO.COM] > Reply To: Weijun Jiang > Sent: Tuesday, May 15, 2001 12:57 AM > To: ITU-SG16(a)mailbag.cps.INTEL.COM > Subject: Re: E-mail reflectors > > Hi, > > Could anyone tell me what kind of topics can be discussed in the two > reflectors? > > Thank you, > > weijun > > Weijun Jiang > PacketVideo > 4820 eastgate mall > San Diego, CA 92121 > (Office)858-731-5380 > (Fax) 858-731-5305 > (Email)jiang(a)pv.com > > > -----Original Message----- > From: Tosco Federico (by way of OKUBO Sakae) > [mailto:Federico.Tosco@TILAB.COM] > Sent: Sunday, May 13, 2001 7:03 PM > To: ITU-SG16(a)mailbag.cps.INTEL.COM > Subject: I:E-mail reflectors > > > /// Message from Mr. Tosco to those who are ITU-T Sector members /// > > For information. > > Federico > > > ---------- > > Da: Bigi, Fabio[SMTP:Fabio.Bigi@itu.int] > > Inviato: gioved $BE (B10 maggio 2001 17.39 > > A: Magill (E-mail); Mitsuji Matsumoto; Probst (E-mail); Simao Campos > > (E-mail); Tosco (E-mail); Wreikat > > Cc: Brian Moore (E-mail) > > Oggetto: E-mail reflectors > > > > Dear colleagues, > > > > I would like to inform you that as from tomorrow two new e-mail > reflectors > > will be in place. > > tsg16convergence > > tsg16ecommerce > > > > To register you may use the following site: > > http://www.itu.int/ITU-T/com16/edh/subscribe.html > > > > Please inform all those who might be involved in the subject. > > > > Best regards > > Fabio > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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: E-mail reflectors
by Weijun Jiang 14 May '01

14 May '01

Hi, Could anyone tell me what kind of topics can be discussed in the two reflectors? Thank you, weijun Weijun Jiang PacketVideo 4820 eastgate mall San Diego, CA 92121 (Office)858-731-5380 (Fax) 858-731-5305 (Email)jiang(a)pv.com -----Original Message----- From: Tosco Federico (by way of OKUBO Sakae) [mailto:Federico.Tosco@TILAB.COM] Sent: Sunday, May 13, 2001 7:03 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: I:E-mail reflectors /// Message from Mr. Tosco to those who are ITU-T Sector members /// For information. Federico > ---------- > Da: Bigi, Fabio[SMTP:Fabio.Bigi@itu.int] > Inviato: gioved $BE (B10 maggio 2001 17.39 > A: Magill (E-mail); Mitsuji Matsumoto; Probst (E-mail); Simao Campos > (E-mail); Tosco (E-mail); Wreikat > Cc: Brian Moore (E-mail) > Oggetto: E-mail reflectors > > Dear colleagues, > > I would like to inform you that as from tomorrow two new e-mail reflectors > will be in place. > tsg16convergence > tsg16ecommerce > > To register you may use the following site: > http://www.itu.int/ITU-T/com16/edh/subscribe.html > > Please inform all those who might be involved in the subject. > > Best regards > Fabio > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

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

14 May '01

Dear colleagues, I have been requested to pass on to you the following additional information regarding the SG 16 meeting in Brazil: - It is advised that all good carried by the travellers (except for personal effects in quantity and quality compatible with the length and purpose of the trip) that exceed the global value of US$500 be declared in the form "Declaration for Accompanined Luggage" ("Declaração de Bagagem Acompanhada", DBA). The DBA will be available in the customs at the airport printed in English, Spanish, and Portuguese. In the case of personal laptops, cameras, etc, whose value exceeds R$3,000 (~US$1,200), a permit for temporary admission will be issued from the declation of the goods in the DBA. This will allow the items the enter and exit Brazil without the imposition of taxes. The traveller should upon arrival go to the (red) "Goods to Declare" ("Bens a Declarar") gate in order to get the temporary admission permit issued, not the (green) "Nothing to Declare" ("Nada a Declarar") gate. - Please note that if you carry foreign currency other than US Dollars, you will have to exchange money at one of the international airports (Guarulhos in São Paulo and Galeão in Rio de Janeiro). On the other hand, exchange of US Dollars into Reais is available in Porto Seguro. - If you need a visa for Brazil and did not get one yet, I suggest that you attach a copy of the Collective Letter 01/16 (http://www.itu.int/itudoc/itu-t/com16/coll/01-04/001.html) to the visa application form and state that you are attending the ITU-T SG 16 Meeting in Porto Seguro organized by ANATEL under the invitation of the International Telecommunication Union. - It is suggested that the dress code for the meeting be "casual dressing" (hurray!). I am currently checking on details regarding the transporation between the airport (BPS) and the ferry to the hotel. I will send you an update when I get some more details on the subject. Best regards, Simão Campos-Neto -- =========================================================================== Simão Ferraz de Campos Neto, Scientist *All comments are strictly my own* LMGT/COMSAT Laboratories Tel: +1-301-428-4516 22300 Comsat Drive Fax: +1-301-428-9287 Clarksburg MD 20871 - USA E-mail: simao.campos(a)labs.comsat.com =========================================================================== ******** Practice random kindness and senseless acts of beauty ******** ===========================================================================

1 0

Megaco call Flows using Asn.1
by Leano, Bob 14 May '01

14 May '01

Cany you please direct me to a reference for megaco call flow examples using asn.1? all the examples that I have seen use ABNF. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H.225v4 correction
by Terry L Anderson 14 May '01

14 May '01

There is a minor editing error in the prepub version of H.225.0v4. In section 7.6, concerning the definition of GloballyUniqueID, there is a numbered list specifying the algorithm. In item 5, the reference to table 20 should be to table 19 (tables were renumbering from v3 and the renumbering of the reference evidently didn't stay in synch). Perhaps this should be corrected in IG. In addition, the specification of conditions underwhich the clock sequence value should be changed (two paragraphs above the numbered list) omits the case where the current UTC EQUALS the saved UTC. It specifies that the clock sequence value should be changed if the current is LESS than the saved value (non-monotonic case) but a similar problem occurs if the clock has not ticked (GID will not be unique). It would be better if the condition were reworded to say "if the current value less or equal or the saved value was lost..." and the bullet item above changed to "... the local value of UTC has gone backward or not increased..." (or an additional bullet item added). Admittedly, if the recommended 100ns clock tick is used, the probability of the clock not having advanced may be low, but not impossible as we move to faster processors. This problem is not new to v4 but since the correction would not cause a compatibility problem, it would be good to correct. If we do not choose to modify v4 through the IG we should at least make this change in v5. -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

1 0

PER ASN.1 encoding of Sequence Of Elements - Boundary Conditions
by Paul, Manoj 13 May '01

13 May '01

Hi All, Is it a valid situation if a "Sequence Of" element is encoded with number of components as 0? PER rules dictate that the lower bound on the number of components is set to 0, if lower bound is not explicitly defined. Since the minimum is 0, one can encode the "Sequence Of" element with 0 components. What would it mean to encode a Sequence Of with no components encoded? In this case, though, there may be a few bits added to the field list for the length determinant of Sequence Of with value 0. Thanks Manoj. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

3 2

I:E-mail reflectors
by Tosco Federico (by way of OKUBO Sakae) 13 May '01

13 May '01

/// Message from Mr. Tosco to those who are ITU-T Sector members /// For information. Federico > ---------- > Da: Bigi, Fabio[SMTP:Fabio.Bigi@itu.int] > Inviato: gioved $BE (B10 maggio 2001 17.39 > A: Magill (E-mail); Mitsuji Matsumoto; Probst (E-mail); Simao Campos > (E-mail); Tosco (E-mail); Wreikat > Cc: Brian Moore (E-mail) > Oggetto: E-mail reflectors > > Dear colleagues, > > I would like to inform you that as from tomorrow two new e-mail reflectors > will be in place. > tsg16convergence > tsg16ecommerce > > To register you may use the following site: > http://www.itu.int/ITU-T/com16/edh/subscribe.html > > Please inform all those who might be involved in the subject. > > Best regards > Fabio > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: MCU decomposition delayed contribution
by OKUBO Sakae 13 May '01

13 May '01

Dear Mr. Even and all, >Attached is a copy of the delayed contribution I submitted about MCU >decomposition. Please load it to the AVT site It is now available at the following place: http://standard.pictel.com/ftp/avc-site/0105_Por/MCU_Decomposition.zip 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 ********************************************************* My contract with TAO finished on 31 March. Please change my e-mail address as above, though okubo(a)giti.or.jp will continue to work for some time. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Contributions from DIS and AT&T
by OKUBO Sakae 11 May '01

11 May '01

Dear Mr. Thom, Mr. Roy and all, GT> I have uploaded two contributions to the incoming directory of GT> the AVC ftp site. GT> HGEF4.doc GT> h246AnnexCchanges.doc GT> GT> These have been submitted to the TSB as Delayed Contributions, GT> source: Delta Information Systems. These two delayed contributions from DIS and the following nine from AT&T have been moved to http://standard.pictel.com/ftp/avc-site/0105_Por/: 1. Scope of Q.F/16 - QOS and End-to-End Performance (File:D01_ATT_QOS_Scope) 2. Framework of QOS and End-to-End Performance in Multimedia Systems (File: D02_ATT_QOS_FW) 3. Enclosure on (View Graphs Presentation) Framework of QOS and End-to-End Performance in Multimedia Systems (File:D03_ATT_QOS_FW_SG16) 4. Problems for Using H.225.0 Annex G Protocol for H.MMS.1 (H.323 Mobility) and Proposed Solution (File: D04_ATT_Mobility_MMS1) 5. Scope of Q.5/16 - Mobility for Multimedia Systems and Services (File: D05_ATT_Mobility_Scope) 6. Framework for Extensions of Multimedia Applications/Systems and Services (File: D06_ATT_Mobility_FW) 7. Enclosure on (View Graphs Presentation) Framework for Extensions of Multimedia Applications/Systems and Services (File:D07_ATT_Mobility_FW_SG16) 8. Common Mobility Management Protocol for all Multimedia Applications/Systems and Services (File: D08_ATT_ Mobility_Mgmt) 9. Enclosure on (View Graphs Presentation) Common Mobility Management Protocol for all Multimedia Applications/Systems and Services (File:D09_ATT_Mobility_Mgmt_SG16) 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

Contribution for Porto Seguro meeting
by Gary Thom 11 May '01

11 May '01

I have uploaded two contributions to the imcomming directory of the AVC ftp site. HGEF4.doc h246AnnexCchanges.doc These have been submitted to the TSB as Delayed Contributions, source: Delta Information Systems. 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 -------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

AW: Question about H.323 Version 4 setup message.
by Horvath Ernst 11 May '01

11 May '01

Paul, the Redirecting number information element is defined in Q.952 (Call Diversion supplementary service). It has probably been included in H.225.0 Setup for interworking with SCNs. Ernst Horvath > -----Ursprüngliche Nachricht----- > Von: Paul, Manoj [mailto:mpaul@TRILLIUM.COM] > Gesendet am: Freitag, 11. Mai 2001 03:02 > An: ITU-SG16(a)mailbag.cps.INTEL.COM > Betreff: Question about H.323 Version 4 setup message. > > Hi All, > > A field "Redirecting Number" has been added in H.225 > Version 4 as an IE > in > Setup message (Section 7.3.10, Table 12/H.225.0). The table > 12/H.225.0 is > derived > from Table 3-15/Q.931. I could not find "Redirecting Number" > in the Q.931 > table. > Could anyone please give any pointer about why is it so? > 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

Question about H.323 Version 4 setup message.
by Paul, Manoj 10 May '01

10 May '01

Hi All, A field "Redirecting Number" has been added in H.225 Version 4 as an IE in Setup message (Section 7.3.10, Table 12/H.225.0). The table 12/H.225.0 is derived from Table 3-15/Q.931. I could not find "Redirecting Number" in the Q.931 table. Could anyone please give any pointer about why is it so? thanks, Manoj Paul. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Encoding of H.248 in H.323
by Frank Derks 10 May '01

10 May '01

H.248 specifies both a binary (using the BER) and a text format for the encoding of its messages. 7.2.2.28/H.225.0 states that either of these formats can be used for H.323 Annex L. Are there reasons, other than the fact that the BER and text are specified in H.248, to dissallow encoding using the PER? It would seem that having to use two different encoding schemes (PER+BER or PER+text) makes things unnecessarily complex. Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

RE: IP Type of Service
by Michael Brown 10 May '01

10 May '01

The contributions do indeed suggest that the work in SG 11 be coordinated with SG 16 and IETF. -----Original Message----- From: Taylor, Tom-PT [NORSE:B881:EXCH] Sent: Wednesday, May 09, 2001 11:41 PM To: Brown, Michael [NC1:GW10:EXCH]; Petros N. Mouchtaris Cc: megaco; SG16; Oskar vanDeventer Subject: RE: IP Type of Service However, any changes to SDP have to be done in the IETF, and since QOS relates to media streams, it really has to be done in SDP as well as anywhere else the ITU-T and other bodies see fit to put it. -----Original Message----- From: Brown, Michael [NC1:GW10:EXCH] Sent: Wednesday, May 09, 2001 4:47 PM To: Petros N. Mouchtaris Cc: megaco; SG16; Oskar vanDeventer Subject: RE: IP Type of Service There are at least four contributions to the upcoming Study Group 11 meeting (May 14-May 25)related to this topic. If you have ITU TIES access, they are under Delayed Contributions 207, 212, 214, and 215. -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ericsson.com] Sent: Wednesday, May 09, 2001 1:41 AM To: Petros N. Mouchtaris Cc: Rosen, Brian; megaco; SG16; Oskar vanDeventer Subject: Re: IP Type of Service I think that any work on QoS parameters should be aligned with the work occuring in ETSI Tiphon, ITU SG16, ITU SG11 etc. There's been a considerable amount of effort in trying to come up with common parameters for QoS. Any solution should tap into this. Cheers, Christian "Petros N. Mouchtaris" wrote: > > Brian, > > Actually there was a long discussion on this topic last year on the mailing > list i.e. whether MGC should be able to signal an MG which TOS bit to use. > The whole topic ended up being dropped. Check the archive for e-mails with > title "MG and DiffServ". > > By the way, Flemming had volunteered to do some work but I assume it didn't > have high enough priority. > > Excerpt from e-mail: > > "Tom-PT Taylor wrote: > > > You are correct that packages should be drawn up (and/or SDP defined) to > > allow QOS parameter setting. Volunteers? > > Sure - I can put a package proposal together. > > -- Flemming > > Petros > > "Rosen, Brian" <Brian.Rosen(a)marconi.com> on 05/08/2001 03:29:44 PM > > To: "'Tom-PT Taylor'" <taylor(a)nortelnetworks.com>, "'Madhu Babu > Brahmanapally'" <madhubabu(a)kenetec.com>, "Rosen, Brian" > <Brian.Rosen(a)marconi.com>, "'Chuong Nguyen'" > <Chuong.Nguyen(a)usa.alcatel.com>, megaco <megaco(a)fore.com> > cc: (bcc: Petros N. Mouchtaris/Telcordia) > Subject: RE: IP Type of Service > > I'll look into this. I agree. > > Brian > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: Tuesday, May 08, 2001 10:07 AM > To: 'Madhu Babu Brahmanapally'; 'Rosen, Brian'; 'Chuong Nguyen'; megaco > Subject: RE: IP Type of Service > > That makes sense. > > -----Original Message----- > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] > Sent: Tuesday, May 08, 2001 10:08 AM > To: 'Rosen, Brian'; Taylor, Tom-PT [NORSE:B881:EXCH]; 'Chuong Nguyen'; > megaco > Subject: RE: IP Type of Service > > Hi All, > Another suggestion. Why cant the SDP be extended to incorporate a TOS > parameter/attribute so that all the protocols(SIP,Megaco,MGCP) that use SDP > need not define extra properties/parameter for supporting this. > > Regards > Madhubabu > > -----Original Message----- > From: owner-megaco(a)pit.comms.marconi.com > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian > Sent: Tuesday, May 08, 2001 9:24 AM > To: 'Madhu Babu Brahmanapally'; 'Tom-PT Taylor'; 'Chuong Nguyen'; > megaco(a)fore.com > Subject: RE: IP Type of Service > > I don't agree. The TOS for a particular stream should be set on that > stream, not > on the MG as a whole. For example, if I have a multimedia MG, I will want > to set > the priority of voice higher than video, and video higher than normal. If > I > implement a > Multilevel Pre-emption and Priority scheme, some calls will have higher > priority than > others. The TOS/frame priority has to be per stream. > > Brian > > -----Original Message----- > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] > Sent: Tuesday, May 08, 2001 9:24 AM > To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Chuong Nguyen'; megaco(a)fore.com > Subject: RE: IP Type of Service > > Hi All, > > The default TOS type should be defined on the ROOT termination for the > default TOS used for all media packets generated from the MG. There should > be a method (might be through some property) of specifying stream level TOS > bits. > > I'm interested to work on RSVP. > > Regards > Madhubabu > > -----Original Message----- > From: owner-megaco(a)pit.comms.marconi.com > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian > Sent: Tuesday, May 08, 2001 8:10 AM > To: 'Tom-PT Taylor'; 'Chuong Nguyen'; 'megaco(a)fore.com' > Subject: RE: IP Type of Service > > TOS should not be ignored at the edge router if the router is configured to > enable DiffServ. > > It would be pretty simple to create one package that had the appropriate > controls for > DiffServ and 802.1p. RSVP needs it's own package because there is > messaging, > and you at least an event or two > > The former could be an enumeration: QosMarking, that had values None, TOS > and > FramePriority, plus another integer, Value. That would suffice I think, > although you > could conceivably get more clever with DiffServ. > > Shall I write something up along those lines? > > RSVP takes some more work. Any volunteers? > > Brian > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: Monday, May 07, 2001 9:15 PM > To: 'Chuong Nguyen'; 'megaco(a)fore.com' > Subject: RE: IP Type of Service > > No such package has yet been defined. > > Various QOS architectures can be imagined. Each would give rise to its own > package, since the MGC-MG information flow would differ from one > architecture to the next. One question: unless the MG is itself the edge > router, won't the ToS be ignored when the media packets reach the latter? > > -----Original Message----- > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com] > Sent: Monday, May 07, 2001 5:14 PM > To: 'megaco(a)fore.com' > Subject: IP Type of Service > > All > > In MGCP, MGC can specify IP Type of Service to the MG. > Do we have an equivalent in Megaco? > > Is there or has anyone defined a package for IP Type of Service? > > Thanks > Chuong > > -- > > Alcatel USA, Inc Internet: Chuong.Nguyen(a)usa.alcatel.com > > 1000 Coit Road Plano, Texas 75075 Phone: (972) 519-4613 > > **** The opinions expressed are not those of Alcatel USA, Inc **** > > ------------------------------------------------------------------------ > Name: att1.htm > att1.htm Type: Hypertext Markup Language (text/html) > Encoding: base64

1 0

sourceAddress and destinationAddress in SETUP
by Frank Derks 10 May '01

10 May '01

7.3.10/H.225.0 states the following in the section on the sourceAddress field: "Note that the E.164 number of the source, if any, shall be contained within the Calling Party Number Information Element." 7.3.10/H.225.0 states the following in the section on the destinationAddress field: "When calling an endpoint using only a dialed digit string, this address shall be placed in the Q.931 Called Party Number IE." First of all I am wondering about how a source "knows" that its number is an E.164 address and how it knows about the numbering plan that this number belongs to so it can actually fill in the Calling Party Number IE. I would expect that this is something that is normally not known by a Terminal, an MCU and a Gateway. Secondly, the section on the destinationAddress could have been a bit more explicit as to how the Called Party Number IE should be filled in. I assume that, if a digit string is used, the "type of number" is "unknown" and the "numbering plan identification" is also "unknown". Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

AW: Encoding of H.248 in H.323
by Klaghofer Karl ICN EN HC ID 71 10 May '01

10 May '01

Frank, There was a change proposed for the H.323 IG in the March Launceston meeting on this subject. The proposal was to allow both Binary (PER !) and Text. The outcome of the meeting is contained in TD-44 of the Launceston meeting. I guess this is for approval in Brazil. Karl -----Ursprüngliche Nachricht----- Von: Frank Derks [mailto:frank.derks@PHILIPS.COM] Gesendet: Donnerstag, 10. Mai 2001 15:08 An: ITU-SG16(a)mailbag.cps.INTEL.COM Betreff: Encoding of H.248 in H.323 H.248 specifies both a binary (using the BER) and a text format for the encoding of its messages. 7.2.2.28/H.225.0 states that either of these formats can be used for H.323 Annex L. Are there reasons, other than the fact that the BER and text are specified in H.248, to dissallow encoding using the PER? It would seem that having to use two different encoding schemes (PER+BER or PER+text) makes things unnecessarily complex. 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

Delayed contribution on Q4/16 from Waseda University
by OKUBO Sakae 10 May '01

10 May '01

Dear SG16 experts, The subject contribution has been sent to Mr. Bigi and also placed at the ftp site: http://standard.pictel.com/ftp/avc-site/0105_por/delayed_Q4_Waseda.zip Its text version is attached for your quick reading. Please also be advised that the Launceston meeting report has been sent to Mr. Bigi and placed at the ftp site: http://standard.pictel.com/ftp/avc-site/0105_por/TDxx-WP2_AVD-2100.zip 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 ********************************************************* ITU - Telecommunication Standardization Sector Study Period 2001-2004 Study Group 16 Delayed Contribution D.xxx Porto Seguro, 28 May - 8 June 2001 Questions: 4/16, C/16 SOURCE*: WASEDA UNIVERSITY TITLE: SOME SCENARIOS FOR THE USE OF INTERNET SERVICES TO ENHANCE VIDEOCONFERENCING AND VIDEOPHONE ___________________ 1. Introduction In response to the request made at the Launceston Rapporteur meeting[1], this contribution provides some scenarios for the utilization of internet services to enhance videoconferencing and videophone that would form a basis to derive technical requirements for the enhanced system. 2. Internet services to be considered Internet services may be classified into two categories; transport services like multicast and applications services on top of UDP/IP or TCP/IP. This contribution focuses on use of the latter application services that enhance basic audio and video functionalities of videoconferencing and videophone systems. Some possible service scenarios are described from the user's perspective. 3. Example scenarios A. Retrieval and presentation of web materials A.1 Use of the web site as a private database This is an alternative of bringing large amount of paper documents or electronic files to the meeting site that should be referred to during the meeting session. A.2 Use of web pages for the presentation We can utilize multimedia contents on the web for persuasive presentation of the meeting subject. There may be a case of presenting the image the presenter has chosen to all the participants and a case of each participant accessing the designated web page. In case the presented document is to be collaboratively worked out by the meeting participants, the presentation image is shared by all and each participant can add or modify the document from his/her own PC after obtaining the chairperson's permission. A.3 Integration with reservation of meeting resources such as meeting room and circuit Reservation systems using web technology are foreseen to prevail. The reservation service and the enhanced services described here can be provided with a unified interface like web browser. A.4 Automatic response to the incoming telephone call On behalf of the absent callee, a web server responds to the incoming call from a telephone set with display. One of the menu items can be selected; request of call back, leaving a message, transfer to another telephone, recording of the message, etc [2]. Use of mobile phone as web browser is widely deployed and similar service for the fixed phone (called L-mode) is going to start in June in Japan. Future telephone set will be equipped with a display and internet accessibility. A.5 Use of browser first to the incoming telephone call In contrast with the above A.4 case where the callee is absent, a browser can be utilized even in case the callee is present. The incoming call is first responded with a browser phone or PC (acting as secretary), then based on the information regarding the caller, the callee may choose to take a voice conversation, record a message, respond with another phone (call transfer), or reject the call. B. Instant messaging, chat B.1 Private communication among meeting participants Members of the same group (section, division, company, etc) or those in alliance may wish to exchange opinions or information and give and receive instructions during the meeting session. This is an analogy of whispering into colleague's ear or assembling among members during the meeting. B.2 Private communication with those who are not attending the meeting The above communication (B.1) may be extended to outside members who are not attending the meeting but supporting those who are in the meeting. They may be experts, managers or group members. C. E-mail C.1 Communication with other meeting participants or outside experts During the meeting session, a meeting participant may exchange views and information with members with inside or outside the meeting. C.2 Management of pre-meeting mailing list discussion A tool is desired to make a report of the pre-meeting mailing list discussion. Visualization of who commented what on whose opinion is desirable. C.3 Assistance to create ad-hoc groups A tool is desired to easily create an ad-hoc group for discussing a particular topic after the meeting and to register participants. D. File transfer D.1 Distribution of meeting documents In advance of or during the meeting, meeting documents are electronically distributed. This service is already utilized for our ITU-T Rapporteur meetings. E. Streaming E.1 Presentation Instead of presenting motion pictures by using a VCR, audio, video or audiovisual materials stored at the server can be presented during the meeting session. E.2 Record of the meeting Meeting scenes are sent to a local or remote server where they are archived together with such metadata as meeting objectives, participants, agenda for later information retrieval. F. Seamless transition between telephone and multimedia communication F.1 Starting with mono media (telephone) and multimedia (video, data) being added or removed later as necessary A call center is accessed by telephone, information retrieval and menu selection are carried out with audio input, then pre-view or pre-listening is given as picture or audio, and finally desired information content (such as a melody for mobile phone "ringing melody") is downloaded. G. Others G.1 Integration of electronic documents and handwritten presentations such as diagrams on whiteboard that are created during the meeting A tool is desired to easily integrate materials handwritten on electronic blackboard or flip chart with a Word or PDF file and distribute it to the meeting participants. 4. Conclusion This contribution has given some usage scenarios of internet services that can enhance the basic audio and video functionalities of videoconferencing and videophone. As many service scenarios as possible should be collected from user's viewpoints to derive technical requirements for the system design. Acknowledgements Draft of this contribution was reviewed by the members of TTC AVS Working Group whose comments, particularly those from Canon, NEC and Oki Electric, have been thankfully incorporated into this contribution. References [1] TD-xx (WP2/16), Report of the Launceston meeting, AVD-2100, March 2001 [2] TD-xy (WP2/16), Draft Annex I to H.324 "Usage of HTTP Generic Capability in H.324 terminals" May 2001 ____________________ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: IP Type of Service
by Tom-PT Taylor 10 May '01

10 May '01

However, any changes to SDP have to be done in the IETF, and since QOS relates to media streams, it really has to be done in SDP as well as anywhere else the ITU-T and other bodies see fit to put it. -----Original Message----- From: Brown, Michael [NC1:GW10:EXCH] Sent: Wednesday, May 09, 2001 4:47 PM To: Petros N. Mouchtaris Cc: megaco; SG16; Oskar vanDeventer Subject: RE: IP Type of Service There are at least four contributions to the upcoming Study Group 11 meeting (May 14-May 25)related to this topic. If you have ITU TIES access, they are under Delayed Contributions 207, 212, 214, and 215. -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ericsson.com] Sent: Wednesday, May 09, 2001 1:41 AM To: Petros N. Mouchtaris Cc: Rosen, Brian; megaco; SG16; Oskar vanDeventer Subject: Re: IP Type of Service I think that any work on QoS parameters should be aligned with the work occuring in ETSI Tiphon, ITU SG16, ITU SG11 etc. There's been a considerable amount of effort in trying to come up with common parameters for QoS. Any solution should tap into this. Cheers, Christian "Petros N. Mouchtaris" wrote: > > Brian, > > Actually there was a long discussion on this topic last year on the mailing > list i.e. whether MGC should be able to signal an MG which TOS bit to use. > The whole topic ended up being dropped. Check the archive for e-mails with > title "MG and DiffServ". > > By the way, Flemming had volunteered to do some work but I assume it didn't > have high enough priority. > > Excerpt from e-mail: > > "Tom-PT Taylor wrote: > > > You are correct that packages should be drawn up (and/or SDP defined) to > > allow QOS parameter setting. Volunteers? > > Sure - I can put a package proposal together. > > -- Flemming > > Petros > > "Rosen, Brian" <Brian.Rosen(a)marconi.com> on 05/08/2001 03:29:44 PM > > To: "'Tom-PT Taylor'" <taylor(a)nortelnetworks.com>, "'Madhu Babu > Brahmanapally'" <madhubabu(a)kenetec.com>, "Rosen, Brian" > <Brian.Rosen(a)marconi.com>, "'Chuong Nguyen'" > <Chuong.Nguyen(a)usa.alcatel.com>, megaco <megaco(a)fore.com> > cc: (bcc: Petros N. Mouchtaris/Telcordia) > Subject: RE: IP Type of Service > > I'll look into this. I agree. > > Brian > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: Tuesday, May 08, 2001 10:07 AM > To: 'Madhu Babu Brahmanapally'; 'Rosen, Brian'; 'Chuong Nguyen'; megaco > Subject: RE: IP Type of Service > > That makes sense. > > -----Original Message----- > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] > Sent: Tuesday, May 08, 2001 10:08 AM > To: 'Rosen, Brian'; Taylor, Tom-PT [NORSE:B881:EXCH]; 'Chuong Nguyen'; > megaco > Subject: RE: IP Type of Service > > Hi All, > Another suggestion. Why cant the SDP be extended to incorporate a TOS > parameter/attribute so that all the protocols(SIP,Megaco,MGCP) that use SDP > need not define extra properties/parameter for supporting this. > > Regards > Madhubabu > > -----Original Message----- > From: owner-megaco(a)pit.comms.marconi.com > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian > Sent: Tuesday, May 08, 2001 9:24 AM > To: 'Madhu Babu Brahmanapally'; 'Tom-PT Taylor'; 'Chuong Nguyen'; > megaco(a)fore.com > Subject: RE: IP Type of Service > > I don't agree. The TOS for a particular stream should be set on that > stream, not > on the MG as a whole. For example, if I have a multimedia MG, I will want > to set > the priority of voice higher than video, and video higher than normal. If > I > implement a > Multilevel Pre-emption and Priority scheme, some calls will have higher > priority than > others. The TOS/frame priority has to be per stream. > > Brian > > -----Original Message----- > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] > Sent: Tuesday, May 08, 2001 9:24 AM > To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Chuong Nguyen'; megaco(a)fore.com > Subject: RE: IP Type of Service > > Hi All, > > The default TOS type should be defined on the ROOT termination for the > default TOS used for all media packets generated from the MG. There should > be a method (might be through some property) of specifying stream level TOS > bits. > > I'm interested to work on RSVP. > > Regards > Madhubabu > > -----Original Message----- > From: owner-megaco(a)pit.comms.marconi.com > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian > Sent: Tuesday, May 08, 2001 8:10 AM > To: 'Tom-PT Taylor'; 'Chuong Nguyen'; 'megaco(a)fore.com' > Subject: RE: IP Type of Service > > TOS should not be ignored at the edge router if the router is configured to > enable DiffServ. > > It would be pretty simple to create one package that had the appropriate > controls for > DiffServ and 802.1p. RSVP needs it's own package because there is > messaging, > and you at least an event or two > > The former could be an enumeration: QosMarking, that had values None, TOS > and > FramePriority, plus another integer, Value. That would suffice I think, > although you > could conceivably get more clever with DiffServ. > > Shall I write something up along those lines? > > RSVP takes some more work. Any volunteers? > > Brian > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: Monday, May 07, 2001 9:15 PM > To: 'Chuong Nguyen'; 'megaco(a)fore.com' > Subject: RE: IP Type of Service > > No such package has yet been defined. > > Various QOS architectures can be imagined. Each would give rise to its own > package, since the MGC-MG information flow would differ from one > architecture to the next. One question: unless the MG is itself the edge > router, won't the ToS be ignored when the media packets reach the latter? > > -----Original Message----- > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com] > Sent: Monday, May 07, 2001 5:14 PM > To: 'megaco(a)fore.com' > Subject: IP Type of Service > > All > > In MGCP, MGC can specify IP Type of Service to the MG. > Do we have an equivalent in Megaco? > > Is there or has anyone defined a package for IP Type of Service? > > Thanks > Chuong > > -- > > Alcatel USA, Inc Internet: Chuong.Nguyen(a)usa.alcatel.com > > 1000 Coit Road Plano, Texas 75075 Phone: (972) 519-4613 > > **** The opinions expressed are not those of Alcatel USA, Inc **** > > ------------------------------------------------------------------------ > Name: att1.htm > att1.htm Type: Hypertext Markup Language (text/html) > Encoding: base64

2 1

Info
by sudha＠HSS.HNS.COM 10 May '01

10 May '01

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

H.GEF.1 Upload
by Pete Cordell 10 May '01

10 May '01

Dear All, I have uploaded a draft on H.GEF.1 (Guidelines for the Use of the Generic Extensible Framework) to the PictureTel Incoming directory. Unfortunately I've lost the email describing what the formal submission procedure is, so if one of the rapporteurs could help me out on that it would be appreciated. ----------- Summary This Recommendation gives guidelines on how to use the "Generic extensibility Framework" specified in H.323v4. It describes when to use the framework, and how to specify features using the framework. It also gives examples on how the GEF negotiation scheme works. ----------- There are a couple of items worth debating, the main one being... - I have defined a syntax way of defining GEF modules. Opinion is sought on whether this stays in the document. Regards, Pete. ============================================= Pete Cordell Tech-Know-Ware pete(a)tech-know-ware.com +44 1473 635863 ============================================= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

RTCP support in H.323
by Rex Coldren 09 May '01

09 May '01

All, I'll be lazy and ask rather than looking through the ASN.1 to find it... Is there support in H.323 for signaling to use RTCP? There is a current thread on the IETF AVT e-mail reflector where talk is of making RTCP mandatory (i.e.-changing it from a SHOULD to a MUST in the RTP specification). The last I heard was that the MUST would apply to implementing RTCP, and not necessarily to using it. Presumably the application level call signaling protocol can be responsible for signaling whether RTCP was to be used. If an endpoint implemented RTCP it should at least benignly ignore received RTCP reports and would not need to send any. So a given operator could specify that RTCP not be signaled if it were not practical in their network. Obvious examples would be wireless networks and cable networks where there are access bandwidth constraints. Cheers, Rex

2 1

Re: IP Type of Service
by Michael Brown 09 May '01

09 May '01

There are at least four contributions to the upcoming Study Group 11 meeting (May 14-May 25)related to this topic. If you have ITU TIES access, they are under Delayed Contributions 207, 212, 214, and 215. -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ericsson.com] Sent: Wednesday, May 09, 2001 1:41 AM To: Petros N. Mouchtaris Cc: Rosen, Brian; megaco; SG16; Oskar vanDeventer Subject: Re: IP Type of Service I think that any work on QoS parameters should be aligned with the work occuring in ETSI Tiphon, ITU SG16, ITU SG11 etc. There's been a considerable amount of effort in trying to come up with common parameters for QoS. Any solution should tap into this. Cheers, Christian "Petros N. Mouchtaris" wrote: > > Brian, > > Actually there was a long discussion on this topic last year on the mailing > list i.e. whether MGC should be able to signal an MG which TOS bit to use. > The whole topic ended up being dropped. Check the archive for e-mails with > title "MG and DiffServ". > > By the way, Flemming had volunteered to do some work but I assume it didn't > have high enough priority. > > Excerpt from e-mail: > > "Tom-PT Taylor wrote: > > > You are correct that packages should be drawn up (and/or SDP defined) to > > allow QOS parameter setting. Volunteers? > > Sure - I can put a package proposal together. > > -- Flemming > > Petros > > "Rosen, Brian" <Brian.Rosen(a)marconi.com> on 05/08/2001 03:29:44 PM > > To: "'Tom-PT Taylor'" <taylor(a)nortelnetworks.com>, "'Madhu Babu > Brahmanapally'" <madhubabu(a)kenetec.com>, "Rosen, Brian" > <Brian.Rosen(a)marconi.com>, "'Chuong Nguyen'" > <Chuong.Nguyen(a)usa.alcatel.com>, megaco <megaco(a)fore.com> > cc: (bcc: Petros N. Mouchtaris/Telcordia) > Subject: RE: IP Type of Service > > I'll look into this. I agree. > > Brian > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: Tuesday, May 08, 2001 10:07 AM > To: 'Madhu Babu Brahmanapally'; 'Rosen, Brian'; 'Chuong Nguyen'; megaco > Subject: RE: IP Type of Service > > That makes sense. > > -----Original Message----- > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] > Sent: Tuesday, May 08, 2001 10:08 AM > To: 'Rosen, Brian'; Taylor, Tom-PT [NORSE:B881:EXCH]; 'Chuong Nguyen'; > megaco > Subject: RE: IP Type of Service > > Hi All, > Another suggestion. Why cant the SDP be extended to incorporate a TOS > parameter/attribute so that all the protocols(SIP,Megaco,MGCP) that use SDP > need not define extra properties/parameter for supporting this. > > Regards > Madhubabu > > -----Original Message----- > From: owner-megaco(a)pit.comms.marconi.com > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian > Sent: Tuesday, May 08, 2001 9:24 AM > To: 'Madhu Babu Brahmanapally'; 'Tom-PT Taylor'; 'Chuong Nguyen'; > megaco(a)fore.com > Subject: RE: IP Type of Service > > I don't agree. The TOS for a particular stream should be set on that > stream, not > on the MG as a whole. For example, if I have a multimedia MG, I will want > to set > the priority of voice higher than video, and video higher than normal. If > I > implement a > Multilevel Pre-emption and Priority scheme, some calls will have higher > priority than > others. The TOS/frame priority has to be per stream. > > Brian > > -----Original Message----- > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] > Sent: Tuesday, May 08, 2001 9:24 AM > To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Chuong Nguyen'; megaco(a)fore.com > Subject: RE: IP Type of Service > > Hi All, > > The default TOS type should be defined on the ROOT termination for the > default TOS used for all media packets generated from the MG. There should > be a method (might be through some property) of specifying stream level TOS > bits. > > I'm interested to work on RSVP. > > Regards > Madhubabu > > -----Original Message----- > From: owner-megaco(a)pit.comms.marconi.com > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian > Sent: Tuesday, May 08, 2001 8:10 AM > To: 'Tom-PT Taylor'; 'Chuong Nguyen'; 'megaco(a)fore.com' > Subject: RE: IP Type of Service > > TOS should not be ignored at the edge router if the router is configured to > enable DiffServ. > > It would be pretty simple to create one package that had the appropriate > controls for > DiffServ and 802.1p. RSVP needs it's own package because there is > messaging, > and you at least an event or two > > The former could be an enumeration: QosMarking, that had values None, TOS > and > FramePriority, plus another integer, Value. That would suffice I think, > although you > could conceivably get more clever with DiffServ. > > Shall I write something up along those lines? > > RSVP takes some more work. Any volunteers? > > Brian > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: Monday, May 07, 2001 9:15 PM > To: 'Chuong Nguyen'; 'megaco(a)fore.com' > Subject: RE: IP Type of Service > > No such package has yet been defined. > > Various QOS architectures can be imagined. Each would give rise to its own > package, since the MGC-MG information flow would differ from one > architecture to the next. One question: unless the MG is itself the edge > router, won't the ToS be ignored when the media packets reach the latter? > > -----Original Message----- > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com] > Sent: Monday, May 07, 2001 5:14 PM > To: 'megaco(a)fore.com' > Subject: IP Type of Service > > All > > In MGCP, MGC can specify IP Type of Service to the MG. > Do we have an equivalent in Megaco? > > Is there or has anyone defined a package for IP Type of Service? > > Thanks > Chuong > > -- > > Alcatel USA, Inc Internet: Chuong.Nguyen(a)usa.alcatel.com > > 1000 Coit Road Plano, Texas 75075 Phone: (972) 519-4613 > > **** The opinions expressed are not those of Alcatel USA, Inc **** > > ------------------------------------------------------------------------ > Name: att1.htm > att1.htm Type: Hypertext Markup Language (text/html) > Encoding: base64

1 0

AW: How to get the heel of RAS Message.
by Horvath Ernst 09 May '01

09 May '01

Paul, the user-data field is a container for a "real" Q.931 user-user information element. Since H.225.0 re-defines the User-user IE for its own use, Q.931 user-user information, if present, must be put somewhere else, that's why the user-data field was included in H323-UserInformation. I don't know if it is ever used in practice. Ernst Horvath Siemens AG -----Ursprüngliche Nachricht----- Von: Paul Long [mailto:plong@IPDIALOG.COM] Gesendet am: Dienstag, 08. Mai 2001 17:43 An: ITU-SG16(a)mailbag.cps.INTEL.COM Betreff: Re: How to get the heel of RAS Message. Delphi, 1. I have no idea what the user-data component is used for. 2. I don't know what you mean by "get and set," but RAS does not use Q.931 or UUIEs in its encoding. It uses ASN.1 PER exclusively. I assume by your other question that you are asking what the outer-most encoding is for RAS. With call-signaling, it's Q.931; with RAS, it's ASN.1 PER--RAS uses ASN.1 PER throughout. Paul Long ipDialog, Inc. -----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@mailbag.cps.INTEL.COM]On Behalf Of Delphi Sent: Tuesday, May 08, 2001 1:53 AM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: How to get the heel of RAS Message. Hi, all: I have two problems concerning H.323 ASN.1. 1> H.323 ASN.1 states as follows: >>>>>>>>> H323-UserInformation::=SEQUENCE { ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Latest draft H.245
by OKUBO Sakae 09 May '01

09 May '01

Dear SG16 experts, The following draft by Mr. Mike Nilsson, Editor, is now available for your review toward the Porto Seguro meeting: http://standard.pictel.com/ftp/avc-site/0105_Por/h245wcmp.zip 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 ********************************************************* My contract with TAO finished on 31 March. Please change my e-mail address as above, though okubo(a)giti.or.jp will continue to work for some time. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 3