- sg16-avd - lists.packetizer.com

H.248 Implementors Guide
by Terry L Anderson 24 Jan '02

24 Jan '02

I have uploaded a copy of the the Editors TD for H.248 Implementors Guide to the avc-site/Incoming directory as TD_H248IG.zip please ignore the TD_H248IG.doc which failed during upload and so is incomplete. Note that there are likely to be additions to the IG during the meeting in Geneva. -- ------------------------------------------------------------ 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

New ITU-SG16 Mail Server
by Meyer, Greg W 24 Jan '02

24 Jan '02

All: As you may have already noticed, the ITU-SG16 mail list has a new server, echo.jf.intel.com. You may continue to send mail to the old server, mailbag.intel.com, and it will be redirected to the new server. You may also, of course, send mail directly to the new server (itu-sg16(a)echo.jf.intel.com) All mail you receive from the ITU-SG16 will be from the new server so this may affect your email filter properties. The procedures will also continue unchanged. All the properties for LISTSERV have been carried over to the new server. This means that you will continue to confirm any messages that you send to the list. By the way, I appreciate the comments (very positive) from this list for this new procedure. As a side benefit, if you receive a confirmation for a message you didn't send to the list, it indicates that you are infected with an email virus or someone is spoofing your address (so please don't confirm it!). But primarily, the new procedure has provided greater security against viruses and spam for the members of this mail list. If you have any quesitons or comments, please don't hesitate to contact me. Best Regards, Greg Meyer Intel Labs

1 0

H.460.1 text
by Pete Cordell 24 Jan '02

24 Jan '02

Dear All, I have uploaded the following to the Picturetel Incoming directory and submitted it to the TSB: Draft Recommendation H.460.1 - Guidelines for the Use of the Generic Extensible Framework It is much the same text as submitted to the Dublin meeting except for a few editorial changes, mentioning XML as an option for the encoded in raw form, and specifying that the standard identifier of an ITU-T defined module is related to its identity in the H.460.n series of recommendations. All the best, Pete. ============================================= Pete Cordell Tech-Know-Ware pete(a)tech-know-ware.com +44 1473 635863 =============================================

1 0

delayed contributions
by Horvath Ernst 24 Jan '02

24 Jan '02

Dear experts, I uploaded the following two contributions to /Incoming: <delayed draft Recommendation H22x.zip> <QoS monitoring proposal.zip> The first one may also be relevant for tomorrow's Q.5 conference call. Regards, Ernst Horvath

2 1

Re: Report of Q.5 (mobility) phone conference, December 18th, 200 1
by Meyer, Greg W 24 Jan '02

24 Jan '02

Forwarded per Mr. Roy's request (his IT dept is working on the problem). -----Original Message----- From: Roy, Radhika R, ALASO Sent: Thursday, January 24, 2002 9:17 AM To: 'BOUGANT François FTRD/DAC/ISS'; ITU-SG16(a)echo.jf.INTEL.COM Subject: RE: Report of Q.5 (mobility) phone conference, December 18th, 200 1 Hi, Mr. Bougant and All: If I understand your argument, it is this: "an annex of H.225, It would not be possible to make it evolve in order to meet the requirements of multimedia services THAT WOULD NOT BE call related." Now let us examine: What is H.225.0 Annex G protocol that is used among the BEs? Is not a kind of H.225.0 RAS messages that is de-coupled from the H.225.0 Q.931/932 call setup? So, from technical point of view, it is this: H.225.0 Annex G and the proposed H.22x are working in the same space. If we want to deprecate H.225.0 Annex G without enhancing it, only then, we can work for H.22x. The only advantage for H.22x that I see it is non-technical: The mobility group (Q.5) will be able to work independently without going through a process for enhancing of H.225.0 Annex G that is controlled by another group (Q.2). Now, my question to all SG16 members: Do you all want to support H.22x (instead of extending H.225.0 Annex G)? I have made points clearly and adequately. Now I will leave the matter to all other SG16 members to decide. I will keep myself off leaving the decision entirely to other SG16 members. Finally, I like to thank all members for participating in the debate. The bottom line is this: Let us decide H.22x or Enhancement of H.225.0 Annex G for mobility in the upcoming SG16 meeting. Best regards, Radhika R. Roy -----Original Message----- From: BOUGANT François FTRD/DAC/ISS [mailto:francois.bougant@RD.FRANCETELECOM.COM] Sent: Thursday, January 24, 2002 8:15 AM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: Re: Report of Q.5 (mobility) phone conference, December 18th, 200 1 Hi all, I fully agree with the arguments previously expressed by Ernst Orvath for H.22x in the specific context (H.22X being an enhanced version of H.225 annex G v2 draft). So I vote for H.22x. If such this MM protocol becomes a standard as an annex of H.225, It would not be possible to make it evolve in order to meet the requirements of multimedia services THAT WOULD NOT BE call related. This doesn't fit our decision to design a generic MM protocol. This justifies the "documentation" advantage as mentionned by Ernst. Anyway, considering the short time remaining until the plenary meeting, I would suggest to discuss also about the protocol design itself. Cordially François Bougant France Telecom -----Message d'origine----- De : Meyer, Greg W [mailto:greg.w.meyer@INTEL.COM] Envoyé : mercredi 23 janvier 2002 19:21 À : ITU-SG16(a)echo.jf.INTEL.COM Objet : Re: Report of Q.5 (mobility) phone conference, December 18th, 200 1 Forwarded per Mr. Roy's request... -----Original Message----- From: Roy, Radhika R, ALASO [mailto:rrroy@att.com] Sent: Monday, January 21, 2002 6:12 AM To: Horvath Ernst; ITU-SG16(a)echo.jf.INTEL.COM Cc: Meyer, Greg W Subject: RE: Report of Q.5 (mobility) phone conference, December 18th, 200 1 ( Mr. Meyer: I would appreciate if you would kindly forward my message to the SG16 reflector.) Hi, Mr. Ernst: I understand your points. Now the question is: Do we want to kill or deprecate H.225.0 Annex G in the longer term through standardization of H.22x? Let us debate the pros and cons of H.22x from technical point of view (I will withdraw my objections to H.22x if sufficient technical arguments are provided). This is the fundamental debate for all of us in the SG16. So far, I have voted for enhancement of H.225.0 Annex G for mobility (because H.22x differs from H.225.0 Annex G by only 2/3 messages and does not say why it has to be fundamentally different from H.225.0 Annex G.) Best regards, Radhika R. Roy rrroy(a)att.com

1 0

Re: Report of Q.5 (mobility) phone conference, December 18th, 200 1
by BOUGANT François FTRD/DAC/ISS 24 Jan '02

24 Jan '02

Hi all, I fully agree with the arguments previously expressed by Ernst Orvath for H.22x in the specific context (H.22X being an enhanced version of H.225 annex G v2 draft). So I vote for H.22x. If such this MM protocol becomes a standard as an annex of H.225, It would not be possible to make it evolve in order to meet the requirements of multimedia services THAT WOULD NOT BE call related. This doesn't fit our decision to design a generic MM protocol. This justifies the "documentation" advantage as mentionned by Ernst. Anyway, considering the short time remaining until the plenary meeting, I would suggest to discuss also about the protocol design itself. Cordially François Bougant France Telecom -----Message d'origine----- De : Meyer, Greg W [mailto:greg.w.meyer@INTEL.COM] Envoyé : mercredi 23 janvier 2002 19:21 À : ITU-SG16(a)echo.jf.INTEL.COM Objet : Re: Report of Q.5 (mobility) phone conference, December 18th, 200 1 Forwarded per Mr. Roy's request... -----Original Message----- From: Roy, Radhika R, ALASO [mailto:rrroy@att.com] Sent: Monday, January 21, 2002 6:12 AM To: Horvath Ernst; ITU-SG16(a)echo.jf.INTEL.COM Cc: Meyer, Greg W Subject: RE: Report of Q.5 (mobility) phone conference, December 18th, 200 1 ( Mr. Meyer: I would appreciate if you would kindly forward my message to the SG16 reflector.) Hi, Mr. Ernst: I understand your points. Now the question is: Do we want to kill or deprecate H.225.0 Annex G in the longer term through standardization of H.22x? Let us debate the pros and cons of H.22x from technical point of view (I will withdraw my objections to H.22x if sufficient technical arguments are provided). This is the fundamental debate for all of us in the SG16. So far, I have voted for enhancement of H.225.0 Annex G for mobility (because H.22x differs from H.225.0 Annex G by only 2/3 messages and does not say why it has to be fundamentally different from H.225.0 Annex G.) Best regards, Radhika R. Roy rrroy(a)att.com

1 0

delayed contribution "Accepting a ServiceChange (HandOff) from se condary MGC"
by Euchner Martin ICN M SR 3 24 Jan '02

24 Jan '02

On behalf of Mr. Leis, let me announce uploaded delayed contribution from Siemens "Accepting a ServiceChange (HandOff) from secondary MGC"" as service_change_contri.zip in the Incoming directory of the Pictel FTP server. With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 47713 | Siemens AG | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de <mailto:Martin.Euchner@icn.siemens.de> | mailto:martin.euchner@ties.itu.int <mailto:martin.euchner@ties.itu.int> | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/sr/pages/122/122_euchner.htm <http://intranet.icn.siemens.de/marketing/sr/pages/122/122_euchner.htm> | D-81359 Muenchen Internet: http://www.siemens.de/ <http://www.siemens.de/> | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Leis Peter ICM N PG SP ST SN 1 Sent: Thursday, January 24, 2002 9:37 AM To: Euchner Martin ICN M SR 3 Subject: delayed contribution Hi, could you please upload the attached delayed contribution 'Accepting a ServiceChange (HandOff) from secondary MGC' to the PICTEL server and send an email to the reflector Peter Leis -------------------------------------------------- Peter Leis Siemens AG ICM N PG SP ST SN 1 phone +49 89 722 26200 fax +49 89 722 32806 email peter.leis(a)icn.siemens.de -------------------------------------------------- <mailto:peter.leis@icn.siemens.de------------------------------------------- ------->

1 0

3rd Q.5 Teleconference on 25th January 2002
by Euchner Martin ICN M SR 3 24 Jan '02

24 Jan '02

Folks, Tomorrow, we will have our third Q.5 teleconference on mobility jointly with Q.2 and Q.G experts. The conference will take at most 2 hours as shown below. Please submit any temporary documents for consideration as soon as possible and place them in the ftp://140.242.1.131/avc-site/Incoming/Q5conf/ <ftp://140.242.1.131/avc-site/Incoming/Q5conf/> Directory. Please also suggest any topics which you like to have covered: Here is my proposal for the agenda: * H.22x Status and progress * H.MMS.1 Status and progress * H.MMS.0 Status and progress * Resolution of potential overlap between H.22x and H.225.0 annex Gv2 * H.235 Annex G.1 (please see the file "delayed new H.235 AnnexG.1.zip" in the Q5conf directory) * Open issues * Preparation for the Geneva SG meeting * AOB Conference Call Meeting 3: Start: Jan 25, 2002 07:00 Pacific Time End: Jan 25, 2002 09:00 Pacific Time Moderator REDDY, PAUL K US Dial-In Number: 1-877-299-1938 International Dial-In Number: 1-617-801-9666 Passcode: 3708752 With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 47713 | Siemens AG | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de <mailto:Martin.Euchner@icn.siemens.de> | mailto:martin.euchner@ties.itu.int <mailto:martin.euchner@ties.itu.int> | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/sr/pages/122/122_euchner.htm <http://intranet.icn.siemens.de/marketing/sr/pages/122/122_euchner.htm> | D-81359 Muenchen Internet: http://www.siemens.de/ <http://www.siemens.de/> | __________________ | Germany -----------------------------------------------------------------------

1 0

delayed Siemens contributions
by Euchner Martin ICN M SR 3 24 Jan '02

24 Jan '02

Yes it's true. I uploaded yesterday evening two of our delayed contributions to the Incoming directory without announcing them. delayed_AES.zip "Proposal to separate H.235 Annex G security into new Annex G.1 for User/Terminal Security and address Generic Mobility Management Security in another document" delayed_new_H.235_AnnexG.1.zip "Inclusion of the AES encryption algorithm to H.235V3" However, I can't find them anywhere. Thus, I uploaded them again to the Incoming directory. With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 47713 | Siemens AG | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/sr/pages/122/122_euchner.htm | D-81359 Muenchen Internet: http://www.siemens.de/ | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: OKUBO Sakae [mailto:okubo@GITI.WASEDA.AC.JP] Sent: Thursday, January 24, 2002 4:32 AM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: Fwd: Editors TD for H.248 Annex M.ka Dear SG16 experts, At 16:31 -0500 02/01/23, Terry L Anderson wrote: >I have uploaded a copy of the Editors TD for H.248 Annex M.ka >(KeepAlive) to the avc-site/incoming directory as: > >TD_H248AnM.keepAlive.zip This and other three documents have been moved to the /0202_Gen directory. delayed_AES.zip delayed_new_H.235_AnnexG.1.zip TD_H248AnM.keepAlive.zip h.460.4.zip You can download them from: using browser http://standard.pictel.com/ftp/avc-site/0202_Gen using ftp tool ftp://standard.pictel.com/avc-site/0202_Gen 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 *********************************************************

1 0

Re: [jvt-experts] ftp server clogged
by Euchner Martin ICN M SR 3 24 Jan '02

24 Jan '02

For of you having difficulties accessing the clogged PictureTel FTP site with a web browser: Here is a special nice trick (originally figured out by Paul Jones) how to still access the clogged PictureTel FTP site with a web-browser: Use the following URL instead (it works!) ftp://140.242.1.131/avc-site/ With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 47713 | Siemens AG | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/sr/pages/122/122_euchner.htm | D-81359 Muenchen Internet: http://www.siemens.de/ | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: OKUBO Sakae [mailto:okubo@GITI.WASEDA.AC.JP] Sent: Wednesday, January 23, 2002 4:25 AM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: Fwd: [jvt-experts] ftp server clogged Dear Q.D,F,G,2-5/16 experts, Please follow the mentioned guidance for accessing the PictureTel ftp site. 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 ********************************************************* >Subject: [jvt-experts] ftp server clogged >Date: Tue, 22 Jan 2002 17:51:42 -0800 >Thread-Topic: ftp server clogged >Thread-Index: AcGjsIFF/XbIRXXRQL+93YJ7Dh2V0w== >From: "Gary Sullivan" <garysull(a)microsoft.com> >To: <jvt-experts(a)mail.imtc.org> >X-OriginalArrivalTime: 23 Jan 2002 01:51:42.0409 (UTC) >FILETIME=[816D7390:01C1A3B0] >Reply-To: "Gary Sullivan" <garysull(a)microsoft.com> > > >We've had trouble today with the PictureTel ftp server. >Please follow these guidelines when accessing this site >to avoid causing these problems (especially in the next >few days): > >1) When you use the site, log on, do what you need to > do rapidly, and log off. Long pauses keep other > people from using the site and cause timeouts that > leave the server in a bad state. > >2) Don't use an http browser for ftp access. Use a > stand-alone ftp tool instead. The browsers > seem to exhibit behavior that causes difficulties > for the server (like not quitting their sessions). > >3) Turn off any automatic site mirroring programs for > the next few days. Lots of people seem to be > running these things and some of them seem to > be clogging the system. > >I continue to be trying to find a new JVT ftp site >to rectify these problems. > >Best Regards, > >Gary Sullivan >

1 0

Fwd: Uploaded files to Incoming
by OKUBO Sakae 24 Jan '02

24 Jan '02

Dear SG16 experts, They are now available at /0202_Gen of the avc-site. At 16:16 +1100 02/01/24, Christian Groves wrote: >I have placed the following files in the incoming directory. Could you >please move them to the Geneve directory? > >1. [DC-xxx_Annex_L_amm1] Proposed H.248 Annex L Amendment 1 >2. [DC-xxx_Annex_M_1] Comments to H.248 Annex M.1 Audio Server Package >3. [DC-xxx_Annex_M_qac] H.248 Annex M.qac Quality Alert Ceasing Package >4. [DC-xxx_Annex_N] H.248 Annex N SDP H.248 Package Attribute >5. [DC-xxx_Imp_Guide] H.248 Implementors' Guide Additions >6. [DC-xxx_MuxDescription] Clarification of H.248 Mux Descriptor Usage >7. [DC-xxx_Nx64K] Addition of Nx64K Service to the H.248 Mutliplex >descriptor >8. [DC-xxx_Packages_Guide] Packages Guide >9. [DC-xxx_Profile_Pkg] Draft H.248 Annex M.profile Profile Package >10. [DC-xxx_H248v2] Draft H.248v2 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 *********************************************************

1 0

Fwd: Editors TD for H.248 Annex M.ka
by OKUBO Sakae 23 Jan '02

23 Jan '02

Dear SG16 experts, At 16:31 -0500 02/01/23, Terry L Anderson wrote: >I have uploaded a copy of the Editors TD for H.248 Annex M.ka >(KeepAlive) to the avc-site/incoming directory as: > >TD_H248AnM.keepAlive.zip This and other three documents have been moved to the /0202_Gen directory. delayed_AES.zip delayed_new_H.235_AnnexG.1.zip TD_H248AnM.keepAlive.zip h.460.4.zip You can download them from: using browser http://standard.pictel.com/ftp/avc-site/0202_Gen using ftp tool ftp://standard.pictel.com/avc-site/0202_Gen 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 *********************************************************

1 0

Fwd: RE: [jvt-experts] ftp server clogged
by OKUBO Sakae 23 Jan '02

23 Jan '02

Dear Q.D,F,G,2-5/16 experts, I have thankfully received the attached helpful advice from Mr. Paul Long. For downloading documents from the avc-site, please use http access with your browser and ftp access with your ftp tool. 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 ********************************************************* >From: "Paul Long" <plong(a)ipdialog.com> >To: "OKUBO Sakae" <okubo(a)GITI.WASEDA.AC.JP> >Subject: RE: [jvt-experts] ftp server clogged >Date: Wed, 23 Jan 2002 11:03:06 -0600 >X-Priority: 3 (Normal) >Importance: Normal > >You can also use HTTP to download documents. (Note that this is not the >same thing as using FTP via a browser, which is the main cause of all the >problems.) HTTP is the preferred method because it is stateless--you don't >lock people out because there is no HTTP "session." Instead of thenormal >FTP URL, you use an HTTP URL. Replace "ftp:" in the old URL with "http:" >and--this is the part that isn't obvious--insert "/ftp" after the domain >name. Therefore, > >ftp://standard.pictel.com/avc-site/till_0012/0011_Gen/H2250v4-final_010317.… > >is equivalent to > >http://standard.pictel.com/ftp/avc-site/till_0012/0011_Gen/H2250v4-final_01… > >The same is true for directories. > >Paul Long >ipDialog, Inc.

1 0

Editors TD for H.248 Annex M.ka
by Terry L Anderson 23 Jan '02

23 Jan '02

I have uploaded a copy of the Editors TD for H.248 Annex M.ka (KeepAlive) to the avc-site/incoming directory as: TD_H248AnM.keepAlive.zip -- ------------------------------------------------------------ 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

Re: Report of Q.5 (mobility) phone conference, December 18th, 200 1
by Meyer, Greg W 23 Jan '02

23 Jan '02

Forwarded per Mr. Roy's request... -----Original Message----- From: Roy, Radhika R, ALASO [mailto:rrroy@att.com] Sent: Monday, January 21, 2002 6:12 AM To: Horvath Ernst; ITU-SG16(a)echo.jf.INTEL.COM Cc: Meyer, Greg W Subject: RE: Report of Q.5 (mobility) phone conference, December 18th, 200 1 ( Mr. Meyer: I would appreciate if you would kindly forward my message to the SG16 reflector.) Hi, Mr. Ernst: I understand your points. Now the question is: Do we want to kill or deprecate H.225.0 Annex G in the longer term through standardization of H.22x? Let us debate the pros and cons of H.22x from technical point of view (I will withdraw my objections to H.22x if sufficient technical arguments are provided). This is the fundamental debate for all of us in the SG16. So far, I have voted for enhancement of H.225.0 Annex G for mobility (because H.22x differs from H.225.0 Annex G by only 2/3 messages and does not say why it has to be fundamentally different from H.225.0 Annex G.) Best regards, Radhika R. Roy rrroy(a)att.com -----Original Message----- From: Horvath Ernst [mailto:ernst.horvath@SIEMENS.AT] Sent: Monday, January 21, 2002 5:04 AM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: AW: Report of Q.5 (mobility) phone conference, December 18th, 200 1 Mr. Roy, since my company actively promoted the Annex G approach I have no problem with it. But H.22x would NOT be a NEW protocol, it would still be H.225.0 annex G (v2, to be precise) if used between border elements. The only "documentation" advantage of a separate recommendation is that for further applications it may be cleaner to use H.22x than H.225.0 annex G. What we ought to avoid is that a further application specifies nearly the same protocol again from scratch. Regards, Ernst Horvath > -----Ursprüngliche Nachricht----- > Von: Roy, Radhika R, ALASO [ mailto:rrroy@att.com] > Gesendet am: Freitag, 18. Jänner 2002 17:08 > An: Horvath Ernst; ITU-SG16(a)echo.jf.INTEL.COM > Cc: Meyer, Greg W > Betreff: RE: Report of Q.5 (mobility) phone conference, December 18th, > 200 1 > > (I would request Mr. Meyer to send the message to the SG16 > reflector ... and thanks to Mr. Meyer. ) > -------------------------------------------------------------- > ---------- > > Hi, Mr. Ernst and All: > > We have seen all pros and cons of all arguments. > > There are some fundamental problems to develop another NEW > protocol like "H.22x" among the BEs. > > So, my vote will be for "H.225.0 Annex v2" that will include > all mobility features extending H.225.0 Annex G v1. > > Best regards, > > Radhika R. Roy > rrroy(a)att.com > > -----Original Message----- > From: Horvath Ernst [ mailto:ernst.horvath@SIEMENS.AT] > Sent: Friday, January 18, 2002 4:02 AM > To: ITU-SG16(a)echo.jf.INTEL.COM > Subject: AW: Report of Q.5 (mobility) phone conference, > December 18th, 200 1 > > > > We should really try to stop going in circles and come to a > conclusion. > > These are the facts: > > 1) For a full year the procedures described in H.MMS.1 have > been stable; they referred to H.225.0 Annex G, but that was > opposed by some participants in the mobility discussion. This > was one reason why mobility work progressed slower than expected. > > 2) In Dublin we found a compromise which did not change the > technical solution, just the form of presentation and > documentation: the "protocol kernel" should be lifted out of > H.225.0 Annex G and turned into an own recommendation. This > would allow different applications to make use of this > protocol independently and still maintain the protocol in a > single document. One application would be H.225.0 Annex G v2, > another one mobility management. > > 3) The effect on H.MMS.1 is probably minimal, just a change > of reference. > > 4) Contrary to Mr. Roy's statement there is absolutely no > overlap with H.225.0 Annex G since the protocol specification > is removed from Annex G and replaced by a reference to H.22x. > The protocol itself is fully backwards compatible with Annex > G version 1. > > It is now up to the work group to decide how to proceed, > either in the present way with an external protocol > specification in H.22x or in the former way with the protocol > specification integrated in H.225.0 Annex G. In the latter > case Annex G version 2 would have to include some extensions > needed by H.MMS.1 and H.235 Annex G. > > Whatever the decision will be, H.MMS.1 will hardly be > affected. The implications for H.225.0 annex G v2 and H.MMS.0 > would be bigger: both of these documents will either simply > refer to H.22x or contain their own (yet very similar) > protocol specification. > > In any case, we should try our best to finalize H.MMS.1 in > February. This means the protcol must be finalized as well, > whether it's H.22x or H.225.0 Annex G v2. > > Kind Regards, > > Ernst Horvath > Siemens AG > > > > -----Ursprüngliche Nachricht----- > > Von: Meyer, Greg W [ mailto:greg.w.meyer@INTEL.COM] > > Gesendet am: Freitag, 11. Jänner 2002 21:35 > > An: ITU-SG16(a)echo.jf.INTEL.COM > > Betreff: Report of Q.5 (mobility) phone conference, December > > 18th, 200 1 > > > > -----Original Message----- > > From: Roy, Radhika R, ALASO [ mailto:rrroy@att.com] > > Sent: Friday, January 11, 2002 9:02 AM > > To: BOUGANT François FTRD/DAC/ISS; ITU-SG16(a)echo.jf.INTEL.COM > > Cc: Meyer, Greg W > > Subject: RE: Report of Q.5 (mobility) phone conference, > December 18th, > > 200 1 > > > > > > (Mr. Greg Meyer: Kindly forward the mail to the SG16 mailing list.) > > > > Further to my earlier email, I like to add a summary. The > > main reason is > > that H.22x is almost a duplicate set of H.225.0 Annex G > > protocol except few > > parameters related to mobility (what can be done through > > extending H.225.0 > > Annex G). > > > > Please note that we have developed as modular sets that are > > decoupled as > > follows: > > > > H.225.0 RAS - Pre-call setup (among the terminals, GKs, and GWs) > > H.225.0 Q.931 - Call setup (among the terminals, GKs, and GWs) > > H.225.0 Annex G - among the BEs > > H.245 Call/media control (terminals, media-aware GKs, GWs) > > > > The proposed H.22x overlaps completely with H.225.0 Annex G > except few > > mobility related parameters. Here lies the fundamental confusions. > > > > Best regards, > > > > Radhika R. Roy > > rrroy(a)att.com > > > > -----Original Message----- > > From: Roy, Radhika R, ALASO > > Sent: Friday, January 11, 2002 11:42 AM > > To: 'BOUGANT François FTRD/DAC/ISS'; ITU-SG16(a)echo.jf.INTEL.COM > > Cc: 'Meyer, Greg W' > > Subject: RE: Report of Q.5 (mobility) phone conference, > December 18th, > > 200 1 > > > > > > (Mr. Greg Meyer: Kindly forward the mail to the SG16 mailing list.) > > > > Hi, Mr. Francois and All: > > > > The fundamental arguments have been that a protocol is > > defined with its own > > characteristics. For example, H.323 protocol has its own > entities like > > terminals, GKs, BEs, and GWs. Whatever protocol is used by > > these entities > > among themselves is known as H.323 protocol suit: For > > example, H.225.0 Annex > > G among BEs. So, the argument is that whatever protocol is > > used among the > > BEs is known as H..25.0 Annex G. The question is: How can we > > define another > > protocol like H.22x among the same BEs of H.323? Is it not > > contradictory to > > the fundamentals for development of the protocol? Will it > not confuse > > everything? (An analogy: How can we say that let us develop another > > protocol, say, H.ZZZ to be used among terminals, GKs, and GWs > > in addition to > > H.323?) > > > > The solution that we have been discussed among ourselves is > > as follows (I am > > providing a copy): > > > > -------------------------------------------------------------- > > -------------- > > ------------------------------------------- > > 1. We are developing a new protocol where no protocol exists > > and the same > > can used by all applications to solve the mobility related > > problems. For > > example, no protocol exits among BE/AMFE, VLF, HLF, and AuF. > > Here where we > > are defining a new "generic" protocol. This is not specific > > to the H.323 > > protocol. (Whether VLF, HLF, and AuF will be colocated with > > the BE/AMFE is a > > matter of implementation.) > > > > 2. We have the H.225.0 Annex G protocol that allows us to > > communicate among > > the H.323 BEs. This is specific to H.323. All we need to do > > is to extend > > this protocol to serve our purposes. (An analogy can be > > provided. It should > > be done in a way what Paul Reddy has done for H.xxx Annex E.) > > > > 3. We have the H.225.0 (RAS + Q.931) protocol that is used > > among the H.323 > > Terminals, GKs, and GWs. This is specific to H.323. All we > > need to do is to > > extend this protocol to serve our purposes. (An analogy can > > be provided. It > > should be done in a way what Paul Reddy has done for H.xxx > Annex E.) > > > > The questions that I have to you all: Why do you want to > > develop a generic > > protocol (if it is not H.323 specific) for items 2 and 3? If > > you want to do > > so, how do you definite the generic functional entities like > > terminals, GKs, > > BEs, GWs, etc? (Please also note that H.324 and H.310 do > not have the > > concept of functional entities like GKs.) > > > > My assumption has been that the same (items 2 and 3) can also > > be done for > > H.324, H.310, or other protocol while all protocols can use > the same > > "generic" protocol as developed in item 1. > > > > Please also note that if we develop a "generic" protocol for > > items 2 and 3 > > instead of being making protocol-specific extension, we will > > force each > > protocol (H.323, H.324, H.310, etc.) to use the DUPLICATE > > sets of protocols > > (protocol specific + generic) among all its functional > > entities. Is it nor > > wastage of resources? > > > > -------------------------------------------------------------- > > -------------- > > ----------------------------------------- > > > > It is not that we cannot develop many fency things like > H.22x, but it > > contradicts the fundamental goals of the protocol development. > > > > Best regards, > > > > Radhika R. Roy > > rrroy(a)att.com > > > > -----Original Message----- > > From: BOUGANT François FTRD/DAC/ISS > > [ mailto:francois.bougant@RD.FRANCETELECOM.COM] > > Sent: Friday, January 11, 2002 10:32 AM > > To: ITU-SG16(a)echo.jf.INTEL.COM > > Subject: Re: Report of Q.5 (mobility) phone conference, > December 18th, > > 200 1 > > > > > > Dear all, > > > > During the last rapporteur's meeting (Dublin - Ireland), it > > was expressed > > that defining H.22x (designed on the basis of H.225 annex G > v2 at the > > current state - the backward compatibility with H.225 annex G > > v1 would be > > necessary) as a protocol used on BE--BE and BE--{Backend > > service entities} > > interfaces (other interfaces implying GKs could be > > considered) and stopping > > H.225 annex G would be a better way than defining a new > > protocol used on > > BE--{Backend service entities} interfaces and going on H.225 v2. > > > > A significant argument is : in the latter case, the BE would > > support two > > application-layer protocols that may evolve separatly in the > > future. This > > would tend to make BE functionalities harder to implement. > > A second one is : if the H.22x "body" includes the H.225 > > annex G protocol , > > it can be used for information exchange on BE--BE interface > > even in the > > H.323 mobility management context. > > > > To my understanding, H.22X would not contain any functional > > architecture > > description. This would be specifically described in every > > H.MMS.x draft, > > depending on the application context (H.323 specific, etc.). > > To give an > > example, the definition of generic entities would be > > contained in H.MMS.0. > > Specific entities such as GKs would be described in H.MMS.1. > > Then, mobility management implies a limited set of > > information exchanges > > that are independants from the application (although the type > > of exchange > > data depends on the application). These are related to the > > same actions at > > least : user registration/deregistration, location update, > > authentication, > > information update (e.g. user service profile transfer, > > update), location > > information request. So I think it is possible to define a > > "simple" generic > > protocol. > > > > Best regards, > > > > François Bougant > > France Telecom > > > > -----Message d'origine----- > > De : Roy, Radhika R, ALASO [ mailto:rrroy@att.com] > > Envoyé : mercredi 9 janvier 2002 16:16 > > À : BOUGANT François FTRD/DAC/ISS; ITU-SG16(a)echo.jf.INTEL.COM > > Cc : Meyer, Greg W > > Objet : RE: Report of Q.5 (mobility) phone conference, > December 18th, > > 2001 > > > > > > Hi, Mr. Francois and All: > > > > In addition, we also had some email correspondences among the > > conference > > participants and few interested folks including Mr. Jones and > > Mr. Reddy. It > > has been opined that H.22x is NOT needed because the > extensions of the > > existing application-specific protocol (e.g., H.225.0 Annex > > G) for mobility > > will serve the purpose. > > > > Copies of the emails are enclosed below. > > > > Best regards, > > > > Radhika R. Roy > > rrroy(a)att.com > > > > PS: I would highly appreciate if Mr. Greg Meyer would send > > the email to the > > SG16 reflector as you know that I can receive the mail from > > the reflector, > > but cannot send it because of problems in filtering. > > >

1 0

Fwd: [jvt-experts] ftp server clogged
by OKUBO Sakae 22 Jan '02

22 Jan '02

Dear Q.D,F,G,2-5/16 experts, Please follow the mentioned guidance for accessing the PictureTel ftp site. 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 ********************************************************* >Subject: [jvt-experts] ftp server clogged >Date: Tue, 22 Jan 2002 17:51:42 -0800 >Thread-Topic: ftp server clogged >Thread-Index: AcGjsIFF/XbIRXXRQL+93YJ7Dh2V0w== >From: "Gary Sullivan" <garysull(a)microsoft.com> >To: <jvt-experts(a)mail.imtc.org> >X-OriginalArrivalTime: 23 Jan 2002 01:51:42.0409 (UTC) >FILETIME=[816D7390:01C1A3B0] >Reply-To: "Gary Sullivan" <garysull(a)microsoft.com> > > >We've had trouble today with the PictureTel ftp server. >Please follow these guidelines when accessing this site >to avoid causing these problems (especially in the next >few days): > >1) When you use the site, log on, do what you need to > do rapidly, and log off. Long pauses keep other > people from using the site and cause timeouts that > leave the server in a bad state. > >2) Don't use an http browser for ftp access. Use a > stand-alone ftp tool instead. The browsers > seem to exhibit behavior that causes difficulties > for the server (like not quitting their sessions). > >3) Turn off any automatic site mirroring programs for > the next few days. Lots of people seem to be > running these things and some of them seem to > be clogging the system. > >I continue to be trying to find a new JVT ftp site >to rectify these problems. > >Best Regards, > >Gary Sullivan >

1 0

Picturetel site locked up
by Tom-PT Taylor 22 Jan '02

22 Jan '02

I just tried to get into the Picturetel site, but was refused because 50 connections are already active. I expect something needs to be reset, and I believe Patrick Luthi (the posted contact) is gone. Can someone from Polycom look into this? Tom Taylor taylor(a)nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490)

1 0

4 Contributions on H246 Annex C and H225.0
by Ichiro SEKI 21 Jan '02

21 Jan '02

Dear Experts, 4 Delayed Contributions from NTT about some clarifications on H.246 Annex C and the H.225.0 has been uploaded to the following site. http://standard.pictel.com/ftp/avc-site/0202_Gen/ Regards, Ichiro SEKI, NTT Network Service Systems Labs. seki.ichiro(a)lab.ntt.co.jp

1 0

AW: Report of Q.5 (mobility) phone conference, December 18th, 200 1
by Horvath Ernst 21 Jan '02

21 Jan '02

Mr. Roy, since my company actively promoted the Annex G approach I have no problem with it. But H.22x would NOT be a NEW protocol, it would still be H.225.0 annex G (v2, to be precise) if used between border elements. The only "documentation" advantage of a separate recommendation is that for further applications it may be cleaner to use H.22x than H.225.0 annex G. What we ought to avoid is that a further application specifies nearly the same protocol again from scratch. Regards, Ernst Horvath > -----Ursprüngliche Nachricht----- > Von: Roy, Radhika R, ALASO [mailto:rrroy@att.com] > Gesendet am: Freitag, 18. Jänner 2002 17:08 > An: Horvath Ernst; ITU-SG16(a)echo.jf.INTEL.COM > Cc: Meyer, Greg W > Betreff: RE: Report of Q.5 (mobility) phone conference, December 18th, > 200 1 > > (I would request Mr. Meyer to send the message to the SG16 > reflector ... and thanks to Mr. Meyer. ) > -------------------------------------------------------------- > ---------- > > Hi, Mr. Ernst and All: > > We have seen all pros and cons of all arguments. > > There are some fundamental problems to develop another NEW > protocol like "H.22x" among the BEs. > > So, my vote will be for "H.225.0 Annex v2" that will include > all mobility features extending H.225.0 Annex G v1. > > Best regards, > > Radhika R. Roy > rrroy(a)att.com > > -----Original Message----- > From: Horvath Ernst [mailto:ernst.horvath@SIEMENS.AT] > Sent: Friday, January 18, 2002 4:02 AM > To: ITU-SG16(a)echo.jf.INTEL.COM > Subject: AW: Report of Q.5 (mobility) phone conference, > December 18th, 200 1 > > > > We should really try to stop going in circles and come to a > conclusion. > > These are the facts: > > 1) For a full year the procedures described in H.MMS.1 have > been stable; they referred to H.225.0 Annex G, but that was > opposed by some participants in the mobility discussion. This > was one reason why mobility work progressed slower than expected. > > 2) In Dublin we found a compromise which did not change the > technical solution, just the form of presentation and > documentation: the "protocol kernel" should be lifted out of > H.225.0 Annex G and turned into an own recommendation. This > would allow different applications to make use of this > protocol independently and still maintain the protocol in a > single document. One application would be H.225.0 Annex G v2, > another one mobility management. > > 3) The effect on H.MMS.1 is probably minimal, just a change > of reference. > > 4) Contrary to Mr. Roy's statement there is absolutely no > overlap with H.225.0 Annex G since the protocol specification > is removed from Annex G and replaced by a reference to H.22x. > The protocol itself is fully backwards compatible with Annex > G version 1. > > It is now up to the work group to decide how to proceed, > either in the present way with an external protocol > specification in H.22x or in the former way with the protocol > specification integrated in H.225.0 Annex G. In the latter > case Annex G version 2 would have to include some extensions > needed by H.MMS.1 and H.235 Annex G. > > Whatever the decision will be, H.MMS.1 will hardly be > affected. The implications for H.225.0 annex G v2 and H.MMS.0 > would be bigger: both of these documents will either simply > refer to H.22x or contain their own (yet very similar) > protocol specification. > > In any case, we should try our best to finalize H.MMS.1 in > February. This means the protcol must be finalized as well, > whether it's H.22x or H.225.0 Annex G v2. > > Kind Regards, > > Ernst Horvath > Siemens AG > > > > -----Ursprüngliche Nachricht----- > > Von: Meyer, Greg W [ mailto:greg.w.meyer@INTEL.COM] > > Gesendet am: Freitag, 11. Jänner 2002 21:35 > > An: ITU-SG16(a)echo.jf.INTEL.COM > > Betreff: Report of Q.5 (mobility) phone conference, December > > 18th, 200 1 > > > > -----Original Message----- > > From: Roy, Radhika R, ALASO [ mailto:rrroy@att.com] > > Sent: Friday, January 11, 2002 9:02 AM > > To: BOUGANT François FTRD/DAC/ISS; ITU-SG16(a)echo.jf.INTEL.COM > > Cc: Meyer, Greg W > > Subject: RE: Report of Q.5 (mobility) phone conference, > December 18th, > > 200 1 > > > > > > (Mr. Greg Meyer: Kindly forward the mail to the SG16 mailing list.) > > > > Further to my earlier email, I like to add a summary. The > > main reason is > > that H.22x is almost a duplicate set of H.225.0 Annex G > > protocol except few > > parameters related to mobility (what can be done through > > extending H.225.0 > > Annex G). > > > > Please note that we have developed as modular sets that are > > decoupled as > > follows: > > > > H.225.0 RAS - Pre-call setup (among the terminals, GKs, and GWs) > > H.225.0 Q.931 - Call setup (among the terminals, GKs, and GWs) > > H.225.0 Annex G - among the BEs > > H.245 Call/media control (terminals, media-aware GKs, GWs) > > > > The proposed H.22x overlaps completely with H.225.0 Annex G > except few > > mobility related parameters. Here lies the fundamental confusions. > > > > Best regards, > > > > Radhika R. Roy > > rrroy(a)att.com > > > > -----Original Message----- > > From: Roy, Radhika R, ALASO > > Sent: Friday, January 11, 2002 11:42 AM > > To: 'BOUGANT François FTRD/DAC/ISS'; ITU-SG16(a)echo.jf.INTEL.COM > > Cc: 'Meyer, Greg W' > > Subject: RE: Report of Q.5 (mobility) phone conference, > December 18th, > > 200 1 > > > > > > (Mr. Greg Meyer: Kindly forward the mail to the SG16 mailing list.) > > > > Hi, Mr. Francois and All: > > > > The fundamental arguments have been that a protocol is > > defined with its own > > characteristics. For example, H.323 protocol has its own > entities like > > terminals, GKs, BEs, and GWs. Whatever protocol is used by > > these entities > > among themselves is known as H.323 protocol suit: For > > example, H.225.0 Annex > > G among BEs. So, the argument is that whatever protocol is > > used among the > > BEs is known as H..25.0 Annex G. The question is: How can we > > define another > > protocol like H.22x among the same BEs of H.323? Is it not > > contradictory to > > the fundamentals for development of the protocol? Will it > not confuse > > everything? (An analogy: How can we say that let us develop another > > protocol, say, H.ZZZ to be used among terminals, GKs, and GWs > > in addition to > > H.323?) > > > > The solution that we have been discussed among ourselves is > > as follows (I am > > providing a copy): > > > > -------------------------------------------------------------- > > -------------- > > ------------------------------------------- > > 1. We are developing a new protocol where no protocol exists > > and the same > > can used by all applications to solve the mobility related > > problems. For > > example, no protocol exits among BE/AMFE, VLF, HLF, and AuF. > > Here where we > > are defining a new "generic" protocol. This is not specific > > to the H.323 > > protocol. (Whether VLF, HLF, and AuF will be colocated with > > the BE/AMFE is a > > matter of implementation.) > > > > 2. We have the H.225.0 Annex G protocol that allows us to > > communicate among > > the H.323 BEs. This is specific to H.323. All we need to do > > is to extend > > this protocol to serve our purposes. (An analogy can be > > provided. It should > > be done in a way what Paul Reddy has done for H.xxx Annex E.) > > > > 3. We have the H.225.0 (RAS + Q.931) protocol that is used > > among the H.323 > > Terminals, GKs, and GWs. This is specific to H.323. All we > > need to do is to > > extend this protocol to serve our purposes. (An analogy can > > be provided. It > > should be done in a way what Paul Reddy has done for H.xxx > Annex E.) > > > > The questions that I have to you all: Why do you want to > > develop a generic > > protocol (if it is not H.323 specific) for items 2 and 3? If > > you want to do > > so, how do you definite the generic functional entities like > > terminals, GKs, > > BEs, GWs, etc? (Please also note that H.324 and H.310 do > not have the > > concept of functional entities like GKs.) > > > > My assumption has been that the same (items 2 and 3) can also > > be done for > > H.324, H.310, or other protocol while all protocols can use > the same > > "generic" protocol as developed in item 1. > > > > Please also note that if we develop a "generic" protocol for > > items 2 and 3 > > instead of being making protocol-specific extension, we will > > force each > > protocol (H.323, H.324, H.310, etc.) to use the DUPLICATE > > sets of protocols > > (protocol specific + generic) among all its functional > > entities. Is it nor > > wastage of resources? > > > > -------------------------------------------------------------- > > -------------- > > ----------------------------------------- > > > > It is not that we cannot develop many fency things like > H.22x, but it > > contradicts the fundamental goals of the protocol development. > > > > Best regards, > > > > Radhika R. Roy > > rrroy(a)att.com > > > > -----Original Message----- > > From: BOUGANT François FTRD/DAC/ISS > > [ mailto:francois.bougant@RD.FRANCETELECOM.COM] > > Sent: Friday, January 11, 2002 10:32 AM > > To: ITU-SG16(a)echo.jf.INTEL.COM > > Subject: Re: Report of Q.5 (mobility) phone conference, > December 18th, > > 200 1 > > > > > > Dear all, > > > > During the last rapporteur's meeting (Dublin - Ireland), it > > was expressed > > that defining H.22x (designed on the basis of H.225 annex G > v2 at the > > current state - the backward compatibility with H.225 annex G > > v1 would be > > necessary) as a protocol used on BE--BE and BE--{Backend > > service entities} > > interfaces (other interfaces implying GKs could be > > considered) and stopping > > H.225 annex G would be a better way than defining a new > > protocol used on > > BE--{Backend service entities} interfaces and going on H.225 v2. > > > > A significant argument is : in the latter case, the BE would > > support two > > application-layer protocols that may evolve separatly in the > > future. This > > would tend to make BE functionalities harder to implement. > > A second one is : if the H.22x "body" includes the H.225 > > annex G protocol , > > it can be used for information exchange on BE--BE interface > > even in the > > H.323 mobility management context. > > > > To my understanding, H.22X would not contain any functional > > architecture > > description. This would be specifically described in every > > H.MMS.x draft, > > depending on the application context (H.323 specific, etc.). > > To give an > > example, the definition of generic entities would be > > contained in H.MMS.0. > > Specific entities such as GKs would be described in H.MMS.1. > > Then, mobility management implies a limited set of > > information exchanges > > that are independants from the application (although the type > > of exchange > > data depends on the application). These are related to the > > same actions at > > least : user registration/deregistration, location update, > > authentication, > > information update (e.g. user service profile transfer, > > update), location > > information request. So I think it is possible to define a > > "simple" generic > > protocol. > > > > Best regards, > > > > François Bougant > > France Telecom > > > > -----Message d'origine----- > > De : Roy, Radhika R, ALASO [ mailto:rrroy@att.com] > > Envoyé : mercredi 9 janvier 2002 16:16 > > À : BOUGANT François FTRD/DAC/ISS; ITU-SG16(a)echo.jf.INTEL.COM > > Cc : Meyer, Greg W > > Objet : RE: Report of Q.5 (mobility) phone conference, > December 18th, > > 2001 > > > > > > Hi, Mr. Francois and All: > > > > In addition, we also had some email correspondences among the > > conference > > participants and few interested folks including Mr. Jones and > > Mr. Reddy. It > > has been opined that H.22x is NOT needed because the > extensions of the > > existing application-specific protocol (e.g., H.225.0 Annex > > G) for mobility > > will serve the purpose. > > > > Copies of the emails are enclosed below. > > > > Best regards, > > > > Radhika R. Roy > > rrroy(a)att.com > > > > PS: I would highly appreciate if Mr. Greg Meyer would send > > the email to the > > SG16 reflector as you know that I can receive the mail from > > the reflector, > > but cannot send it because of problems in filtering. > > >

1 0

Delayed Contribution from Waseda University
by OKUBO Sakae 18 Jan '02

18 Jan '02

Dear SG16 experts, I have uploaded the following delayed contribution and moved it to http://standard.pictel.com/ftp/avc-site/0202_Gen/ File: Waseda_delayed_020118.zip SOURCE: Waseda University TITLE: Comments on the multiple media stream transmission in H.323 This contribution gives comments on the following three items: - Pairing of RTP streams for a common bi-directional RTCP channel - Indication of the stream content - Multiplexing all media packets into a single port 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 *********************************************************

1 0

Re: Report of Q.5 (mobility) phone conference, December 18th, 200 1
by Meyer, Greg W 18 Jan '02

18 Jan '02

Forwarded per Mr. Roy's request... -----Original Message----- From: Roy, Radhika R, ALASO [mailto:rrroy@att.com] Sent: Friday, January 18, 2002 8:08 AM To: Horvath Ernst; ITU-SG16(a)echo.jf.INTEL.COM Cc: Meyer, Greg W Subject: RE: Report of Q.5 (mobility) phone conference, December 18th, 200 1 (I would request Mr. Meyer to send the message to the SG16 reflector ... and thanks to Mr. Meyer. ) ------------------------------------------------------------------------ Hi, Mr. Ernst and All: We have seen all pros and cons of all arguments. There are some fundamental problems to develop another NEW protocol like "H.22x" among the BEs. So, my vote will be for "H.225.0 Annex v2" that will include all mobility features extending H.225.0 Annex G v1. Best regards, Radhika R. Roy rrroy(a)att.com -----Original Message----- From: Horvath Ernst [mailto:ernst.horvath@SIEMENS.AT] Sent: Friday, January 18, 2002 4:02 AM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: AW: Report of Q.5 (mobility) phone conference, December 18th, 200 1 We should really try to stop going in circles and come to a conclusion. These are the facts: 1) For a full year the procedures described in H.MMS.1 have been stable; they referred to H.225.0 Annex G, but that was opposed by some participants in the mobility discussion. This was one reason why mobility work progressed slower than expected. 2) In Dublin we found a compromise which did not change the technical solution, just the form of presentation and documentation: the "protocol kernel" should be lifted out of H.225.0 Annex G and turned into an own recommendation. This would allow different applications to make use of this protocol independently and still maintain the protocol in a single document. One application would be H.225.0 Annex G v2, another one mobility management. 3) The effect on H.MMS.1 is probably minimal, just a change of reference. 4) Contrary to Mr. Roy's statement there is absolutely no overlap with H.225.0 Annex G since the protocol specification is removed from Annex G and replaced by a reference to H.22x. The protocol itself is fully backwards compatible with Annex G version 1. It is now up to the work group to decide how to proceed, either in the present way with an external protocol specification in H.22x or in the former way with the protocol specification integrated in H.225.0 Annex G. In the latter case Annex G version 2 would have to include some extensions needed by H.MMS.1 and H.235 Annex G. Whatever the decision will be, H.MMS.1 will hardly be affected. The implications for H.225.0 annex G v2 and H.MMS.0 would be bigger: both of these documents will either simply refer to H.22x or contain their own (yet very similar) protocol specification. In any case, we should try our best to finalize H.MMS.1 in February. This means the protcol must be finalized as well, whether it's H.22x or H.225.0 Annex G v2. Kind Regards, Ernst Horvath Siemens AG > -----Ursprüngliche Nachricht----- > Von: Meyer, Greg W [ mailto:greg.w.meyer@INTEL.COM] > Gesendet am: Freitag, 11. Jänner 2002 21:35 > An: ITU-SG16(a)echo.jf.INTEL.COM > Betreff: Report of Q.5 (mobility) phone conference, December > 18th, 200 1 > > -----Original Message----- > From: Roy, Radhika R, ALASO [ mailto:rrroy@att.com] > Sent: Friday, January 11, 2002 9:02 AM > To: BOUGANT François FTRD/DAC/ISS; ITU-SG16(a)echo.jf.INTEL.COM > Cc: Meyer, Greg W > Subject: RE: Report of Q.5 (mobility) phone conference, December 18th, > 200 1 > > > (Mr. Greg Meyer: Kindly forward the mail to the SG16 mailing list.) > > Further to my earlier email, I like to add a summary. The > main reason is > that H.22x is almost a duplicate set of H.225.0 Annex G > protocol except few > parameters related to mobility (what can be done through > extending H.225.0 > Annex G). > > Please note that we have developed as modular sets that are > decoupled as > follows: > > H.225.0 RAS - Pre-call setup (among the terminals, GKs, and GWs) > H.225.0 Q.931 - Call setup (among the terminals, GKs, and GWs) > H.225.0 Annex G - among the BEs > H.245 Call/media control (terminals, media-aware GKs, GWs) > > The proposed H.22x overlaps completely with H.225.0 Annex G except few > mobility related parameters. Here lies the fundamental confusions. > > Best regards, > > Radhika R. Roy > rrroy(a)att.com > > -----Original Message----- > From: Roy, Radhika R, ALASO > Sent: Friday, January 11, 2002 11:42 AM > To: 'BOUGANT François FTRD/DAC/ISS'; ITU-SG16(a)echo.jf.INTEL.COM > Cc: 'Meyer, Greg W' > Subject: RE: Report of Q.5 (mobility) phone conference, December 18th, > 200 1 > > > (Mr. Greg Meyer: Kindly forward the mail to the SG16 mailing list.) > > Hi, Mr. Francois and All: > > The fundamental arguments have been that a protocol is > defined with its own > characteristics. For example, H.323 protocol has its own entities like > terminals, GKs, BEs, and GWs. Whatever protocol is used by > these entities > among themselves is known as H.323 protocol suit: For > example, H.225.0 Annex > G among BEs. So, the argument is that whatever protocol is > used among the > BEs is known as H..25.0 Annex G. The question is: How can we > define another > protocol like H.22x among the same BEs of H.323? Is it not > contradictory to > the fundamentals for development of the protocol? Will it not confuse > everything? (An analogy: How can we say that let us develop another > protocol, say, H.ZZZ to be used among terminals, GKs, and GWs > in addition to > H.323?) > > The solution that we have been discussed among ourselves is > as follows (I am > providing a copy): > > -------------------------------------------------------------- > -------------- > ------------------------------------------- > 1. We are developing a new protocol where no protocol exists > and the same > can used by all applications to solve the mobility related > problems. For > example, no protocol exits among BE/AMFE, VLF, HLF, and AuF. > Here where we > are defining a new "generic" protocol. This is not specific > to the H.323 > protocol. (Whether VLF, HLF, and AuF will be colocated with > the BE/AMFE is a > matter of implementation.) > > 2. We have the H.225.0 Annex G protocol that allows us to > communicate among > the H.323 BEs. This is specific to H.323. All we need to do > is to extend > this protocol to serve our purposes. (An analogy can be > provided. It should > be done in a way what Paul Reddy has done for H.xxx Annex E.) > > 3. We have the H.225.0 (RAS + Q.931) protocol that is used > among the H.323 > Terminals, GKs, and GWs. This is specific to H.323. All we > need to do is to > extend this protocol to serve our purposes. (An analogy can > be provided. It > should be done in a way what Paul Reddy has done for H.xxx Annex E.) > > The questions that I have to you all: Why do you want to > develop a generic > protocol (if it is not H.323 specific) for items 2 and 3? If > you want to do > so, how do you definite the generic functional entities like > terminals, GKs, > BEs, GWs, etc? (Please also note that H.324 and H.310 do not have the > concept of functional entities like GKs.) > > My assumption has been that the same (items 2 and 3) can also > be done for > H.324, H.310, or other protocol while all protocols can use the same > "generic" protocol as developed in item 1. > > Please also note that if we develop a "generic" protocol for > items 2 and 3 > instead of being making protocol-specific extension, we will > force each > protocol (H.323, H.324, H.310, etc.) to use the DUPLICATE > sets of protocols > (protocol specific + generic) among all its functional > entities. Is it nor > wastage of resources? > > -------------------------------------------------------------- > -------------- > ----------------------------------------- > > It is not that we cannot develop many fency things like H.22x, but it > contradicts the fundamental goals of the protocol development. > > Best regards, > > Radhika R. Roy > rrroy(a)att.com > > -----Original Message----- > From: BOUGANT François FTRD/DAC/ISS > [ mailto:francois.bougant@RD.FRANCETELECOM.COM] > Sent: Friday, January 11, 2002 10:32 AM > To: ITU-SG16(a)echo.jf.INTEL.COM > Subject: Re: Report of Q.5 (mobility) phone conference, December 18th, > 200 1 > > > Dear all, > > During the last rapporteur's meeting (Dublin - Ireland), it > was expressed > that defining H.22x (designed on the basis of H.225 annex G v2 at the > current state - the backward compatibility with H.225 annex G > v1 would be > necessary) as a protocol used on BE--BE and BE--{Backend > service entities} > interfaces (other interfaces implying GKs could be > considered) and stopping > H.225 annex G would be a better way than defining a new > protocol used on > BE--{Backend service entities} interfaces and going on H.225 v2. > > A significant argument is : in the latter case, the BE would > support two > application-layer protocols that may evolve separatly in the > future. This > would tend to make BE functionalities harder to implement. > A second one is : if the H.22x "body" includes the H.225 > annex G protocol , > it can be used for information exchange on BE--BE interface > even in the > H.323 mobility management context. > > To my understanding, H.22X would not contain any functional > architecture > description. This would be specifically described in every > H.MMS.x draft, > depending on the application context (H.323 specific, etc.). > To give an > example, the definition of generic entities would be > contained in H.MMS.0. > Specific entities such as GKs would be described in H.MMS.1. > Then, mobility management implies a limited set of > information exchanges > that are independants from the application (although the type > of exchange > data depends on the application). These are related to the > same actions at > least : user registration/deregistration, location update, > authentication, > information update (e.g. user service profile transfer, > update), location > information request. So I think it is possible to define a > "simple" generic > protocol. > > Best regards, > > François Bougant > France Telecom > > -----Message d'origine----- > De : Roy, Radhika R, ALASO [ mailto:rrroy@att.com] > Envoyé : mercredi 9 janvier 2002 16:16 > À : BOUGANT François FTRD/DAC/ISS; ITU-SG16(a)echo.jf.INTEL.COM > Cc : Meyer, Greg W > Objet : RE: Report of Q.5 (mobility) phone conference, December 18th, > 2001 > > > Hi, Mr. Francois and All: > > In addition, we also had some email correspondences among the > conference > participants and few interested folks including Mr. Jones and > Mr. Reddy. It > has been opined that H.22x is NOT needed because the extensions of the > existing application-specific protocol (e.g., H.225.0 Annex > G) for mobility > will serve the purpose. > > Copies of the emails are enclosed below. > > Best regards, > > Radhika R. Roy > rrroy(a)att.com > > PS: I would highly appreciate if Mr. Greg Meyer would send > the email to the > SG16 reflector as you know that I can receive the mail from > the reflector, > but cannot send it because of problems in filtering. >

1 0

AW: Report of Q.5 (mobility) phone conference, December 18th, 200 1
by Horvath Ernst 18 Jan '02

18 Jan '02

We should really try to stop going in circles and come to a conclusion. These are the facts: 1) For a full year the procedures described in H.MMS.1 have been stable; they referred to H.225.0 Annex G, but that was opposed by some participants in the mobility discussion. This was one reason why mobility work progressed slower than expected. 2) In Dublin we found a compromise which did not change the technical solution, just the form of presentation and documentation: the "protocol kernel" should be lifted out of H.225.0 Annex G and turned into an own recommendation. This would allow different applications to make use of this protocol independently and still maintain the protocol in a single document. One application would be H.225.0 Annex G v2, another one mobility management. 3) The effect on H.MMS.1 is probably minimal, just a change of reference. 4) Contrary to Mr. Roy's statement there is absolutely no overlap with H.225.0 Annex G since the protocol specification is removed from Annex G and replaced by a reference to H.22x. The protocol itself is fully backwards compatible with Annex G version 1. It is now up to the work group to decide how to proceed, either in the present way with an external protocol specification in H.22x or in the former way with the protocol specification integrated in H.225.0 Annex G. In the latter case Annex G version 2 would have to include some extensions needed by H.MMS.1 and H.235 Annex G. Whatever the decision will be, H.MMS.1 will hardly be affected. The implications for H.225.0 annex G v2 and H.MMS.0 would be bigger: both of these documents will either simply refer to H.22x or contain their own (yet very similar) protocol specification. In any case, we should try our best to finalize H.MMS.1 in February. This means the protcol must be finalized as well, whether it's H.22x or H.225.0 Annex G v2. Kind Regards, Ernst Horvath Siemens AG > -----Ursprüngliche Nachricht----- > Von: Meyer, Greg W [mailto:greg.w.meyer@INTEL.COM] > Gesendet am: Freitag, 11. Jänner 2002 21:35 > An: ITU-SG16(a)echo.jf.INTEL.COM > Betreff: Report of Q.5 (mobility) phone conference, December > 18th, 200 1 > > -----Original Message----- > From: Roy, Radhika R, ALASO [mailto:rrroy@att.com] > Sent: Friday, January 11, 2002 9:02 AM > To: BOUGANT François FTRD/DAC/ISS; ITU-SG16(a)echo.jf.INTEL.COM > Cc: Meyer, Greg W > Subject: RE: Report of Q.5 (mobility) phone conference, December 18th, > 200 1 > > > (Mr. Greg Meyer: Kindly forward the mail to the SG16 mailing list.) > > Further to my earlier email, I like to add a summary. The > main reason is > that H.22x is almost a duplicate set of H.225.0 Annex G > protocol except few > parameters related to mobility (what can be done through > extending H.225.0 > Annex G). > > Please note that we have developed as modular sets that are > decoupled as > follows: > > H.225.0 RAS - Pre-call setup (among the terminals, GKs, and GWs) > H.225.0 Q.931 - Call setup (among the terminals, GKs, and GWs) > H.225.0 Annex G - among the BEs > H.245 Call/media control (terminals, media-aware GKs, GWs) > > The proposed H.22x overlaps completely with H.225.0 Annex G except few > mobility related parameters. Here lies the fundamental confusions. > > Best regards, > > Radhika R. Roy > rrroy(a)att.com > > -----Original Message----- > From: Roy, Radhika R, ALASO > Sent: Friday, January 11, 2002 11:42 AM > To: 'BOUGANT François FTRD/DAC/ISS'; ITU-SG16(a)echo.jf.INTEL.COM > Cc: 'Meyer, Greg W' > Subject: RE: Report of Q.5 (mobility) phone conference, December 18th, > 200 1 > > > (Mr. Greg Meyer: Kindly forward the mail to the SG16 mailing list.) > > Hi, Mr. Francois and All: > > The fundamental arguments have been that a protocol is > defined with its own > characteristics. For example, H.323 protocol has its own entities like > terminals, GKs, BEs, and GWs. Whatever protocol is used by > these entities > among themselves is known as H.323 protocol suit: For > example, H.225.0 Annex > G among BEs. So, the argument is that whatever protocol is > used among the > BEs is known as H..25.0 Annex G. The question is: How can we > define another > protocol like H.22x among the same BEs of H.323? Is it not > contradictory to > the fundamentals for development of the protocol? Will it not confuse > everything? (An analogy: How can we say that let us develop another > protocol, say, H.ZZZ to be used among terminals, GKs, and GWs > in addition to > H.323?) > > The solution that we have been discussed among ourselves is > as follows (I am > providing a copy): > > -------------------------------------------------------------- > -------------- > ------------------------------------------- > 1. We are developing a new protocol where no protocol exists > and the same > can used by all applications to solve the mobility related > problems. For > example, no protocol exits among BE/AMFE, VLF, HLF, and AuF. > Here where we > are defining a new "generic" protocol. This is not specific > to the H.323 > protocol. (Whether VLF, HLF, and AuF will be colocated with > the BE/AMFE is a > matter of implementation.) > > 2. We have the H.225.0 Annex G protocol that allows us to > communicate among > the H.323 BEs. This is specific to H.323. All we need to do > is to extend > this protocol to serve our purposes. (An analogy can be > provided. It should > be done in a way what Paul Reddy has done for H.xxx Annex E.) > > 3. We have the H.225.0 (RAS + Q.931) protocol that is used > among the H.323 > Terminals, GKs, and GWs. This is specific to H.323. All we > need to do is to > extend this protocol to serve our purposes. (An analogy can > be provided. It > should be done in a way what Paul Reddy has done for H.xxx Annex E.) > > The questions that I have to you all: Why do you want to > develop a generic > protocol (if it is not H.323 specific) for items 2 and 3? If > you want to do > so, how do you definite the generic functional entities like > terminals, GKs, > BEs, GWs, etc? (Please also note that H.324 and H.310 do not have the > concept of functional entities like GKs.) > > My assumption has been that the same (items 2 and 3) can also > be done for > H.324, H.310, or other protocol while all protocols can use the same > "generic" protocol as developed in item 1. > > Please also note that if we develop a "generic" protocol for > items 2 and 3 > instead of being making protocol-specific extension, we will > force each > protocol (H.323, H.324, H.310, etc.) to use the DUPLICATE > sets of protocols > (protocol specific + generic) among all its functional > entities. Is it nor > wastage of resources? > > -------------------------------------------------------------- > -------------- > ----------------------------------------- > > It is not that we cannot develop many fency things like H.22x, but it > contradicts the fundamental goals of the protocol development. > > Best regards, > > Radhika R. Roy > rrroy(a)att.com > > -----Original Message----- > From: BOUGANT François FTRD/DAC/ISS > [mailto:francois.bougant@RD.FRANCETELECOM.COM] > Sent: Friday, January 11, 2002 10:32 AM > To: ITU-SG16(a)echo.jf.INTEL.COM > Subject: Re: Report of Q.5 (mobility) phone conference, December 18th, > 200 1 > > > Dear all, > > During the last rapporteur's meeting (Dublin - Ireland), it > was expressed > that defining H.22x (designed on the basis of H.225 annex G v2 at the > current state - the backward compatibility with H.225 annex G > v1 would be > necessary) as a protocol used on BE--BE and BE--{Backend > service entities} > interfaces (other interfaces implying GKs could be > considered) and stopping > H.225 annex G would be a better way than defining a new > protocol used on > BE--{Backend service entities} interfaces and going on H.225 v2. > > A significant argument is : in the latter case, the BE would > support two > application-layer protocols that may evolve separatly in the > future. This > would tend to make BE functionalities harder to implement. > A second one is : if the H.22x "body" includes the H.225 > annex G protocol , > it can be used for information exchange on BE--BE interface > even in the > H.323 mobility management context. > > To my understanding, H.22X would not contain any functional > architecture > description. This would be specifically described in every > H.MMS.x draft, > depending on the application context (H.323 specific, etc.). > To give an > example, the definition of generic entities would be > contained in H.MMS.0. > Specific entities such as GKs would be described in H.MMS.1. > Then, mobility management implies a limited set of > information exchanges > that are independants from the application (although the type > of exchange > data depends on the application). These are related to the > same actions at > least : user registration/deregistration, location update, > authentication, > information update (e.g. user service profile transfer, > update), location > information request. So I think it is possible to define a > "simple" generic > protocol. > > Best regards, > > François Bougant > France Telecom > > -----Message d'origine----- > De : Roy, Radhika R, ALASO [mailto:rrroy@att.com] > Envoyé : mercredi 9 janvier 2002 16:16 > À : BOUGANT François FTRD/DAC/ISS; ITU-SG16(a)echo.jf.INTEL.COM > Cc : Meyer, Greg W > Objet : RE: Report of Q.5 (mobility) phone conference, December 18th, > 2001 > > > Hi, Mr. Francois and All: > > In addition, we also had some email correspondences among the > conference > participants and few interested folks including Mr. Jones and > Mr. Reddy. It > has been opined that H.22x is NOT needed because the extensions of the > existing application-specific protocol (e.g., H.225.0 Annex > G) for mobility > will serve the purpose. > > Copies of the emails are enclosed below. > > Best regards, > > Radhika R. Roy > rrroy(a)att.com > > PS: I would highly appreciate if Mr. Greg Meyer would send > the email to the > SG16 reflector as you know that I can receive the mail from > the reflector, > but cannot send it because of problems in filtering. >

1 0

FW: [Megaco] LCN mapping
by Tom-PT Taylor 17 Jan '02

17 Jan '02

-----Original Message----- From: Taylor, Tom-PT [CAR:B800:EXCH] Sent: Thursday, January 17, 2002 7:59 PM To: 'Christer Holmberg' Cc: megaco(a)ietf.org; sg16(a)jf.intel.com Subject: RE: [Megaco] LCN mapping H.248 Annex M.4 (packages for H.324 operation) says this right at the end of section M.4.6: "When logical channels are opened for audio, video and data, the termination shall be connected to the appropriate terminations respectively." In other words, it happens by magic. You make a valid point: there is something missing in the specification. One possibility is to say that the MG associates streams with logical channels in the sequence in which the two are respectively defined. Because of the possibility of misordering it would be safer to have an explicit means for the purpose. I wonder if it is too soon to amend Annex M.4? I'm copying this message to the SG 16 list so they can think about the issue. -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] Sent: Thursday, January 17, 2002 6:34 PM To: Taylor, Tom-PT [CAR:B800:EXCH] Cc: megaco(a)ietf.org Subject: Re: [Megaco] LCN mapping Hi, >The short answer is that the relationship between LCN (Logical Channel >Number) and streamID is set by the application control, which probably >resides in the MGC. I agree. But, how do I indicate that relationship to the MG, where the actual LCN and streamID "connection" is? >Assuming your H.223 mux is operating as part of the H.324 system it was designed for, the control information >is carried in H.245 signalling, gets routed to the MGC, and results in H.248 requests back >to the MG. I agree. But, again, in that request the MGC have to tell the MG how to do the mapping. >However, let me first address your proposed multiplexing structure. I >should mention that several of us (Christian Groves, Roni Even, Marcello >Pantaleo and myself) are nearing the end of a discussion initiated by >Christian, on additional words to add around the multiplex concept, >clarifying it and at the same time allowing it to be used to represent Nx64K >wideband service. I will report the results and reasoning to the list >shortly. In any event, the basic multiplex concept I have been defending >(based on what we already have in RFC 3015/H.248)is something that >specifically has one or more circuits on one side and appears as an ordinary >termination to the rest of the context on the other. Along the way, it >hides the circuits (which are represented by terminationIDs of their own) >from the rest of the context. > >In your present example, you have the multiplexing termination (T3), 30 or >24 circuits which support it (the circuits in the E1/T1), and the RTP >termination T2. If you are running H.324, the recommended way to tie the >circuits together is to use H.226 channel aggregation (set up with V.140 >signalling) under the H.223 multiplex. Because H.226 is mentioned in H.324 >(Annex F) but not in H.223, I suspect we have to model the two layers of >multiplexing explicitly. This blows holes in my idea that all multiplexes >are supported directly by circuits. In diagramatic terms, we have the >following situation: > > Context interior ----> > _________ _________ > Data stream | H.226 | | H.223 | Audio stream >Ckt 1 ..............| "MUX" | | MUX | ................. > . . . | term | Data stream | term | > Data stream | | ................| | Video stream >Ckt n ..............| | | | ................. > | | | | > --------- --------- > >Here the H.226 MUX termination contains/is supported by the individual >circuits, which appear as terminations in their own right. The H.223 MUX >termination contains/is supported by the H.226 MUX termination. > >The model I have been arguing for is that a multiplexing termination hides >all of the terminations it contains from the rest of the context. One >implication of this is that the streamIDs of the streams flowing between the >contained terminations and the multiplexing termination are local rather >than global in scope. > >Looking at the above diagram, people may ask how we know that the stream >between the H.226 and H.223 multiplexing terminations is a data stream, >while the streams passing from the H.223 termination to the rest of the >context are audio and video. I will maintain that this is a result of the >definition of the respective multiplexes. If this is not clear, we need an >explicit description of the exterior-side and context-side streams supported >by each multiplex somewhere within our Megaco/H.248 documentation. I look at the above diagram, and my question is still the same: how do I map the Audio- and Video straems coming out from the H.223 MUX term to specific RTP terminations (and possibly specific streams within them)? >I come to my final point. Your example included the RTP termination T2 >within the multiplex. In my view this is a mistake: T2 is just another >termination in the context. All it sees is T3, the H.223 multiplexing >termination, and it exchanges audio and video with that termination. Ok, but my question STILL remains :) T3 does see the mux termination, but I need to be able to tell my context that stream 1 (eg audio) from the mux shall be mapped to stream X in T3, and stream 2 (eg video) shall be mapped to stream Y in T3. ...or, if I want to use separate RTP terminations for audio and video, I need to be able to tell that mux stream 1 shall be mapped to RTP termination T3, and stream 2 into RTP termination T4. >I hope this makes things clearer. The question has raised some points which >I will now have to reflect back into my conversation with Christian and all. >Even better if they bring that conversation to this list. Maybe I've missed some point, but I am still as confused :) Regards, Christer Holmberg Ericsson Finland

1 0

Contributions to the SG16 meeting (5-15 February 2002)
by OKUBO Sakae 15 Jan '02

15 Jan '02

Dear Q.D,F,G,2-5/16 experts, I have created a new directory at the avc-site: ftp://standard.pictel.com/avc-site/0202_Gen or http://standard.pictel.com/ftp/avc-site/0202_Gen This is for the documents input to and output from the coming SG16 meeting in Geneva. Please post your delayed contributions and TDs at the following place and make an announcement at the reflector: ftp://standard.pictel.com/avc-site/Incoming Please note that the files stored there are those provided voluntarily by the contributors for early review of the input/output documents by the experts. Since the SG16 meeting is an official ITU-T meeting and managed by TSB, you must send your documents to TSB-EDH. The meeting documents are made available at the ITU TIES site for ITU-T members. The PictureTel site is NOT intended for mirroring the ITU TIES site, it is functioning to assist the study of experts. 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 *********************************************************

1 0

Report of Q.5 (mobility) phone conference, December 18th, 200 1
by Meyer, Greg W 11 Jan '02

11 Jan '02

-----Original Message----- From: Roy, Radhika R, ALASO [mailto:rrroy@att.com] Sent: Friday, January 11, 2002 9:02 AM To: BOUGANT François FTRD/DAC/ISS; ITU-SG16(a)echo.jf.INTEL.COM Cc: Meyer, Greg W Subject: RE: Report of Q.5 (mobility) phone conference, December 18th, 200 1 (Mr. Greg Meyer: Kindly forward the mail to the SG16 mailing list.) Further to my earlier email, I like to add a summary. The main reason is that H.22x is almost a duplicate set of H.225.0 Annex G protocol except few parameters related to mobility (what can be done through extending H.225.0 Annex G). Please note that we have developed as modular sets that are decoupled as follows: H.225.0 RAS - Pre-call setup (among the terminals, GKs, and GWs) H.225.0 Q.931 - Call setup (among the terminals, GKs, and GWs) H.225.0 Annex G - among the BEs H.245 Call/media control (terminals, media-aware GKs, GWs) The proposed H.22x overlaps completely with H.225.0 Annex G except few mobility related parameters. Here lies the fundamental confusions. Best regards, Radhika R. Roy rrroy(a)att.com -----Original Message----- From: Roy, Radhika R, ALASO Sent: Friday, January 11, 2002 11:42 AM To: 'BOUGANT François FTRD/DAC/ISS'; ITU-SG16(a)echo.jf.INTEL.COM Cc: 'Meyer, Greg W' Subject: RE: Report of Q.5 (mobility) phone conference, December 18th, 200 1 (Mr. Greg Meyer: Kindly forward the mail to the SG16 mailing list.) Hi, Mr. Francois and All: The fundamental arguments have been that a protocol is defined with its own characteristics. For example, H.323 protocol has its own entities like terminals, GKs, BEs, and GWs. Whatever protocol is used by these entities among themselves is known as H.323 protocol suit: For example, H.225.0 Annex G among BEs. So, the argument is that whatever protocol is used among the BEs is known as H..25.0 Annex G. The question is: How can we define another protocol like H.22x among the same BEs of H.323? Is it not contradictory to the fundamentals for development of the protocol? Will it not confuse everything? (An analogy: How can we say that let us develop another protocol, say, H.ZZZ to be used among terminals, GKs, and GWs in addition to H.323?) The solution that we have been discussed among ourselves is as follows (I am providing a copy): ---------------------------------------------------------------------------- ------------------------------------------- 1. We are developing a new protocol where no protocol exists and the same can used by all applications to solve the mobility related problems. For example, no protocol exits among BE/AMFE, VLF, HLF, and AuF. Here where we are defining a new "generic" protocol. This is not specific to the H.323 protocol. (Whether VLF, HLF, and AuF will be colocated with the BE/AMFE is a matter of implementation.) 2. We have the H.225.0 Annex G protocol that allows us to communicate among the H.323 BEs. This is specific to H.323. All we need to do is to extend this protocol to serve our purposes. (An analogy can be provided. It should be done in a way what Paul Reddy has done for H.xxx Annex E.) 3. We have the H.225.0 (RAS + Q.931) protocol that is used among the H.323 Terminals, GKs, and GWs. This is specific to H.323. All we need to do is to extend this protocol to serve our purposes. (An analogy can be provided. It should be done in a way what Paul Reddy has done for H.xxx Annex E.) The questions that I have to you all: Why do you want to develop a generic protocol (if it is not H.323 specific) for items 2 and 3? If you want to do so, how do you definite the generic functional entities like terminals, GKs, BEs, GWs, etc? (Please also note that H.324 and H.310 do not have the concept of functional entities like GKs.) My assumption has been that the same (items 2 and 3) can also be done for H.324, H.310, or other protocol while all protocols can use the same "generic" protocol as developed in item 1. Please also note that if we develop a "generic" protocol for items 2 and 3 instead of being making protocol-specific extension, we will force each protocol (H.323, H.324, H.310, etc.) to use the DUPLICATE sets of protocols (protocol specific + generic) among all its functional entities. Is it nor wastage of resources? ---------------------------------------------------------------------------- ----------------------------------------- It is not that we cannot develop many fency things like H.22x, but it contradicts the fundamental goals of the protocol development. Best regards, Radhika R. Roy rrroy(a)att.com -----Original Message----- From: BOUGANT François FTRD/DAC/ISS [mailto:francois.bougant@RD.FRANCETELECOM.COM] Sent: Friday, January 11, 2002 10:32 AM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: Re: Report of Q.5 (mobility) phone conference, December 18th, 200 1 Dear all, During the last rapporteur's meeting (Dublin - Ireland), it was expressed that defining H.22x (designed on the basis of H.225 annex G v2 at the current state - the backward compatibility with H.225 annex G v1 would be necessary) as a protocol used on BE--BE and BE--{Backend service entities} interfaces (other interfaces implying GKs could be considered) and stopping H.225 annex G would be a better way than defining a new protocol used on BE--{Backend service entities} interfaces and going on H.225 v2. A significant argument is : in the latter case, the BE would support two application-layer protocols that may evolve separatly in the future. This would tend to make BE functionalities harder to implement. A second one is : if the H.22x "body" includes the H.225 annex G protocol , it can be used for information exchange on BE--BE interface even in the H.323 mobility management context. To my understanding, H.22X would not contain any functional architecture description. This would be specifically described in every H.MMS.x draft, depending on the application context (H.323 specific, etc.). To give an example, the definition of generic entities would be contained in H.MMS.0. Specific entities such as GKs would be described in H.MMS.1. Then, mobility management implies a limited set of information exchanges that are independants from the application (although the type of exchange data depends on the application). These are related to the same actions at least : user registration/deregistration, location update, authentication, information update (e.g. user service profile transfer, update), location information request. So I think it is possible to define a "simple" generic protocol. Best regards, François Bougant France Telecom -----Message d'origine----- De : Roy, Radhika R, ALASO [mailto:rrroy@att.com] Envoyé : mercredi 9 janvier 2002 16:16 À : BOUGANT François FTRD/DAC/ISS; ITU-SG16(a)echo.jf.INTEL.COM Cc : Meyer, Greg W Objet : RE: Report of Q.5 (mobility) phone conference, December 18th, 2001 Hi, Mr. Francois and All: In addition, we also had some email correspondences among the conference participants and few interested folks including Mr. Jones and Mr. Reddy. It has been opined that H.22x is NOT needed because the extensions of the existing application-specific protocol (e.g., H.225.0 Annex G) for mobility will serve the purpose. Copies of the emails are enclosed below. Best regards, Radhika R. Roy rrroy(a)att.com PS: I would highly appreciate if Mr. Greg Meyer would send the email to the SG16 reflector as you know that I can receive the mail from the reflector, but cannot send it because of problems in filtering.

1 0