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

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 11 May '01

11 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