- sg16-avd - lists.packetizer.com

Re: Registered payload types for G.723.1/G.729
by Hutton, Charles 23 Feb '00

23 Feb '00

I have the same concerns for G.729E. Charles (Chuck) Hutton Strategic Architecture Engineering Wireless Local Technology Group AT&T Wireless Services PO Box 97059 Redmond, WA 98073 (USPS only) 9461 Willows Road Redmond, WA 98052 (FEDEX/UPS) 425-702-2938 Voice 425-702-2518 FAX charles.hutton(a)attws.com > ---------- > From: Frank Derks[SMTP:frank.derks@PHILIPS.COM] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Wednesday, February 23, 2000 8:46 AM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Registered payload types for G.723.1/G.729 > > <<File: FILE0001>> > Tom, > > section 3 of RFC1890 indeed specifies how additional payload types have to > be registered with the IANA. > Table 2 in section 7 specifies the assigned (and unassigned) payload types > at the time of publication of the > RFC (presumably). This table is no longer in line with the table that can > be found at the IANA Web site > (http://www.isi.edu/in-notes/iana/assignments/rtp-parameters) however. > > Since G.729 is not present in either of these tables, it would seem that > somebody will need to undertake > the action to do so. Especially because H.225.0 _does_ specify a payload > type for G.729 and I think it is > desirable that the code that is being used is not assigned (inadvertently) > to some other codec. > > Whose responsibility would it be to do so? ITU-SG16? > > ----------------------------------------------------- > Frank Derks |Tel +31 35 6893238 | > Advanced Development |Fax +31 35 6891030 | > Philips Business Communications|P.O. Box 32 | > |1200 JD Hilversum | > |The Netherlands | > ----------------------------------------------------| > E-mail: mailto:frank.derks@philips.com | > WWW: http://www.sopho.philips.com | > ----------------------------------------------------- > > > > > > taylor@NORTELNETWORKS.COM@SMTP@MAILBAG.INTEL.COM on 23/02/2000 17:24:37 > Please respond to ITU-SG16@MAILBAG.INTEL.COM@SMTP > Sent by: ITU-SG16(a)MAILBAG.INTEL.COM > To: ITU-SG16@MAILBAG.INTEL.COM@SMTP > cc: > Subject: Re: Registered payload types for G.723.1/G.729 > Classification: Restricted > As I understand it (and I'd better be right, because I have to do similar > things for H.248!) the stuff initially defined in the RFC that sets up the > registration process (RFC 1890) does not go into the IANA database -- only > subsequent registrations. > > > -----Original Message----- > > From: Frank Derks [SMTP:frank.derks@PHILIPS.COM] > > Sent: Tuesday, February 22, 2000 10:30 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Registered payload types for G.723.1/G.729 > > > > H.225.0 specifies that the payload types for G.723.1 and G.729 are 4 and > > 18 respectively. > > When I take a look at the registered payload types at the IANA, these > two > > codecs are > > not listed. > > > > Does this mean that the IANA list is not up-to-date or that these codecs > > are not officially > > registered. > > > > Frank > > > > ----------------------------------------------------- > > Frank Derks |Tel +31 35 6893238 | > > Advanced Development |Fax +31 35 6891030 | > > Philips Business Communications|P.O. Box 32 | > > |1200 JD Hilversum | > > |The Netherlands | > > ----------------------------------------------------| > > E-mail: mailto:frank.derks@philips.com | > > WWW: http://www.sopho.philips.com | > > ----------------------------------------------------- > > > >

1 0

H.248 most recent document
by Bilalis Zacharias 23 Feb '00

23 Feb '00

Good morning Glenn. Could you please tell me where can I find the H.248 with the changes of the Geneva meeting? Thanks in advance Best Regards / Mit freundlichen Grüssen Zacharias Bilalis SIEMENS ICN WN CS EK B13 > Schertlinstr. 8 > D-81359 Muenchen > Germany > Tel: + 49 89 722 28391 Fax: + 49 89 722 61243 Mail to: zacharias.bilalis(a)icn.siemens.de

3 2

Re: Please upload the decided/determined/approved texts
by Callaghan, Robert 23 Feb '00

23 Feb '00

Sakae, I have uploaded the decided text for H.450.8 as: H.450.8clean.doc H.450.8red.doc Bob ------------------------------------------------------------------ Robert Callaghan Siemens Information and Communication Networks Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Sakae OKUBO [mailto:sakae.okubo@TIES.ITU.INT] Sent: Friday, February 18, 2000 12:34 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Please upload the decided/determined/approved texts Dear Editors, Could you please upload your documents of decision, determination or approval at the /Incoming of the PictureTel ftp site? Please make an announce through the reflector when you have uploaded your documents. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

Re: [H.323-SIP/Internet] The work has been started
by Orit Levin 23 Feb '00

23 Feb '00

For those who are experiencing problems. Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit(a)radvision.com -----Original Message----- From: Roni Even <Roni_e(a)accord.co.il> To: 'Orit Levin' <orit(a)radvision.com> Date: Wednesday, February 23, 2000 12:11 PM Subject: RE: [H.323-SIP/Internet] The work has been started >Hi Orit, >I have a problem opening the zip file >Regards >Roni > >********************************************** >Roni Even >VP Product Marketing >Accord Networks >Email: roni_e(a)accord.co.il >Tel: +972-3-9251412 >Fax: +972-3-9211571 >*************************************************** > >> -----Original Message----- >> From: Orit Levin [SMTP:orit@RADVISION.COM] >> Sent: Wed, February 23, 2000 7:03 PM >> To: ITU-SG16(a)MAILBAG.INTEL.COM >> Subject: [H.323-SIP/Internet] The work has been started >> >> Hello all! >> I put together the ideas for H.323-Internet Interworking discussion/work >> as the follow up from Geneva meeting. Please, look into the attachments >> and join the discussion. >> Best Regards, >> Orit Levin >> RADVision Inc. >> 575 Corporate Drive Suite 420 >> Mahwah, NJ 07430 >> Tel: 1 201 529 4300 (230) >> Fax: 1 201 529 3516 >> www.radvision.com <http://www.radvision.com> >> orit(a)radvision.com <mailto:orit@radvision.com> << Message: RE: H.323-SIP >> Discussion >> << Message: RE: H.323-SIP Discussion >> << Message: RE: >> H.323-SIP Discusssion >> << Message: Re: H.323-SIP Discussion >> << >> Message: Re: H.323-SIP Discussion >> << File: H323-Internet.zip >> >

1 0

[H.323-SIP/Internet] The work has been started
by Orit Levin 23 Feb '00

23 Feb '00

Hello all! I put together the ideas for H.323-Internet Interworking discussion/work as the follow up from Geneva meeting. Please, look into the attachments and join the discussion. Best Regards, Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit(a)radvision.com

1 0

H.323 Annex K uploaded (RE: Please upload the decided/determined/ approved texts)
by Espen Skjæran (ETO) 23 Feb '00

23 Feb '00

Hi all, The determined H.323 Annex K is now uploaded to ftp://standard.pictel.com/avc-site/Incoming/h323-annexK-determined-000218.d… Please let me know if you have any comments. /Espen -----Original Message----- From: Sakae OKUBO [mailto:sakae.okubo@TIES.ITU.INT] Sent: 18. februar 2000 18:34 To: ITU-SG16(a)mailbag.cps.intel.com Subject: Please upload the decided/determined/approved texts Dear Editors, Could you please upload your documents of decision, determination or approval at the /Incoming of the PictureTel ftp site? Please make an announce through the reflector when you have uploaded your documents. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

Re: Registered payload types for G.723.1/G.729
by Tom-PT Taylor 23 Feb '00

23 Feb '00

As I understand it (and I'd better be right, because I have to do similar things for H.248!) the stuff initially defined in the RFC that sets up the registration process (RFC 1890) does not go into the IANA database -- only subsequent registrations. > -----Original Message----- > From: Frank Derks [SMTP:frank.derks@PHILIPS.COM] > Sent: Tuesday, February 22, 2000 10:30 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Registered payload types for G.723.1/G.729 > > H.225.0 specifies that the payload types for G.723.1 and G.729 are 4 and > 18 respectively. > When I take a look at the registered payload types at the IANA, these two > codecs are > not listed. > > Does this mean that the IANA list is not up-to-date or that these codecs > are not officially > registered. > > Frank > > ----------------------------------------------------- > Frank Derks |Tel +31 35 6893238 | > Advanced Development |Fax +31 35 6891030 | > Philips Business Communications|P.O. Box 32 | > |1200 JD Hilversum | > |The Netherlands | > ----------------------------------------------------| > E-mail: mailto:frank.derks@philips.com | > WWW: http://www.sopho.philips.com | > -----------------------------------------------------

1 0

RE: H.323-SIP Discussion
by Roy, Radhika R, ALARC 23 Feb '00

23 Feb '00

Hi, Steve and All: I am enclosing the draft that Orit sends to us. Also, I guess that Joon will proceed for requesting BOF in the IETF for this work. Please send an email like Steve to all of us regarding the date, time, and agenda of the meeting. I am also delighted to see Frank Audet's comments. Let all of us comment on the document. Best regards, Radhika <<H323-Internet_RADvision.doc>> > -----Original Message----- > From: Stephen Terrill [SMTP:stephen.terrill@ericsson.com] > Sent: Wednesday, February 23, 2000 6:30 AM > To: Roy, Radhika R, ALARC > Cc: Orit Levin; Tom-PT Taylor; martinze(a)cig.mot.com; > ranga.dendi(a)wcom.com; joon_maeng(a)vtel.com; Francois Audet; Dave Walker; > Paul E. Jones; schulzrinne(a)cs.columbia.edu; bahman.mobasser(a)alcatel.fr; > jo(a)teles.com > Subject: Re: H.323-SIP Discussion > > Hi Roy, > > Hi Roy, > > The 3/1 or 3/2 would be best, and the time is OK (17 - 19 C european > time). > > I would like to see the proposed agenda, and I would like to see that it > coveres the latest in the IETF thoughts as well. I think that it is > benificial if we can agree on the network scenarios which we are to > concentrate on, and the service set. > > Thanks, > > ..//Steve > > "Roy, Radhika R, ALARC" wrote: > > > Hi, Orit and Joon: > > > > I am glad that we got the views of Joon. We all had long conversations > > before, during, and after the SG16 meeting. > > > > If needed, we may also arrange a conference call among ourselves. > Propose > > time can be 11 AM - 1 PM EST USA and probable dates are 2/24, 3/1, 3/2, > > 3/3. I will arrange the conf bridge if we all agree to have a conf call. > Pl. > > let me know. > > > > Best regards, > > Radhika > > > > -----Original Message----- > > From: Joon Maeng [SMTP:joon_maeng@vtel.com] > > Sent: Tuesday, February 22, 2000 5:13 PM > > To: 'Orit Levin'; Tom-PT Taylor; Roy, Radhika R, ALARC; > > martinze(a)cig.mot.com; ranga.dendi(a)wcom.com; Francois Audet; Dave Walker; > > Paul E. Jones > > Subject: RE: H.323-SIP Discussion > > > > Hi Orit. You document seems to be a very good starting point. Before we > > start making any comments to your document, I'd like to see if we can > agree > > on what we are going to work on. I am talking about defining the scope > based > > on the requirements. I am sure my interest is different form others. > Can we > > insert the scope section in you document and discuss what we are going > to > > work on (in the first phase and so on..) before we get into details? > The > > scope will help us in building the consensus quickly. Cheers. > > Regards, > > Joon > > > > > -----Original Message----- > > > From: Roy, Radhika R, ALARC > > > Sent: Tuesday, February 22, 2000 5:00 PM > > > To: 'Orit Levin'; Tom-PT Taylor; martinze(a)cig.mot.com; > > > ranga.dendi(a)wcom.com; joon_maeng(a)vtel.com; Francois Audet; Dave > Walker; > > > Paul E. Jones; 'schulzrinne(a)cs.columbia.edu'; > > > 'bahman.mobasser(a)alcatel.fr'; 'stephen.terrill(a)ericsson.com'; > > > 'jo(a)teles.com' > > > Subject: RE: H.323-SIP Discussion > > > > > > Hi, Orit: > > > > > > You are just right on time. I appreciate this. > > > > > > Please provide me couple of days (may be 2 more days). I would also > like > > > to include Henning S., Bahman M, Stephen T. and others in this mail. > > > > > > My understanding is that you are willing to work as an editor of this > work > > > in the SG16. > > > > > > Henning, just to let you know that SG16 has taken this as a work item. > > > > > > Going forward, we would also like to take this issue to the IETF to > open a > > > work item there as well. Tom indicated that Scott B. likes to see that > > > there is enough support for this work item in the IETF before he > considers > > > whether it is worthwhile to open a new WG or to be a part of another > WG. > > > Tom might elaborate on this. > > > > > > I plan to attend the next IETF meeting in March'00. If we all plan to > go > > > there, we may push for this work in the IETF as well. > > > > > > I would request that all of us provide comments on this. If needed, we > all > > > may be the co-author of this document to show that we have a wide > support > > > for this paper. > > > > > > By the way, the next Q.13-14/16 Rapporteur meeting to be held in > OSAKA, > > > Japan (May 15-19) and any company can be the co-author of this > document > > > irrespective of the country of origin. Even Henning can also join in > this > > > contribution although Columbia University is not a member of the ITU-T > > > because a Rap. can allow anyone to participate in the meeting. > > > > > > Let us start this with a great cooperative mode. > > > > > > Best regards, > > > Radhika R. Roy > > > AT&T > > > +1 732 420 1580 > > > rrroy(a)att.com > > > > > > -----Original Message----- > > > From: Orit Levin [SMTP:orit@radvision.com] > > > Sent: Tuesday, February 22, 2000 4:17 PM > > > To: Tom-PT Taylor; Roy, Radhika R, ALARC; > martinze(a)cig.mot.com; > > > ranga.dendi(a)wcom.com; joon_maeng(a)vtel.com; Francois Audet; Dave > Walker; > > > Paul E. Jones > > > Subject: H.323-SIP Discusssion > > > > > > Hello all! > > > I put together the ideas for H.323-Internet Interworking > > > discussion/work as the first follow up from Geneva meeting. Please, > look > > > into it, comment, provide ideas and additional topics of your > interest. > > > Feel free to forward it to whom I forgot... The only reason, I am NOT > > > putting this on the SG16 mailing list, I wouldn't like to create waves > > > outside H.323 community before we have an understanding on the agenda > in > > > general. After the first round of remarks, I would like to send it to > SG16 > > > mailing list. > > > Regards, > > > Orit Levin > > > RADVision Inc. > > > 575 Corporate Drive Suite 420 > > > Mahwah, NJ 07430 > > > Tel: 1 201 529 4300 (230) > > > Fax: 1 201 529 3516 > > > www.radvision.com <http://www.radvision.com> > > > orit(a)radvision.com <mailto:orit@radvision.com> << File: > > > H323-Internet.zip >>

2 1

Re: [H.323Mobility:]
by Roy, Radhika R, ALARC 23 Feb '00

23 Feb '00

Hi, Paul and Jaakko: Many thanks for the information. Paul Guram: Please provide a well thought convention for the document number. For example, MTD.xxx would be given to diiferentiate from the reqular TDs. One request to you: Once a numbering convention is used, please try to stick to that rule (if we change the rule in the middle, it creates confusions as it happened last time). Best regards, Radhika R. Roy AT&T > -----Original Message----- > From: Jaakko Sundquist [SMTP:jaakko.sundquist@NOKIA.COM] > Sent: Wednesday, February 23, 2000 9:01 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323Mobility:] > > Hi Radhika et al, > > There seems to be a subdirectory in the pictel-site for mobility. The URL > is: ftp://standard.pictel.com/avc-site/Mobility-adhoc/ . I suggest that we > will put our contributions there. It would be nice to have some naming > convention (such as the MTD-xxx scheme) for the documents. Maybe Paul > should > assign these numbers as he is now the moderator for the teleconferences... > > - Jaakko Sundquist > > -----Original Message----- > From: EXT Roy, Radhika R, ALARC [mailto:rrroy@att.com] > Sent: Wednesday, February 23, 2000 3:34 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: [H.323Mobility:] > > Hi, Jaakko: > > I agree with your reply that was also reflected in my > earlier email. > > I have a question to you and Paul Guram: Have you guys > decided where the > incoming contributions for the Ad Hoc group to be sent and > where the URL > would be for accessing to that website? If it is so, > please > let all of us > know soon. > > Paul Guram: Are you close to decide the meeting date and > time as well? > > Best regards, > Radhika R. Roy > > > > -----Original Message----- > > From: Jaakko Sundquist [SMTP:jaakko.sundquist@NOKIA.COM] > > Sent: Wednesday, February 23, 2000 3:37 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: [H.323Mobility:] > > > > Hi all, > > > > I'm sending here the documents related to H.323 Annex H > that were > > accomplished in the Geneva meeting by the ad hoc > mobility > group. Included > > are the draft Annex H, the Terms of Reference for it as > well as the > > meeting > > minutes (quite short) of the ad hoc group meetings in > Geneva. > > > > As Mr. Tran pointed out the location area had been left > to > the VLF-section > > of the draft annex. This is my mistake and I apologize > for > any confusion > > it > > has created. I did not, however, take it off from the > document I am > > sending > > here, this is the document that was produced as a TD in > Geneva, but I will > > remove the location area from the subsequent versions of > the draft annex. > > As for the TMSI, etc. concepts, in my view it is quite > unnecessary to > > argue > > about these, the TMSI is already included in the > proposed > new alias > > address > > type: UIM. Many of these concepts are, as I understand, > already needed in > > H.246 Annex E, which addresses one scenario of the > mobility problem. I > > would > > see the VLR functionality of the H.246 Annex E IWF as > really the VLF we > > have > > defined as a new mobility functional entity, thus the > identifiers TMSI, > > etc. > > would be needed in the VLF at least in some cases. > However, it might be > > suitable to indicate that all of the identifiers > mentioned > in the VLF (and > > other) section(s) are not mandatory. > > > > <<GenevaMobility.zip>> > > > > - Jaakko Sundquist > > ------------------------------------------------------- > > In a hole in the ground there lived a hobbit. > > Not a nasty, dirty, wet hole, filled with the ends of > > worms and an oozy smell, nor yet a dry, bare, > > sandy hole with nothing in it to sit down on or to eat: > > it was a hobbit-hole, and that means comfort. > > ------------------------------------------------------- > << > File: > > GenevaMobility.zip >>

1 0

Re: [H.323Mobility:]
by Jaakko Sundquist 23 Feb '00

23 Feb '00

Hi Radhika et al, There seems to be a subdirectory in the pictel-site for mobility. The URL is: ftp://standard.pictel.com/avc-site/Mobility-adhoc/ . I suggest that we will put our contributions there. It would be nice to have some naming convention (such as the MTD-xxx scheme) for the documents. Maybe Paul should assign these numbers as he is now the moderator for the teleconferences... - Jaakko Sundquist -----Original Message----- From: EXT Roy, Radhika R, ALARC [mailto:rrroy@att.com] Sent: Wednesday, February 23, 2000 3:34 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: [H.323Mobility:] Hi, Jaakko: I agree with your reply that was also reflected in my earlier email. I have a question to you and Paul Guram: Have you guys decided where the incoming contributions for the Ad Hoc group to be sent and where the URL would be for accessing to that website? If it is so, please let all of us know soon. Paul Guram: Are you close to decide the meeting date and time as well? Best regards, Radhika R. Roy > -----Original Message----- > From: Jaakko Sundquist [SMTP:jaakko.sundquist@NOKIA.COM] > Sent: Wednesday, February 23, 2000 3:37 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: [H.323Mobility:] > > Hi all, > > I'm sending here the documents related to H.323 Annex H that were > accomplished in the Geneva meeting by the ad hoc mobility group. Included > are the draft Annex H, the Terms of Reference for it as well as the > meeting > minutes (quite short) of the ad hoc group meetings in Geneva. > > As Mr. Tran pointed out the location area had been left to the VLF-section > of the draft annex. This is my mistake and I apologize for any confusion > it > has created. I did not, however, take it off from the document I am > sending > here, this is the document that was produced as a TD in Geneva, but I will > remove the location area from the subsequent versions of the draft annex. > As for the TMSI, etc. concepts, in my view it is quite unnecessary to > argue > about these, the TMSI is already included in the proposed new alias > address > type: UIM. Many of these concepts are, as I understand, already needed in > H.246 Annex E, which addresses one scenario of the mobility problem. I > would > see the VLR functionality of the H.246 Annex E IWF as really the VLF we > have > defined as a new mobility functional entity, thus the identifiers TMSI, > etc. > would be needed in the VLF at least in some cases. However, it might be > suitable to indicate that all of the identifiers mentioned in the VLF (and > other) section(s) are not mandatory. > > <<GenevaMobility.zip>> > > - Jaakko Sundquist > ------------------------------------------------------- > In a hole in the ground there lived a hobbit. > Not a nasty, dirty, wet hole, filled with the ends of > worms and an oozy smell, nor yet a dry, bare, > sandy hole with nothing in it to sit down on or to eat: > it was a hobbit-hole, and that means comfort. > ------------------------------------------------------- << File: > GenevaMobility.zip >>

1 0

Re: H.248 most recent document
by John Segers 23 Feb '00

23 Feb '00

Zacharias, Today I saw this email message on the megaco list. The Megaco248v15tov16diff.doc can presumably be found on Nortel's site (ftp://standards.nortelnetworks.com/megaco/) John Segers -- John Segers email: jsegers(a)lucent.com Lucent Technologies Room HE 306 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954

1 0

Re: [H.323Mobility:]
by Roy, Radhika R, ALARC 23 Feb '00

23 Feb '00

Hi, Jaakko: I agree with your reply that was also reflected in my earlier email. I have a question to you and Paul Guram: Have you guys decided where the incoming contributions for the Ad Hoc group to be sent and where the URL would be for accessing to that website? If it is so, please let all of us know soon. Paul Guram: Are you close to decide the meeting date and time as well? Best regards, Radhika R. Roy > -----Original Message----- > From: Jaakko Sundquist [SMTP:jaakko.sundquist@NOKIA.COM] > Sent: Wednesday, February 23, 2000 3:37 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: [H.323Mobility:] > > Hi all, > > I'm sending here the documents related to H.323 Annex H that were > accomplished in the Geneva meeting by the ad hoc mobility group. Included > are the draft Annex H, the Terms of Reference for it as well as the > meeting > minutes (quite short) of the ad hoc group meetings in Geneva. > > As Mr. Tran pointed out the location area had been left to the VLF-section > of the draft annex. This is my mistake and I apologize for any confusion > it > has created. I did not, however, take it off from the document I am > sending > here, this is the document that was produced as a TD in Geneva, but I will > remove the location area from the subsequent versions of the draft annex. > As for the TMSI, etc. concepts, in my view it is quite unnecessary to > argue > about these, the TMSI is already included in the proposed new alias > address > type: UIM. Many of these concepts are, as I understand, already needed in > H.246 Annex E, which addresses one scenario of the mobility problem. I > would > see the VLR functionality of the H.246 Annex E IWF as really the VLF we > have > defined as a new mobility functional entity, thus the identifiers TMSI, > etc. > would be needed in the VLF at least in some cases. However, it might be > suitable to indicate that all of the identifiers mentioned in the VLF (and > other) section(s) are not mandatory. > > <<GenevaMobility.zip>> > > - Jaakko Sundquist > ------------------------------------------------------- > In a hole in the ground there lived a hobbit. > Not a nasty, dirty, wet hole, filled with the ends of > worms and an oozy smell, nor yet a dry, bare, > sandy hole with nothing in it to sit down on or to eat: > it was a hobbit-hole, and that means comfort. > ------------------------------------------------------- << File: > GenevaMobility.zip >>

1 0

RE: H.323-SIP Discussion
by Roy, Radhika R, ALARC 23 Feb '00

23 Feb '00

Hi, Orit and Joon: I am glad that we got the views of Joon. We all had long conversations before, during, and after the SG16 meeting. If needed, we may also arrange a conference call among ourselves. Propose time can be 11 AM - 1 PM EST USA and probable dates are 2/24, 3/1, 3/2, 3/3. I will arrange the conf bridge if we all agree to have a conf call. Pl. let me know. Best regards, Radhika -----Original Message----- From: Joon Maeng [SMTP:joon_maeng@vtel.com] Sent: Tuesday, February 22, 2000 5:13 PM To: 'Orit Levin'; Tom-PT Taylor; Roy, Radhika R, ALARC; martinze(a)cig.mot.com; ranga.dendi(a)wcom.com; Francois Audet; Dave Walker; Paul E. Jones Subject: RE: H.323-SIP Discussion Hi Orit. You document seems to be a very good starting point. Before we start making any comments to your document, I'd like to see if we can agree on what we are going to work on. I am talking about defining the scope based on the requirements. I am sure my interest is different form others. Can we insert the scope section in you document and discuss what we are going to work on (in the first phase and so on..) before we get into details? The scope will help us in building the consensus quickly. Cheers. Regards, Joon > -----Original Message----- > From: Roy, Radhika R, ALARC > Sent: Tuesday, February 22, 2000 5:00 PM > To: 'Orit Levin'; Tom-PT Taylor; martinze(a)cig.mot.com; > ranga.dendi(a)wcom.com; joon_maeng(a)vtel.com; Francois Audet; Dave Walker; > Paul E. Jones; 'schulzrinne(a)cs.columbia.edu'; > 'bahman.mobasser(a)alcatel.fr'; 'stephen.terrill(a)ericsson.com'; > 'jo(a)teles.com' > Subject: RE: H.323-SIP Discussion > > Hi, Orit: > > You are just right on time. I appreciate this. > > Please provide me couple of days (may be 2 more days). I would also like > to include Henning S., Bahman M, Stephen T. and others in this mail. > > My understanding is that you are willing to work as an editor of this work > in the SG16. > > Henning, just to let you know that SG16 has taken this as a work item. > > Going forward, we would also like to take this issue to the IETF to open a > work item there as well. Tom indicated that Scott B. likes to see that > there is enough support for this work item in the IETF before he considers > whether it is worthwhile to open a new WG or to be a part of another WG. > Tom might elaborate on this. > > I plan to attend the next IETF meeting in March'00. If we all plan to go > there, we may push for this work in the IETF as well. > > I would request that all of us provide comments on this. If needed, we all > may be the co-author of this document to show that we have a wide support > for this paper. > > By the way, the next Q.13-14/16 Rapporteur meeting to be held in OSAKA, > Japan (May 15-19) and any company can be the co-author of this document > irrespective of the country of origin. Even Henning can also join in this > contribution although Columbia University is not a member of the ITU-T > because a Rap. can allow anyone to participate in the meeting. > > Let us start this with a great cooperative mode. > > Best regards, > Radhika R. Roy > AT&T > +1 732 420 1580 > rrroy(a)att.com > > -----Original Message----- > From: Orit Levin [SMTP:orit@radvision.com] > Sent: Tuesday, February 22, 2000 4:17 PM > To: Tom-PT Taylor; Roy, Radhika R, ALARC; martinze(a)cig.mot.com; > ranga.dendi(a)wcom.com; joon_maeng(a)vtel.com; Francois Audet; Dave Walker; > Paul E. Jones > Subject: H.323-SIP Discusssion > > Hello all! > I put together the ideas for H.323-Internet Interworking > discussion/work as the first follow up from Geneva meeting. Please, look > into it, comment, provide ideas and additional topics of your interest. > Feel free to forward it to whom I forgot... The only reason, I am NOT > putting this on the SG16 mailing list, I wouldn't like to create waves > outside H.323 community before we have an understanding on the agenda in > general. After the first round of remarks, I would like to send it to SG16 > mailing list. > Regards, > Orit Levin > RADVision Inc. > 575 Corporate Drive Suite 420 > Mahwah, NJ 07430 > Tel: 1 201 529 4300 (230) > Fax: 1 201 529 3516 > www.radvision.com <http://www.radvision.com> > orit(a)radvision.com <mailto:orit@radvision.com> << File: > H323-Internet.zip >>

2 1

[H.323Mobility:]
by Jaakko Sundquist 23 Feb '00

23 Feb '00

Hi all, I'm sending here the documents related to H.323 Annex H that were accomplished in the Geneva meeting by the ad hoc mobility group. Included are the draft Annex H, the Terms of Reference for it as well as the meeting minutes (quite short) of the ad hoc group meetings in Geneva. As Mr. Tran pointed out the location area had been left to the VLF-section of the draft annex. This is my mistake and I apologize for any confusion it has created. I did not, however, take it off from the document I am sending here, this is the document that was produced as a TD in Geneva, but I will remove the location area from the subsequent versions of the draft annex. As for the TMSI, etc. concepts, in my view it is quite unnecessary to argue about these, the TMSI is already included in the proposed new alias address type: UIM. Many of these concepts are, as I understand, already needed in H.246 Annex E, which addresses one scenario of the mobility problem. I would see the VLR functionality of the H.246 Annex E IWF as really the VLF we have defined as a new mobility functional entity, thus the identifiers TMSI, etc. would be needed in the VLF at least in some cases. However, it might be suitable to indicate that all of the identifiers mentioned in the VLF (and other) section(s) are not mandatory. <<GenevaMobility.zip>> - Jaakko Sundquist ------------------------------------------------------- In a hole in the ground there lived a hobbit. Not a nasty, dirty, wet hole, filled with the ends of worms and an oozy smell, nor yet a dry, bare, sandy hole with nothing in it to sit down on or to eat: it was a hobbit-hole, and that means comfort. -------------------------------------------------------

1 0

RE: H.323-SIP Discusssion
by Francois Audet 22 Feb '00

22 Feb '00

This looks good. I would probably change the term "H.323-Internet" to something else. "Internet" sounds a little vague. On thing that should be mentioned in there is H.245-SDP interworking. In the case of addressing, we might want to avoid having different translations of SIP telephone numbers (E.164) to H.323 publicNumber, URLs, dialledDigits... At the very least, we should explain the meaning. I'm not that interested in mapping from H.450 to SIP. However, the "third party pause and re-routing" procedures would be a good candidate. Then there is in-band tones and anouncements, busy, etc. Also, the role of gk-routed vs. sip proxy server, and direct-routed vs. sip redirection server. Also, we should thing of which versions of SIP and H.323 we should consider. My personal preference would be to only look at the latest (H.323v4). François Audet -----Original Message----- From: Orit Levin [mailto:orit@radvision.com] Sent: Tuesday, February 22, 2000 1:17 PM To: Taylor, Tom-PT [CAR:B904:EXCH]; rrroy; martinze; ranga.dendi; joon_maeng; Audet, Francois [SC9:4K02:EXCH]; Dave Walker; Paul E. Jones Subject: H.323-SIP Discusssion Hello all! I put together the ideas for H.323-Internet Interworking discussion/work as the first follow up from Geneva meeting. Please, look into it, comment, provide ideas and additional topics of your interest. Feel free to forward it to whom I forgot... The only reason, I am NOT putting this on the SG16 mailing list, I wouldn't like to create waves outside H.323 community before we have an understanding on the agenda in general. After the first round of remarks, I would like to send it to SG16 mailing list. Regards, Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com <http://www.radvision.com> orit(a)radvision.com <mailto:orit@radvision.com>

1 0

RE: H.323-SIP Discussion
by Joon Maeng 22 Feb '00

22 Feb '00

Hi Orit. You document seems to be a very good starting point. Before we start making any comments to your document, I'd like to see if we can agree on what we are going to work on. I am talking about defining the scope based on the requirements. I am sure my interest is different form others. Can we insert the scope section in you document and discuss what we are going to work on (in the first phase and so on..) before we get into details? The scope will help us in building the consensus quickly. Cheers. Regards, Joon -----Original Message----- From: Orit Levin [mailto:orit@radvision.com] Sent: Tuesday, February 22, 2000 3:17 PM To: Tom-PT Taylor; rrroy(a)att.com; martinze(a)cig.mot.com; ranga.dendi(a)wcom.com; joon_maeng(a)vtel.com; Francois Audet; Dave Walker; Paul E. Jones Subject: H.323-SIP Discusssion Hello all! I put together the ideas for H.323-Internet Interworking discussion/work as the first follow up from Geneva meeting. Please, look into it, comment, provide ideas and additional topics of your interest. Feel free to forward it to whom I forgot... The only reason, I am NOT putting this on the SG16 mailing list, I wouldn't like to create waves outside H.323 community before we have an understanding on the agenda in general. After the first round of remarks, I would like to send it to SG16 mailing list. Regards, Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com <http://www.radvision.com> orit(a)radvision.com <mailto:orit@radvision.com>

1 0

H.323-SIP Discusssion
by Orit Levin 22 Feb '00

22 Feb '00

Hello all! I put together the ideas for H.323-Internet Interworking discussion/work as the first follow up from Geneva meeting. Please, look into it, comment, provide ideas and additional topics of your interest. Feel free to forward it to whom I forgot... The only reason, I am NOT putting this on the SG16 mailing list, I wouldn't like to create waves outside H.323 community before we have an understanding on the agenda in general. After the first round of remarks, I would like to send it to SG16 mailing list. Regards, Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit(a)radvision.com

1 0

Re: Registered payload types for G.723.1/G.729
by Nancy-M Greene 22 Feb '00

22 Feb '00

Quoting from H.248 Appendix A, middle of the 2nd paragraph: "For example, G.711A-law is called PCMA in the SDP, and is assigned profile 0. G.723 is profile 4, and H263 is profile 34. See also http://www.isi.edu/in-notes/iana/assignments/rtp-parameters " The URL above is supposed to be an up to date list, it has G.723.1 but it does not have info on the G.729 profile. Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > ---------- > From: Frank Derks[SMTP:frank.derks@PHILIPS.COM] > Sent: Tuesday, February 22, 2000 10:30 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Registered payload types for G.723.1/G.729 > > H.225.0 specifies that the payload types for G.723.1 and G.729 are 4 and > 18 respectively. > When I take a look at the registered payload types at the IANA, these two > codecs are > not listed. > > Does this mean that the IANA list is not up-to-date or that these codecs > are not officially > registered. > > Frank > > ----------------------------------------------------- > Frank Derks |Tel +31 35 6893238 | > Advanced Development |Fax +31 35 6891030 | > Philips Business Communications|P.O. Box 32 | > |1200 JD Hilversum | > |The Netherlands | > ----------------------------------------------------| > E-mail: mailto:frank.derks@philips.com | > WWW: http://www.sopho.philips.com | > ----------------------------------------------------- >

1 0

Re: H.323 Annex N draft
by Roy, Radhika R, ALARC 22 Feb '00

22 Feb '00

Hi, Audet: For the existing ATM QOS and RSVP in H.323, there should be the exact mapping (please see TD-57) because exact parameters are known. There should not be any place for ambiguity to provide the backward compatibility as a minimum. Per your suggestion, if needed, we can also extend our mapping in ATM beyond what H.323 Annex C currently does. For DiffServ, the PHB parameters need to be known to provide the mappings. There are possibilities for ambiguity in DiffServ if the parameters are not well defined. For now, PHBs are yet to be defined clearly in the IETF. More importantly, there is no backward compatibility issue in H.323 for DiffServ. I am not worried about this for now. We may keep this as a place holder (please also see TD-57) for our future work. Best regards, Radhika R. Roy AT&T > -----Original Message----- > From: Francois Audet [SMTP:audet@NORTELNETWORKS.COM] > Sent: Tuesday, February 22, 2000 2:35 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 Annex N draft > > > H.323 standard has already defined how the lower network > > layer QOS (e.g., > > RSVP [guaranteed, controlled, best effort], ATM QOS [CBR, > > rt-VBR, nrt-VBR, > > ABR, UBR]). > > > > Now, if we define H.323 application layer QOS only without > > defining the > > mapping, this will not provide backward compatibility to the > > existing H.323 > > standard. > > > > This is the concern. > > > > So, the "scope" should include the "mapping" of the H.323 QOS > > to the lower > > network layer QOS. > > I don't think we can define such a mapping. There are many ways to use > ATM. The one we used in Annex C is based on CBR AAL5. AAL1 or AAL2 could > be candidates. VBR is also something to consider. We alse did single > channel adaptation. We could multiplex. There is no reason why we need to > specify the ATM transport and associated QoS mechanism. > > On the diffserv side, I am also not convinced that there is much to say > since network operators are free to use diffserv in any way they see fit. >

1 0

Re: H.323 Annex N draft
by Roy, Radhika R, ALARC 22 Feb '00

22 Feb '00

Hi, Audet: Yes, I agree. We should take the high level generic table (provided in the last meeting) as a starting point. Now we have to work around such that the parameters expressed in the table can be used to map over the lower network layer in a meaningful way to prove that it works to provide the backward compatibility as a minimum before we go any further. This is definitely a test how good it is to satisfy the requirements. Therefore, we should include "mapping" of the H.323 QOS to the lower network layer in the "scope." Best regards, Radhika R. Roy AT&T > -----Original Message----- > From: Francois Audet [SMTP:audet@NORTELNETWORKS.COM] > Sent: Tuesday, February 22, 2000 2:36 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 Annex N draft > > In any case, we now have a baseline text. > Contributions are welcomed for the next meeting. > > > -----Original Message----- > > From: Roy, Radhika R, ALARC [ <mailto:rrroy@ATT.COM>] > > Sent: Tuesday, February 22, 2000 11:31 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: H.323 Annex N draft > > > > > > Hi, Mike: > > > > The fundamental issue is that we should be able to map the > > H.323 QOS over > > the lower network layer. > > >

1 0

Re: H.323 Annex N draft
by Francois Audet 22 Feb '00

22 Feb '00

In any case, we now have a baseline text. Contributions are welcomed for the next meeting. > -----Original Message----- > From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] > Sent: Tuesday, February 22, 2000 11:31 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 Annex N draft > > > Hi, Mike: > > The fundamental issue is that we should be able to map the > H.323 QOS over > the lower network layer. >

1 0

Re: H.323 Annex N draft
by Francois Audet 22 Feb '00

22 Feb '00

> H.323 standard has already defined how the lower network > layer QOS (e.g., > RSVP [guaranteed, controlled, best effort], ATM QOS [CBR, > rt-VBR, nrt-VBR, > ABR, UBR]). > > Now, if we define H.323 application layer QOS only without > defining the > mapping, this will not provide backward compatibility to the > existing H.323 > standard. > > This is the concern. > > So, the "scope" should include the "mapping" of the H.323 QOS > to the lower > network layer QOS. I don't think we can define such a mapping. There are many ways to use ATM. The one we used in Annex C is based on CBR AAL5. AAL1 or AAL2 could be candidates. VBR is also something to consider. We alse did single channel adaptation. We could multiplex. There is no reason why we need to specify the ATM transport and associated QoS mechanism. On the diffserv side, I am also not convinced that there is much to say since network operators are free to use diffserv in any way they see fit.

1 0

Re: H.323 Annex N draft
by Roy, Radhika R, ALARC 22 Feb '00

22 Feb '00

Hi, Mike: The fundamental issue is that we should be able to map the H.323 QOS over the lower network layer. H.323 standard has already defined how the lower network layer QOS (e.g., RSVP [guaranteed, controlled, best effort], ATM QOS [CBR, rt-VBR, nrt-VBR, ABR, UBR]). Now, if we define H.323 application layer QOS only without defining the mapping, this will not provide backward compatibility to the existing H.323 standard. This is the concern. So, the "scope" should include the "mapping" of the H.323 QOS to the lower network layer QOS. I am not speaking which functional entity (e.g., you are mentioning about the resource manager, etc.) will do the mapping or how the mapping will be implemented within the network by any functional entity. I am urging that contributions should be brought explaining how the H.323 QOS can provide backward compatibility without defining the mapping. So, the simplest solution is that we should include "mapping" as a part of scope. Best regards, Radhika R. Roy AT&T > -----Original Message----- > From: Mike Buckley [SMTP:mikebuckley@ATTMAIL.COM] > Sent: Tuesday, February 22, 2000 1:56 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 Annex N draft > > Hi Radhika, > > I am not sure what your concern is here. > > >Therefore, the scope provided in your edited document does NOT reflect > the > >agreement. > > You areright that the text of the scope was not discussed during the > meeting. > The point was made, however, in discussions that Annex N required a scope > statement. I drafted something for discussion based on the documents > presented at the meeting, and off line discussions I had with interested > parties > (included yourself). It is a draft and we can change it. > > >Moreover, the backward compatibility requirement will also mandate the > >mapping of H.323 QOS over RSVP (Guaranteed, Controlled, Best effort) and > >ATM QOS (CBR, rt-VBR, nrt-VBR, ABR, UBR). For example, once an H.323 > >QOS is agreed on end-to-end basis, an endpoint may use RSVP to implement > >the H.323 QOS over the transport network. Therefore, it mandates that > H.323 > >QOS MUST be mapped to provide the backward compatibility. Similar is the > >case for the ATM QOS. > > Radhika, could you clarify what you mean by the backward compatibility > issue? > I don't think anyone is disagreeing that the scheme must be compatible > with the > use of RSVP from the terminal. What specific constraints do you see > imposed > by Appendix II? > > What are the issues with ATM? > > >Hope that this clarify that the H.323 QOS mapping over the transport > network > >is a requirement and the scope MUST reflect this. > > I don't see that you have made a case out for mapping in the H.323 > application. > If application and transport are independent the mapping will take place > in the > Resource Manager in the transport layer and the H.323 mechanisms will be > independent of it. > > However, you are welcome to bring contributions to justify your case in > the > next OSAKA meeting (May'00) and we will definitely discuss it. > > > I am not sure what you are asking me to make a contribution on. The > text as > >it stands reflects the wish of the meeting last week and the discussions > at the > >lunchtime editing meeting. What do you see precluded by the existing > text? > > Mike > > > > > ____________________ Begin Original Message > ___________________________ > Date: Tue Feb 22 08:43:28 -0500 2000 > From: internet!ATT.COM!rrroy (Roy, Radhika R, ALARC) > Subject: Re: H.323 Annex N draft > To: internet!MAILBAG.INTEL.COM!ITU-SG16 > Content-Type: Generic-Text > Content-Length: 7049 > > Hi, Mike: > > Yes, H.323 QOS will operate independent of the transport mechanisms. That > is > why, we all brought contributions in the first palce and all our efforts > have been made to fulfill that goal. Acordingly, we have created new > terminology that is known as H.323 appliction layer QOS. We have define > how > H.323 QOS works indpendent of any transport mechnaims on end-to-end basis. > We have also defined how end-to-end H.323 QOS is signaled vis RAS during > the > pre-call setup time to discover what kind of QOS classes or parameters are > available in a given zone or in different zones with the help of the GKs. > > However, a given H.323 QOS class can be chosen by an endpoint to setup > (Q.931/932) the call. This may also trigger H.245 OLCs to go for the media > for which QOS will be provided to convert the astraction of H.323 QOS to > the > corresponding network layer QOS (where mapping is needed). Mr. Bowen > edited > TD-57 WP2/16 accordingly based on the contributions that were accepted in > the last Red Bank meeting (Oct'99). > > The agreement reached in the last SG16 meeting is as follows [TD-74 (plen) > p-20]: > > D.472(2/16) [Ericsson] - Generic QoS bearer for IP and ATM > > A general method of discussing QoS was presented. This is believed to be > more appropriate to IP than the method of TD57, which was viewed as being > too ATM-centric. Support was expressed for the idea that TD-57 is too > ATM-centric. It was noted that the ATM Forum terminology is used rather > than the ITU-T forum QoS terminology. It was agreed that this > contribution > should be reflected in future versions TD57. > > TD57(2/16) [Rapp.] - QoS Architecture and Supporting Protocol > > It was noted that there appear to be a conflict between point 1(3) from > APC-1705 and xxx accepted at this meeting. > > It was agreed that : > > 1)This is not ready for determination > 2)The H.323 material will go in a new Annex N "QoS in H.323 Systems and > Networks." > 3)It will be determined no earlier than Nov 2000, and more likely in 2001. > 4)Liaisons need to be sent to: > a)IETF > b)TIPHON > c)ATM Forum > d)SG13 > 4)3GPP > 5)3GPP2 > 5)Mr. Bowen will update Annex N to reflect D.472, and it will be attached > to the liaisons. > 6)Mr. Buckley will write the liaison. This liasion will solict specific > input against the draft Annex N. > 7)Going forward, Mr. Buckley will edit Annex N. He is also chair of the > TIPHON QoS working group. > > TD5(2/16) is related. It was noted that this work seems very similar to > the > approach of 3GPP and TIPHON. > > D.451(2/16) reports on QoS work in TIPHON. It covers such advanced > topics > as allocating QoS budget between multiple carriers. > > Therefore, the scope provided in your edited document does NOT reflect the > agreement. > > Moreover, the backward compatibility requirement will also mandate the > mapping of H.323 QOS over RSVP (Guaranteed, Controlled, Best effort) and > ATM > QOS (CBR, rt-VBR, nrt-VBR, ABR, UBR). For example, once an H.323 QOS is > agreed on end-to-end basis, an endpoint may use RSVP to implement the > H.323 > QOS over the transport network. Therefore, it mandates that H.323 QOS MUST > be mapped to provide the backward comapatibility. Similar is the case for > the ATM QOS. > > Hope that this clarify that the H.323 QOS mapping over the transport > network > is a requirement and the scope MUST reflect this. > > However, you are welcome to bring contributions to justify your case in > the > next OSAKA meeting (May'00) and we will definitely discuss it. > > I also plan to provide comments for other part of the document later. > > Best regards, > Radhika R. Roy > > > -----Original Message----- > > From: Mike Buckley [SMTP:mikebuckley@ATTMAIL.COM] > > Sent: Monday, February 21, 2000 8:06 PM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: H.323 Annex N draft > > > > Hi Radhika, > > > > Thanks for your quick comments. > > > > The agreement last week was that the H.323 mechanisms should operate > > independently of transport mechanism. This is included in the > > requirements. So > > all the mechanisms you list are included. > > > > The backward compatibility is an important issue and one we should > discuss > > carefully as to its implications. In principle I agree with you, > backward > > compatibility with existing H.323 mechanisms should be an important > > factor. I > > am not yet sure yet what the implications of this are in the QoS area. > > > > Mike > > > > ____________________ Begin Original Message > > ___________________________ > > Date: Mon Feb 21 17:56:43 -0500 2000 > > From: internet!ATT.COM!rrroy (Roy, Radhika R, ALARC) > > Subject: Re: H.323 Annex N draft > > To: internet!MAILBAG.INTEL.COM!ITU-SG16 > > Content-Type: Text > > Content-Length: 2192 > > > > Hi, Mike and All: > > > > I did not have the time go through the whole document yet. However, a > > quick > > look into the document provides me to point out about the scope as > > follows: > > > > 1. The contributions were provided for mapping of H.323 QOS over the > > network > > layer QOS. For example, IETF's DiffServ, IntServ/RSVP, and MPLS, and ATM > > QOS > > classes: CBR, VBR, rt-VBR, nrt-VRB, and ABR. Those contributions were > > accepted in the last Red Bank (Oct'99) meeting. Accordingly, the then > > editor > > Rich Bowen produced the TD in the last SG16 meeting. > > > > So, the scope of H.323 QOS mapping over the network layer QOS (IP, ATM) > > shall be there. > > > > However, if you have any disagreement over the decision made in the last > > Red > > Bank meeting, please submit a contribution in the upcoming OSAKA meeting > > (May'00), we can discuss. Until the decision is made based on > > contributions, > > the scope of the document shall remain the same as submitted by Mr. Rich > > Bowen. > > > > 2. So far the backward compatibility is concerned, it shall not only > > consider Appendix II, but it shall also consider ATM QOS provided in > H.323 > > Annex C. Accordingly, both backward compatibilities should be included > as > > per norm of the ITU standards. > > > > BTW, if you would keep the text the way I suggested, I would think that > I > > did not have to provide my comments as stated above. > > > > Best regards, > > Radhika R. Roy, AT&T > > > > PS: I am yet to finish reading the whole document. Hope to provide more > > comments later. > > > > > -----Original Message----- > > > From: Mike Buckley [SMTP:mikebuckley@ATTMAIL.COM] > > > Sent: Monday, February 21, 2000 2:31 PM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: H.323 Annex N draft > > > > > > Attached is the first draft of the new Annex N of H.323. This was > > issued > > > at last > > > week's meeting as TD126 of WP2 but the attached version includes some > > > further > > > minor revisions and additions of informational material (in the > > > Appendices) which > > > needs further review in the light of the adoption of the generic QoS > > > bearer > > > descriptor. > > > > > > Comments and contributions welcome. > > > > > > Mike Buckley (editor) > > > mikebuckley(a)44comms.com > > > +44-1457-877718 (T) > > > +44-1457-877721 (F) << File: [No Description] >>

1 0

Re: H.323 Annex N draft
by Mike Buckley 22 Feb '00

22 Feb '00

Hi Radhika, I am not sure what your concern is here. >Therefore, the scope provided in your edited document does NOT reflect the >agreement. You areright that the text of the scope was not discussed during the meeting. The point was made, however, in discussions that Annex N required a scope statement. I drafted something for discussion based on the documents presented at the meeting, and off line discussions I had with interested parties (included yourself). It is a draft and we can change it. >Moreover, the backward compatibility requirement will also mandate the >mapping of H.323 QOS over RSVP (Guaranteed, Controlled, Best effort) and >ATM QOS (CBR, rt-VBR, nrt-VBR, ABR, UBR). For example, once an H.323 >QOS is agreed on end-to-end basis, an endpoint may use RSVP to implement >the H.323 QOS over the transport network. Therefore, it mandates that H.323 >QOS MUST be mapped to provide the backward compatibility. Similar is the >case for the ATM QOS. Radhika, could you clarify what you mean by the backward compatibility issue? I don't think anyone is disagreeing that the scheme must be compatible with the use of RSVP from the terminal. What specific constraints do you see imposed by Appendix II? What are the issues with ATM? >Hope that this clarify that the H.323 QOS mapping over the transport network >is a requirement and the scope MUST reflect this. I don't see that you have made a case out for mapping in the H.323 application. If application and transport are independent the mapping will take place in the Resource Manager in the transport layer and the H.323 mechanisms will be independent of it. However, you are welcome to bring contributions to justify your case in the next OSAKA meeting (May'00) and we will definitely discuss it. > I am not sure what you are asking me to make a contribution on. The text as >it stands reflects the wish of the meeting last week and the discussions at the >lunchtime editing meeting. What do you see precluded by the existing text? Mike ____________________ Begin Original Message ___________________________ Date: Tue Feb 22 08:43:28 -0500 2000 From: internet!ATT.COM!rrroy (Roy, Radhika R, ALARC) Subject: Re: H.323 Annex N draft To: internet!MAILBAG.INTEL.COM!ITU-SG16 Content-Type: Generic-Text Content-Length: 7049 Hi, Mike: Yes, H.323 QOS will operate independent of the transport mechanisms. That is why, we all brought contributions in the first palce and all our efforts have been made to fulfill that goal. Acordingly, we have created new terminology that is known as H.323 appliction layer QOS. We have define how H.323 QOS works indpendent of any transport mechnaims on end-to-end basis. We have also defined how end-to-end H.323 QOS is signaled vis RAS during the pre-call setup time to discover what kind of QOS classes or parameters are available in a given zone or in different zones with the help of the GKs. However, a given H.323 QOS class can be chosen by an endpoint to setup (Q.931/932) the call. This may also trigger H.245 OLCs to go for the media for which QOS will be provided to convert the astraction of H.323 QOS to the corresponding network layer QOS (where mapping is needed). Mr. Bowen edited TD-57 WP2/16 accordingly based on the contributions that were accepted in the last Red Bank meeting (Oct'99). The agreement reached in the last SG16 meeting is as follows [TD-74 (plen) p-20]: D.472(2/16) [Ericsson] - Generic QoS bearer for IP and ATM A general method of discussing QoS was presented. This is believed to be more appropriate to IP than the method of TD57, which was viewed as being too ATM-centric. Support was expressed for the idea that TD-57 is too ATM-centric. It was noted that the ATM Forum terminology is used rather than the ITU-T forum QoS terminology. It was agreed that this contribution should be reflected in future versions TD57. TD57(2/16) [Rapp.] - QoS Architecture and Supporting Protocol It was noted that there appear to be a conflict between point 1(3) from APC-1705 and xxx accepted at this meeting. It was agreed that : 1)This is not ready for determination 2)The H.323 material will go in a new Annex N "QoS in H.323 Systems and Networks." 3)It will be determined no earlier than Nov 2000, and more likely in 2001. 4)Liaisons need to be sent to: a)IETF b)TIPHON c)ATM Forum d)SG13 4)3GPP 5)3GPP2 5)Mr. Bowen will update Annex N to reflect D.472, and it will be attached to the liaisons. 6)Mr. Buckley will write the liaison. This liasion will solict specific input against the draft Annex N. 7)Going forward, Mr. Buckley will edit Annex N. He is also chair of the TIPHON QoS working group. TD5(2/16) is related. It was noted that this work seems very similar to the approach of 3GPP and TIPHON. D.451(2/16) reports on QoS work in TIPHON. It covers such advanced topics as allocating QoS budget between multiple carriers. Therefore, the scope provided in your edited document does NOT reflect the agreement. Moreover, the backward compatibility requirement will also mandate the mapping of H.323 QOS over RSVP (Guaranteed, Controlled, Best effort) and ATM QOS (CBR, rt-VBR, nrt-VBR, ABR, UBR). For example, once an H.323 QOS is agreed on end-to-end basis, an endpoint may use RSVP to implement the H.323 QOS over the transport network. Therefore, it mandates that H.323 QOS MUST be mapped to provide the backward comapatibility. Similar is the case for the ATM QOS. Hope that this clarify that the H.323 QOS mapping over the transport network is a requirement and the scope MUST reflect this. However, you are welcome to bring contributions to justify your case in the next OSAKA meeting (May'00) and we will definitely discuss it. I also plan to provide comments for other part of the document later. Best regards, Radhika R. Roy > -----Original Message----- > From: Mike Buckley [SMTP:mikebuckley@ATTMAIL.COM] > Sent: Monday, February 21, 2000 8:06 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 Annex N draft > > Hi Radhika, > > Thanks for your quick comments. > > The agreement last week was that the H.323 mechanisms should operate > independently of transport mechanism. This is included in the > requirements. So > all the mechanisms you list are included. > > The backward compatibility is an important issue and one we should discuss > carefully as to its implications. In principle I agree with you, backward > compatibility with existing H.323 mechanisms should be an important > factor. I > am not yet sure yet what the implications of this are in the QoS area. > > Mike > > ____________________ Begin Original Message > ___________________________ > Date: Mon Feb 21 17:56:43 -0500 2000 > From: internet!ATT.COM!rrroy (Roy, Radhika R, ALARC) > Subject: Re: H.323 Annex N draft > To: internet!MAILBAG.INTEL.COM!ITU-SG16 > Content-Type: Text > Content-Length: 2192 > > Hi, Mike and All: > > I did not have the time go through the whole document yet. However, a > quick > look into the document provides me to point out about the scope as > follows: > > 1. The contributions were provided for mapping of H.323 QOS over the > network > layer QOS. For example, IETF's DiffServ, IntServ/RSVP, and MPLS, and ATM > QOS > classes: CBR, VBR, rt-VBR, nrt-VRB, and ABR. Those contributions were > accepted in the last Red Bank (Oct'99) meeting. Accordingly, the then > editor > Rich Bowen produced the TD in the last SG16 meeting. > > So, the scope of H.323 QOS mapping over the network layer QOS (IP, ATM) > shall be there. > > However, if you have any disagreement over the decision made in the last > Red > Bank meeting, please submit a contribution in the upcoming OSAKA meeting > (May'00), we can discuss. Until the decision is made based on > contributions, > the scope of the document shall remain the same as submitted by Mr. Rich > Bowen. > > 2. So far the backward compatibility is concerned, it shall not only > consider Appendix II, but it shall also consider ATM QOS provided in H.323 > Annex C. Accordingly, both backward compatibilities should be included as > per norm of the ITU standards. > > BTW, if you would keep the text the way I suggested, I would think that I > did not have to provide my comments as stated above. > > Best regards, > Radhika R. Roy, AT&T > > PS: I am yet to finish reading the whole document. Hope to provide more > comments later. > > > -----Original Message----- > > From: Mike Buckley [SMTP:mikebuckley@ATTMAIL.COM] > > Sent: Monday, February 21, 2000 2:31 PM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: H.323 Annex N draft > > > > Attached is the first draft of the new Annex N of H.323. This was > issued > > at last > > week's meeting as TD126 of WP2 but the attached version includes some > > further > > minor revisions and additions of informational material (in the > > Appendices) which > > needs further review in the light of the adoption of the generic QoS > > bearer > > descriptor. > > > > Comments and contributions welcome. > > > > Mike Buckley (editor) > > mikebuckley(a)44comms.com > > +44-1457-877718 (T) > > +44-1457-877721 (F) << File: [No Description] >>

1 0

H.323 Annex M.1
by Francois Audet 22 Feb '00

22 Feb '00

Annex M.1 "Tunnelling of Q.SIG" has been uploaded in: http://standard.pictel.com/ftp/avc-site/Incoming/h323M1.doc ----- François Audet Tel:+1 408 565 5675 mailto:audet@NortelNetworks.com Nortel Networks Fax:+1 408 565 2375 http://www.NortelNetworks.com

1 0