January 2002 - sg16-avd - lists.packetizer.com

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

Re: 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 8:44 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

John Brownlie
by bpechey＠cix.compulink.co.uk 11 Jan '02

11 Jan '02

Dear All, Most of you will know by now that John Brownlie of BT Labs died in September 2001. If you didn't know, I'm sorry to be the bearer of bad news. John was a very active and notorious participant in standards activities and will be missed in those groups. After a suggestion by Jack Moran, many people thought that it would be a good idea if those who knew him could spend a little time writing a story or two about their recollections. Perhaps there's some particular event or events that stick in your mind as typifying JB, if so, please write it up. There's certainly plenty of material! I have at last managed to get in touch with his daughter, Helen, who thinks that it would be a great idea. John was a very private man and Helen knew very little of what he did at work and on his many trips around the world. She knows he was always a rebel and would particularly like to hear about the more rebellious incidents! So, please spend a few minutes if you can and send me the result; I will compile the contributions into a booklet and give a copy to Helen. I think it would also be a good idea to publish it somewhere on the web so that we could all read it. I have already received a very nice contribution from Ralf-Rainer Damm. Best wishes, Bill. PS. My apologies if you receive multiple copies of this; I have sent it to several email reflectors as well as to a long BCC: list. Please feel free to send it on to anyone whom I might have missed. Bill Pechey Jays Lodge Crays Pond Reading RG8 7QG United Kingdom T: +44 870 740 1123 F: +44 870 740 1126

1 0

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

11 Jan '02

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

H323 version labeling - FW: h323 Annex E support
by Lyons, Terry 11 Jan '02

11 Jan '02

> -----Original Message----- > From: Lyons, Terry > Sent: Thursday, January 10, 2002 12:06 PM > To: 'imtch323implementors(a)mail.imtc.org'; ITU-SG16(a)mailbag.cps.INTEL.COM > Cc: Lyons, Terry > Subject: H323 version labeling - FW: h323 Annex E support > > Maybe we should talk in terms of dot releases, > eg. v3.0 and v4.0 are the official ITU-T Recommendations > whereas v3.1 and v4.1 are the Implementers Guide changes. > > The need is to be clear about what H323 version an endpoint > conforms to or a protocol stack supports. Calling different things, > eg. H323 (11/2000) and H323 IG (6/2001), by the same name "v4" > can lead to misunderstanding. > > - TLyons(a)sonusnet.com +1 732 625-3003 ext 212 > > > -----Original Message----- > From: Paul Long [mailto:plong@ipdialog.com] > Sent: Wednesday, January 09, 2002 12:19 PM > Subject: Re: h323 Annex E support > > > Paul, > > No, the concensus was that the IG is NOT normative because the ITU does > not > sanction its "normativeness" in any way, but it appears that we have made > a > de facto decision to informally pretend that it is normative. I know for > sure that the H.324 IGs were NOT normative. In fact, the H.324 IG is what > its name indicates--an actual guide for implementors, not an corregendum, > which is what the H.323 IG really is (it's also an addendum, but that's > another issue altogether). I don't know about T.120 or H.320, but I'd be > willing to bet that their IGs, if they had any, were also NOT normative. > > Paul Long > ipDialog, Inc. > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Wednesday, January 09, 2002 10:27 AM > To: Lyons, Terry > Cc: imtch323implementors(a)mail.imtc.org > Subject: [imtch323implementors] Re: h323 Annex E support > > > Terry, > > Arguably, the IG is not normative. However, since the first day, ITU-T > SG16 > has used the implementers guides as a normative texts. This is done, not > only with H.323, but also with T.120, H.320, H.324, etc. > > One could ignore the corrections applied to the IG, but doing so is quite > dangerous. You can't simply ignore the changes made via the IG, because > SG16 changes the ASN.1, not just add fields, and those changes will appear > in the next revision of the Recommendations. Of course, we try to limit > changes, but we usually do make a number of changes after the > Recommendation > is first approved and people start to finding problems. There are no > plans > to change the v4 syntax any further-- and I will fight any change-- but > you > can see the history of changes made for v4 on Packetizer. The last > approved > change was June 2001, yet the Recommendation was approved in November > 2000. > > It would be nice if we could first get implementations and then approve > the > Recommendation in a more solid state. Unfortunately, that's not possible > for several reasons: > 1) Companies do not want to spend engineering resources on a moving > target > 2) The standards work is usually way ahead of implementation > 3) No matter how hard we try, there's likely to be something we miss > 4) This is the way it has always been done-- tradition is hard to change > > I presently have no intent to move the IG to series of amendments. We > have > been using this approach for 5 years with good results. Changing the text > would require drafting a number of different documents and that process is > also subject to error. I'm not opposed to it, but I doubt we'll find the > volunteers to write all of the amendments: it's boring, non-rewarding > work. > > Paul > > ----- Original Message ----- > From: "Lyons, Terry" <TLyons(a)sonusnet.com> > To: "'Paul E. Jones'" <paulej(a)packetizer.com>; "Lyons, Terry" > <TLyons(a)sonusnet.com> > Cc: <imtch323implementors(a)mail.imtc.org> > Sent: Wednesday, January 09, 2002 9:47 AM > Subject: RE: h323 Annex E support > > > > We all recognize, don't we, that the Implementers Guide > > is not a normative ITU Recommendation. The way that the ITU > > changes things is through an amendment or subsequent edition. > > I believe there was some discussion of just this point in the past. > > > > The IG is best understood as a indication of what is coming next. > > The correct statment is that the fields are in v4, not v3. > > > > - TLyons(a)sonusnet.com +1 732 625-3003 ext 212 > > > > > > -----Original Message----- > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > Sent: Tuesday, January 08, 2002 11:44 PM > > To: Lyons, Terry > > Cc: imtch323implementors(a)mail.imtc.org > > Subject: Re: h323 Annex E support > > > > > > Terry, > > > > They were added to H.323v3 via the H.323 Implementers Guide approved in > > November 2000. > > > > Paul > > > > ----- Original Message ----- > > From: "Lyons, Terry" <TLyons(a)sonusnet.com> > > To: "'Paul E. Jones'" <paulej(a)packetizer.com> > > Cc: <imtch323implementors(a)mail.imtc.org> > > Sent: Tuesday, January 08, 2002 11:12 AM > > Subject: RE: h323 Annex E support > > > > > > > Hmmm ... the fields are NOT in the ITU publication H.225.0(09/99) > > > nor in the "Draft H.323 Core Document" H.225.0 Version 3 tabulated at > > > http://www.packetizer.com/iptel/h323/ > > > which links to > > > > > > ftp://standard.pictel.com/avc-site/till_0012/9909_Gen/h225v3_decided_wcm_9 > 90 > > > 930 > > > > > > Endpoint ::= SEQUENCE > > > { > > > nonStandardData NonStandardParameter OPTIONAL, > > > aliasAddress SEQUENCE OF AliasAddress OPTIONAL, > > > callSignalAddress SEQUENCE OF TransportAddress > > > OPTIONAL, > > > rasAddress SEQUENCE OF TransportAddress > > > OPTIONAL, > > > endpointType EndpointType OPTIONAL, > > > tokens SEQUENCE OF ClearToken OPTIONAL, > > > cryptoTokens SEQUENCE OF CryptoH323Token > > > OPTIONAL, > > > priority INTEGER(0..127) OPTIONAL, > > > remoteExtensionAddress SEQUENCE OF AliasAddress OPTIONAL, > > > destExtraCallInfo SEQUENCE OF AliasAddress OPTIONAL, > > > ... > > > } > > > > > > - TLyons(a)sonusnet.com +1 732 625-3003 ext 212 > > > > > > > > > -----Original Message----- > > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > > Sent: Tuesday, January 08, 2002 12:56 AM > > > Subject: RE: h323 Annex E support > > > > > > > > > C. S., > > > > > > Those fields are also in v3. See the ASN.1 file here: > > > http://www.packetizer.com/iptel/h323/h2250v3.asn > > > > > > As for how a v2 device will work, Annex E describes how the endpoint > may > > > initiate a call with Annex E and then fall back to TCP if it is > determined > > > that Annex E is not supported. Of course, this is less efficient in > terms > > > of call setup time, so using the v3/v4 fields are preferred. > > > > > > Paul > > > > > > ----- Original Message ----- > > > From: <subbac(a)hss.hns.com> > > > To: "Paul, Manoj" <mpaul(a)trillium.com> > > > Cc: <imtch323implementors(a)mail.imtc.org> > > > Sent: Monday, January 07, 2002 3:48 AM > > > Subject: [imtch323implementors] RE: h323 Annex E support > > > > > > > > > > > > > > > > > > > > > > Hi paul, > > > > > > > > These "alternateTransportAddress" and "useSpecifiedTransport" fields > are > > > > present in h323V4. > > > > > > > > In Case of H323V3 how to mention. > > > > > > > > regards > > > > C. S. Rao > > > > > > > > > > > > > > > > > > > > > > > > "Paul, Manoj" <mpaul(a)trillium.com> on 01/07/2002 01:49:59 PM > > > > > > > > To: Subbarao Chanduri/HSSBLR, imtch323implementors(a)mail.imtc.org > > > > cc: > > > > > > > > Subject: RE: [imtch323implementors] h323 Annex E support > > > > > > > > > > > > > > > > > > > > Rao: > > > > > > > > GK can indicate it's Annex E transport addresses in > > > > "alternateTransportAddress" > > > > field. It also indicates in "useSpecifiedTransport" to use TCP/Annex > E. > > > > > > > > -Manoj Paul > > > > Trillium Digital Systems (Intel). > > > > > > > > -----Original Message----- > > > > From: subbac(a)hss.hns.com [mailto:subbac@hss.hns.com] > > > > Sent: Monday, January 07, 2002 1:37 PM > > > > To: imtch323implementors(a)mail.imtc.org > > > > Cc: subbac(a)hss.hns.com > > > > Subject: [imtch323implementors] h323 Annex E support > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > If Gatekeeper supports H323 Annex E. > > > > inresponse to Admission Request from an endpoint, > > > > through ACF, how gatekeeper informs the endpoint that it is > listening > > on > > > > two different Transport Addresses. > > > > i.e. one transport address (TA1) for Annex E messages. > > > > other transport Address (TA2) for TCP > messages. > > > > > > > > As there is only one field in ACF to indicate the destination call > > > > signalling address, how endpoint come to know > > > > about the different addresses GK is listening. > > > > > > > > > > > > regards > > > > C. S. Rao

2 1

Re: H323 version labeling - FW: h323 Annex E support
by Skran, Dale 10 Jan '02

10 Jan '02

Paul: I think you are incorrect on this. In SG16 implementors guides have always been treated as normative, and clearly are not implementors guides in the sense that you mention. They are formally approved by the entire SG, and become effective 'normative' after that approval. Dale Skran -----Original Message----- From: Lyons, Terry [mailto:TLyons@sonusnet.com] Sent: Thursday, January 10, 2002 12:08 PM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: H323 version labeling - FW: h323 Annex E support > -----Original Message----- > From: Lyons, Terry > Sent: Thursday, January 10, 2002 12:06 PM > To: 'imtch323implementors(a)mail.imtc.org'; ITU-SG16(a)mailbag.cps.INTEL.COM > Cc: Lyons, Terry > Subject: H323 version labeling - FW: h323 Annex E support > > Maybe we should talk in terms of dot releases, > eg. v3.0 and v4.0 are the official ITU-T Recommendations > whereas v3.1 and v4.1 are the Implementers Guide changes. > > The need is to be clear about what H323 version an endpoint > conforms to or a protocol stack supports. Calling different things, > eg. H323 (11/2000) and H323 IG (6/2001), by the same name "v4" > can lead to misunderstanding. > > - TLyons(a)sonusnet.com +1 732 625-3003 ext 212 > > > -----Original Message----- > From: Paul Long [mailto:plong@ipdialog.com] > Sent: Wednesday, January 09, 2002 12:19 PM > Subject: Re: h323 Annex E support > > > Paul, > > No, the concensus was that the IG is NOT normative because the ITU does > not > sanction its "normativeness" in any way, but it appears that we have made > a > de facto decision to informally pretend that it is normative. I know for > sure that the H.324 IGs were NOT normative. In fact, the H.324 IG is what > its name indicates--an actual guide for implementors, not an corregendum, > which is what the H.323 IG really is (it's also an addendum, but that's > another issue altogether). I don't know about T.120 or H.320, but I'd be > willing to bet that their IGs, if they had any, were also NOT normative. > > Paul Long > ipDialog, Inc. > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Wednesday, January 09, 2002 10:27 AM > To: Lyons, Terry > Cc: imtch323implementors(a)mail.imtc.org > Subject: [imtch323implementors] Re: h323 Annex E support > > > Terry, > > Arguably, the IG is not normative. However, since the first day, ITU-T > SG16 > has used the implementers guides as a normative texts. This is done, not > only with H.323, but also with T.120, H.320, H.324, etc. > > One could ignore the corrections applied to the IG, but doing so is quite > dangerous. You can't simply ignore the changes made via the IG, because > SG16 changes the ASN.1, not just add fields, and those changes will appear > in the next revision of the Recommendations. Of course, we try to limit > changes, but we usually do make a number of changes after the > Recommendation > is first approved and people start to finding problems. There are no > plans > to change the v4 syntax any further-- and I will fight any change-- but > you > can see the history of changes made for v4 on Packetizer. The last > approved > change was June 2001, yet the Recommendation was approved in November > 2000. > > It would be nice if we could first get implementations and then approve > the > Recommendation in a more solid state. Unfortunately, that's not possible > for several reasons: > 1) Companies do not want to spend engineering resources on a moving > target > 2) The standards work is usually way ahead of implementation > 3) No matter how hard we try, there's likely to be something we miss > 4) This is the way it has always been done-- tradition is hard to change > > I presently have no intent to move the IG to series of amendments. We > have > been using this approach for 5 years with good results. Changing the text > would require drafting a number of different documents and that process is > also subject to error. I'm not opposed to it, but I doubt we'll find the > volunteers to write all of the amendments: it's boring, non-rewarding > work. > > Paul > > ----- Original Message ----- > From: "Lyons, Terry" <TLyons(a)sonusnet.com> > To: "'Paul E. Jones'" <paulej(a)packetizer.com>; "Lyons, Terry" > <TLyons(a)sonusnet.com> > Cc: <imtch323implementors(a)mail.imtc.org> > Sent: Wednesday, January 09, 2002 9:47 AM > Subject: RE: h323 Annex E support > > > > We all recognize, don't we, that the Implementers Guide > > is not a normative ITU Recommendation. The way that the ITU > > changes things is through an amendment or subsequent edition. > > I believe there was some discussion of just this point in the past. > > > > The IG is best understood as a indication of what is coming next. > > The correct statment is that the fields are in v4, not v3. > > > > - TLyons(a)sonusnet.com +1 732 625-3003 ext 212 > > > > > > -----Original Message----- > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > Sent: Tuesday, January 08, 2002 11:44 PM > > To: Lyons, Terry > > Cc: imtch323implementors(a)mail.imtc.org > > Subject: Re: h323 Annex E support > > > > > > Terry, > > > > They were added to H.323v3 via the H.323 Implementers Guide approved in > > November 2000. > > > > Paul > > > > ----- Original Message ----- > > From: "Lyons, Terry" <TLyons(a)sonusnet.com> > > To: "'Paul E. Jones'" <paulej(a)packetizer.com> > > Cc: <imtch323implementors(a)mail.imtc.org> > > Sent: Tuesday, January 08, 2002 11:12 AM > > Subject: RE: h323 Annex E support > > > > > > > Hmmm ... the fields are NOT in the ITU publication H.225.0(09/99) > > > nor in the "Draft H.323 Core Document" H.225.0 Version 3 tabulated at > > > http://www.packetizer.com/iptel/h323/ > > > which links to > > > > > > ftp://standard.pictel.com/avc-site/till_0012/9909_Gen/h225v3_decided_wcm_9 > 90 > > > 930 > > > > > > Endpoint ::= SEQUENCE > > > { > > > nonStandardData NonStandardParameter OPTIONAL, > > > aliasAddress SEQUENCE OF AliasAddress OPTIONAL, > > > callSignalAddress SEQUENCE OF TransportAddress > > > OPTIONAL, > > > rasAddress SEQUENCE OF TransportAddress > > > OPTIONAL, > > > endpointType EndpointType OPTIONAL, > > > tokens SEQUENCE OF ClearToken OPTIONAL, > > > cryptoTokens SEQUENCE OF CryptoH323Token > > > OPTIONAL, > > > priority INTEGER(0..127) OPTIONAL, > > > remoteExtensionAddress SEQUENCE OF AliasAddress OPTIONAL, > > > destExtraCallInfo SEQUENCE OF AliasAddress OPTIONAL, > > > ... > > > } > > > > > > - TLyons(a)sonusnet.com +1 732 625-3003 ext 212 > > > > > > > > > -----Original Message----- > > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > > Sent: Tuesday, January 08, 2002 12:56 AM > > > Subject: RE: h323 Annex E support > > > > > > > > > C. S., > > > > > > Those fields are also in v3. See the ASN.1 file here: > > > http://www.packetizer.com/iptel/h323/h2250v3.asn > > > > > > As for how a v2 device will work, Annex E describes how the endpoint > may > > > initiate a call with Annex E and then fall back to TCP if it is > determined > > > that Annex E is not supported. Of course, this is less efficient in > terms > > > of call setup time, so using the v3/v4 fields are preferred. > > > > > > Paul > > > > > > ----- Original Message ----- > > > From: <subbac(a)hss.hns.com> > > > To: "Paul, Manoj" <mpaul(a)trillium.com> > > > Cc: <imtch323implementors(a)mail.imtc.org> > > > Sent: Monday, January 07, 2002 3:48 AM > > > Subject: [imtch323implementors] RE: h323 Annex E support > > > > > > > > > > > > > > > > > > > > > > Hi paul, > > > > > > > > These "alternateTransportAddress" and "useSpecifiedTransport" fields > are > > > > present in h323V4. > > > > > > > > In Case of H323V3 how to mention. > > > > > > > > regards > > > > C. S. Rao > > > > > > > > > > > > > > > > > > > > > > > > "Paul, Manoj" <mpaul(a)trillium.com> on 01/07/2002 01:49:59 PM > > > > > > > > To: Subbarao Chanduri/HSSBLR, imtch323implementors(a)mail.imtc.org > > > > cc: > > > > > > > > Subject: RE: [imtch323implementors] h323 Annex E support > > > > > > > > > > > > > > > > > > > > Rao: > > > > > > > > GK can indicate it's Annex E transport addresses in > > > > "alternateTransportAddress" > > > > field. It also indicates in "useSpecifiedTransport" to use TCP/Annex > E. > > > > > > > > -Manoj Paul > > > > Trillium Digital Systems (Intel). > > > > > > > > -----Original Message----- > > > > From: subbac(a)hss.hns.com [mailto:subbac@hss.hns.com] > > > > Sent: Monday, January 07, 2002 1:37 PM > > > > To: imtch323implementors(a)mail.imtc.org > > > > Cc: subbac(a)hss.hns.com > > > > Subject: [imtch323implementors] h323 Annex E support > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > If Gatekeeper supports H323 Annex E. > > > > inresponse to Admission Request from an endpoint, > > > > through ACF, how gatekeeper informs the endpoint that it is > listening > > on > > > > two different Transport Addresses. > > > > i.e. one transport address (TA1) for Annex E messages. > > > > other transport Address (TA2) for TCP > messages. > > > > > > > > As there is only one field in ACF to indicate the destination call > > > > signalling address, how endpoint come to know > > > > about the different addresses GK is listening. > > > > > > > > > > > > regards > > > > C. S. Rao

3 2

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

10 Jan '02

Forwarded per Mr. Roy's request... Greg Meyer -----Original Message----- From: Roy, Radhika R, ALASO [mailto:rrroy@att.com] Sent: Wednesday, January 09, 2002 7:16 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, 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. -----Original Message----- From: BOUGANT François FTRD/DAC/ISS [mailto:francois.bougant@RD.FRANCETELECOM.COM] Sent: Wednesday, January 09, 2002 9:25 AM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: Report of Q.5 (mobility) phone conference, December 18th, 2001 Report of Q.5/SG16 (Mobility) conference call on December 18th, 2001 (prepared by Francois Bougant) Participants: Messrs. Gleason (Cisco), Euchner (Siemens), Horvath (Siemens), Reddy (Intel), Roy (AT&T), Bougant (FT). Available documents: New drafts of H.235 Annex G, H.MMS.0 and H.MMS.1; temporary documents TD-EH-01, TD-EH-02, TD-EH-03, TD-EH-04 and TD-FB-02. Results: Most of the time was spent on TD-EH-04 (H.22x draft) 1) the messages defined to ensure security in signalling exchanges have been discussed. It has been proposed to remove the set of definitions related to Access Request/Confirm/Reject messages from H.22x because security requirements on interaces between heterogeneous systems must be identified. Another discussion was about to add optional fields in Service Request/Confirm/reject messages, because such these messages would be used to start a relationship between entities from heterogeneous systems and with different signalling capabilities. Mr. Orvath proposed to make a separate work on these issues. 2) The next discussion was about the version number of ASN.1 coding of H.22x. " The version number is the only real issue. This is an object identifier which contains "itu-t recommendation h 2250 ..." at the moment. Two solutions seem possible: a) Use application specific version numbers. In Annex G V2 the version number will remain "itu-t recommendation h 2250 ...", in H.MMS.x it will use another object-ID root. b) Use the current object identifier (i.e. just increment the version number) for all applications even if they have nothing to do with Annex G." (extracted from TD-EH-04) Contributions are needed to solve this issue. 3) The next discussion was about to extend the current structures (MessageBody choice and message sequences) in order to support additional data and message formats according to H.MMS.0 requirements. It has been notified that the current H.22x design allows these extensions. The next call conference will be on January 25, 2002. Best regards, Francois Bougant France Telecom

1 0

Re: Including RTCP report packets in IRR
by Even, Roni 10 Jan '02

10 Jan '02

Frank, I do not object to have some reports that are needed by the GK. I would object to copy all RTCP info to the IRR. The RTCP is a direct connection between encoder and decoder. This is used and will be used for supporting media specific indications that will help the communication like for error resilience. Another problem is that decomposed systems like gateways will have the RTCP in the MG part while the GK communication will be done by the MGC who does not have all the RTCP information. that is why I suggested that instead of stating that the need is for the RTCP info to list the information that will be useful for the GK Regards Roni -----Original Message----- From: frank.derks(a)PHILIPS.COM [mailto:frank.derks@PHILIPS.COM] Sent: Tuesday, January 08, 2002 4:48 PM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: Re: Including RTCP report packets in IRR Roni, the idea is that the GK may have its reasons for wanting this sort of information. Depending on why the GK wants this information, it may be classified as being for call control, diagnosis, accounting, etc. An example of usage for call control would be the re-routing of the call when it is experiencing insufficient quality. I agree that there may be other ways of obtaining this sort of information (E.g. through the RTP MIB: RFC2959) and that we may have take other "call control" protocols (like SIP, MGCP and H.248/Megaco) into consideration, to avoid coming up with a H.323 specific solution. Furthermore, the solution(s) may be dependent on the purpose of the information, although I would not opt for a variety of solutions that do more or less the same. The reason, why I initially, proposed the "H.323 solution", is because it is relatively easy to add this to H.323 and because it may serve a multitude of purposes. The fact that this topic is being discussed within the IETF is good, but we must be aware that this is something in which any of us can freely participate. In a sense we all "are" the IETF if we decide to participate. If there are any ideas withing this community, then we should not hesitate to coomunicate this on the AVT mailing list. Regards, Frank Paul, The need for the report is not clear to me. Usually RTCP is used for codec/encoder communication and not call control. What is needed by the GK that is in the RTCP today. If the application is monitoring then maybe SNMP has it already. Roni -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Thursday, December 27, 2001 6:41 AM To: Even ,Roni; ITU-SG16(a)echo.jf.INTEL.COM Subject: Re: Including RTCP report packets in IRR Roni, Yes, you're right. However, it seems reasonable that H.323 systems might report this information to the GK for decision making purposes. We could use SNMP, but we'd need agreement from both sides that that is the way to go. I would guess that the reporting to the GK is intended for some decision processes... would you really prefer to have poll via SNMP instead? I'd suspect you're not going to use traps. Paul ----- Original Message ----- From: "Even ,Roni" <roni.even(a)polycom.co.il> To: "'Paul E. Jones'" <paulej(a)PACKETIZER.COM>; <ITU-SG16(a)echo.jf.INTEL.COM> Sent: Tuesday, December 25, 2001 9:33 AM Subject: RE: Including RTCP report packets in IRR > Paul, > Having a solution for H.323 may not solve the problem. RTP & RTCP are used > also in other protocols like SIP. At the last IETF meeting (IETF-52) the > topic was discussed in the AVT WG. Maybe we can see what will happen there. > I would like to point out that SNMP can be used to get part of the > information. > Roni Even > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > Sent: Monday, December 24, 2001 3:14 AM > To: ITU-SG16(a)echo.jf.INTEL.COM > Subject: Re: Including RTCP report packets in IRR > > > Paul, > > I suppose this is probably in need of clarification, but the assumption was > that if the call contained an audio session, the audio element would be > included. Likewise for video, etc. Unfortunately, there are a few fields > in H.225.0 that are labeled as "OPTIONAL" in the ASN.1, so implementers > assume that semantically they're optional, but that's not the case. We > don't want to change the syntax (since we don't want to mandate the > inclusion of a field when the call doesn't have a session of that type), so > I suppose it would be nice to see a proposal for clarification of this > issue. > > One other thought about the RTCP stats is that we report them in the DRQ > rather than the IRR. One problem with IRRs is that if they are sent too > frequently, an extremely busy system can get bogged down processing those > messages. I imagine that you'd want to set the IRR timer somewhere outside > the length of an average call. Doing so, though, would mean you never get > stats for the average call. So perhaps DRQ alone (or in addition to) the > IRR is the right approach. > > Paul > > ----- Original Message ----- > From: "Paul Long" <plong(a)IPDIALOG.COM> > To: <ITU-SG16(a)echo.jf.INTEL.COM> > Sent: Tuesday, December 18, 2001 10:42 AM > Subject: Re: Including RTCP report packets in IRR > > > > Paul, > > > > Please note though that an EP is not required to include any media info in > > perCallInfo, i.e., audio, video, and data. I imagine that this was an > > oversight, but we ought to explicitly require v5+ EPs to report all > > currently active media sessions, including RTP. > > > > Paul Long > > ipDialog, Inc. > > > > -----Original Message----- > > From: Mailing list for parties associated with ITU-T Study Group 16 > > [mailto:ITU-SG16@echo.jf.INTEL.COM]On Behalf Of Paul E. Jones > > Sent: Tuesday, December 18, 2001 3:07 AM > > To: ITU-SG16(a)echo.jf.INTEL.COM > > Subject: Re: Including RTCP report packets in IRR > > > > > > I completely support your idea. > > > > pj > > > > ----- Original Message ----- > > From: <frank.derks(a)PHILIPS.COM> > > To: <ITU-SG16(a)echo.jf.INTEL.COM> > > Sent: Monday, December 17, 2001 2:42 AM > > Subject: Including RTCP report packets in IRR > > > > > > > Dear all, > > > > > > RTP's specification mandates that the RTP ports, for a given > > > source/destination, are "co-located" with the RTCP ports. This > > > means the the report information about the RTP streams flow > > > between the communicating endpoints. Although this mode of > > > operation is intentional, it does make it difficult for 3rd > > > parties to monitor the statistics as perceived by the endpoints. > > > This can be particularly useful for network management where > > > one would like to be able to monitor whether the network > > > provides adequate quality. > > > > > > On way to access the RTCP information would be to route all the > > > RTCP traffic through some entity, but this also means that the > > > RTP will have to follow the same path through the network. And > > > this is not desirable. > > > > > > For H.323 there would be the option to include the report packets > > > in the "audio" element in the perCallInfo element in the IRR > > > message. This would allow for a Gatekeeper to get a hold of these > > > "vital" statistics. > > > > > > Any views? > > > > > > Regards, > > > > > > Frank > > >

1 0

Report of Q.5 (mobility) phone conference, December 18th, 2001
by BOUGANT François FTRD/DAC/ISS 09 Jan '02

09 Jan '02

Report of Q.5/SG16 (Mobility) conference call on December 18th, 2001 (prepared by Francois Bougant) Participants: Messrs. Gleason (Cisco), Euchner (Siemens), Horvath (Siemens), Reddy (Intel), Roy (AT&T), Bougant (FT). Available documents: New drafts of H.235 Annex G, H.MMS.0 and H.MMS.1; temporary documents TD-EH-01, TD-EH-02, TD-EH-03, TD-EH-04 and TD-FB-02. Results: Most of the time was spent on TD-EH-04 (H.22x draft) 1) the messages defined to ensure security in signalling exchanges have been discussed. It has been proposed to remove the set of definitions related to Access Request/Confirm/Reject messages from H.22x because security requirements on interaces between heterogeneous systems must be identified. Another discussion was about to add optional fields in Service Request/Confirm/reject messages, because such these messages would be used to start a relationship between entities from heterogeneous systems and with different signalling capabilities. Mr. Orvath proposed to make a separate work on these issues. 2) The next discussion was about the version number of ASN.1 coding of H.22x. " The version number is the only real issue. This is an object identifier which contains "itu-t recommendation h 2250 ..." at the moment. Two solutions seem possible: a) Use application specific version numbers. In Annex G V2 the version number will remain "itu-t recommendation h 2250 ...", in H.MMS.x it will use another object-ID root. b) Use the current object identifier (i.e. just increment the version number) for all applications even if they have nothing to do with Annex G." (extracted from TD-EH-04) Contributions are needed to solve this issue. 3) The next discussion was about to extend the current structures (MessageBody choice and message sequences) in order to support additional data and message formats according to H.MMS.0 requirements. It has been notified that the current H.22x design allows these extensions. The next call conference will be on January 25, 2002. Best regards, Francois Bougant France Telecom

1 0

Re: Including RTCP report packets in IRR
by frank.derks＠PHILIPS.COM 08 Jan '02

08 Jan '02

Roni, the idea is that the GK may have its reasons for wanting this sort of information. Depending on why the GK wants this information, it may be classified as being for call control, diagnosis, accounting, etc. An example of usage for call control would be the re-routing of the call when it is experiencing insufficient quality. I agree that there may be other ways of obtaining this sort of information (E.g. through the RTP MIB: RFC2959) and that we may have take other "call control" protocols (like SIP, MGCP and H.248/Megaco) into consideration, to avoid coming up with a H.323 specific solution. Furthermore, the solution(s) may be dependent on the purpose of the information, although I would not opt for a variety of solutions that do more or less the same. The reason, why I initially, proposed the "H.323 solution", is because it is relatively easy to add this to H.323 and because it may serve a multitude of purposes. The fact that this topic is being discussed within the IETF is good, but we must be aware that this is something in which any of us can freely participate. In a sense we all "are" the IETF if we decide to participate. If there are any ideas withing this community, then we should not hesitate to coomunicate this on the AVT mailing list. Regards, Frank Paul, The need for the report is not clear to me. Usually RTCP is used for codec/encoder communication and not call control. What is needed by the GK that is in the RTCP today. If the application is monitoring then maybe SNMP has it already. Roni -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Thursday, December 27, 2001 6:41 AM To: Even ,Roni; ITU-SG16(a)echo.jf.INTEL.COM Subject: Re: Including RTCP report packets in IRR Roni, Yes, you're right. However, it seems reasonable that H.323 systems might report this information to the GK for decision making purposes. We could use SNMP, but we'd need agreement from both sides that that is the way to go. I would guess that the reporting to the GK is intended for some decision processes... would you really prefer to have poll via SNMP instead? I'd suspect you're not going to use traps. Paul ----- Original Message ----- From: "Even ,Roni" <roni.even(a)polycom.co.il> To: "'Paul E. Jones'" <paulej(a)PACKETIZER.COM>; <ITU-SG16(a)echo.jf.INTEL.COM> Sent: Tuesday, December 25, 2001 9:33 AM Subject: RE: Including RTCP report packets in IRR > Paul, > Having a solution for H.323 may not solve the problem. RTP & RTCP are used > also in other protocols like SIP. At the last IETF meeting (IETF-52) the > topic was discussed in the AVT WG. Maybe we can see what will happen there. > I would like to point out that SNMP can be used to get part of the > information. > Roni Even > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > Sent: Monday, December 24, 2001 3:14 AM > To: ITU-SG16(a)echo.jf.INTEL.COM > Subject: Re: Including RTCP report packets in IRR > > > Paul, > > I suppose this is probably in need of clarification, but the assumption was > that if the call contained an audio session, the audio element would be > included. Likewise for video, etc. Unfortunately, there are a few fields > in H.225.0 that are labeled as "OPTIONAL" in the ASN.1, so implementers > assume that semantically they're optional, but that's not the case. We > don't want to change the syntax (since we don't want to mandate the > inclusion of a field when the call doesn't have a session of that type), so > I suppose it would be nice to see a proposal for clarification of this > issue. > > One other thought about the RTCP stats is that we report them in the DRQ > rather than the IRR. One problem with IRRs is that if they are sent too > frequently, an extremely busy system can get bogged down processing those > messages. I imagine that you'd want to set the IRR timer somewhere outside > the length of an average call. Doing so, though, would mean you never get > stats for the average call. So perhaps DRQ alone (or in addition to) the > IRR is the right approach. > > Paul > > ----- Original Message ----- > From: "Paul Long" <plong(a)IPDIALOG.COM> > To: <ITU-SG16(a)echo.jf.INTEL.COM> > Sent: Tuesday, December 18, 2001 10:42 AM > Subject: Re: Including RTCP report packets in IRR > > > > Paul, > > > > Please note though that an EP is not required to include any media info in > > perCallInfo, i.e., audio, video, and data. I imagine that this was an > > oversight, but we ought to explicitly require v5+ EPs to report all > > currently active media sessions, including RTP. > > > > Paul Long > > ipDialog, Inc. > > > > -----Original Message----- > > From: Mailing list for parties associated with ITU-T Study Group 16 > > [mailto:ITU-SG16@echo.jf.INTEL.COM]On Behalf Of Paul E. Jones > > Sent: Tuesday, December 18, 2001 3:07 AM > > To: ITU-SG16(a)echo.jf.INTEL.COM > > Subject: Re: Including RTCP report packets in IRR > > > > > > I completely support your idea. > > > > pj > > > > ----- Original Message ----- > > From: <frank.derks(a)PHILIPS.COM> > > To: <ITU-SG16(a)echo.jf.INTEL.COM> > > Sent: Monday, December 17, 2001 2:42 AM > > Subject: Including RTCP report packets in IRR > > > > > > > Dear all, > > > > > > RTP's specification mandates that the RTP ports, for a given > > > source/destination, are "co-located" with the RTCP ports. This > > > means the the report information about the RTP streams flow > > > between the communicating endpoints. Although this mode of > > > operation is intentional, it does make it difficult for 3rd > > > parties to monitor the statistics as perceived by the endpoints. > > > This can be particularly useful for network management where > > > one would like to be able to monitor whether the network > > > provides adequate quality. > > > > > > On way to access the RTCP information would be to route all the > > > RTCP traffic through some entity, but this also means that the > > > RTP will have to follow the same path through the network. And > > > this is not desirable. > > > > > > For H.323 there would be the option to include the report packets > > > in the "audio" element in the perCallInfo element in the IRR > > > message. This would allow for a Gatekeeper to get a hold of these > > > "vital" statistics. > > > > > > Any views? > > > > > > Regards, > > > > > > Frank > > >

1 0

Facilty Message, reason StartH245
by Peter Price 04 Jan '02

04 Jan '02

All, I need a little help with interpretation... I believe that the receipt of a Facility message with reason "StartH245" means that the receiving endpoint SHALL open an H245 channel to the sender at the supplied transport address. However, I can't find where it specifies the SHALL part of this statement in the standards. The only references I can find to startH245 are (H323/8.2.3) related to Fast Connect and tunnelling (H.245/7.4.1) which is actually about when the reason code is NOT StartH245 So the questions are: 1) Is it appropriate to use Facility (startH245) outside Fast Connect or Tunnelling (for instance the called endpoint trying to force the equivalent of Early H245) 2) Is it really mandatory for the receiving endpoint to open the H245 channel - if so where does it stipulate this in the standards. Thanks Pete Price Vegastream Ltd

2 1