- sg16-avd - lists.packetizer.com

Re: Annex Gv2
by Roy, Radhika R 22 May '01

22 May '01

Hi, Paul: It is not about "master" protocol per se. It is also NOT the name change (even the name change provides the meets the first step of the fundamental objective because the same protocol can be used by all applications for mobility in the context of HLF/VLF/AUF: H.323, H.310, H.324, IMT-2000, and others - it is also a very big gain). It is the big picture of Q.5/16 how the whole mobility question needs to be addressed. People want to build "inefficient" protocol by duplicating the same thing for the same purpose is against the very fundamental principle of ITU standardization. The protocol used by HLF/VLF/AuF/Billing/QOS/Accounting will NOT be called H.225.0 Annex G. The proposal has been made with the name of simple extensions of some messages of Annex G (as if nothing else is needed here now or in the future) to fulfill the very short-term "narrow" objectives. But it is forgotten that many more things are ahead to address all issues related to mobility. Hope this clarifies the things. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Horvath Ernst [mailto:ernst.horvath@SIEMENS.AT] Sent: Tuesday, May 22, 2001 5:38 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: AW: Annex Gv2 Paul, I welcome the proposal not to approve H.225.0 annex G v2 now. In my contribution to Q.5/16 I suggest to make the mobility management protocol a "profile" of the annex G protocol, after adding the few extras that mobility management would require. However, some members strongly oppose to calling mobility management "H.225.0 annex G". Since the arguing is about names rather than content, it would be undesirable to duplicate the work and define nearly identical protocols in two different recommendations. Maybe we can define a "master protocol" in a separate recommendation and then derive various profiles from this master protocol: for the current annex G (reference point A), for reference point B (GK-BE), for mobility management, etc. Regards, Ernst Horvath Siemens AG > -----Ursprüngliche Nachricht----- > Von: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > Gesendet am: Dienstag, 22. Mai 2001 06:14 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: Re: Annex Gv2 > > Paul, > > I think the decisions made for H.225.0 Annex Gv2 as it > relates to Q.5 work > should be considered, but I stress even more the other two issues: the > editor feels that the content has not changed significantly enough and > comments I've received from others relating to reference > point D. I believe > the latter two issues are most significant. > > Two questions I hear from people often are "How does the GK > talk to the BE?" > and "What good does it do to have the usage information in > Annex G when it > can't be passed to/from the GK?" Consideration should be > given to whether > those questions are adequately answered (which they're not) > and whether we > want to answer those question within the protocol at this time. > > Paul > > ----- Original Message ----- > From: "Reddy, Paul K" <paul.k.reddy(a)INTEL.COM> > To: <ITU-SG16(a)mailbag.cps.INTEL.COM> > Sent: Monday, May 21, 2001 7:48 PM > Subject: Re: Annex Gv2 > > > > Hi Radhika, > > > > With respect to your point on 2a, Q.5/16 has been defined > the Objectives, > > scope, work plan for study period 2001-2004 during last Rapporteur's > meeting > > in Lanceston, Australia. As far as the protocol for H.MMS.1 > (Mobility for > > Multimedia systems based on H.323) recommendation has not > been decided as > of > > last meeting. Your contributions and other contributions > have come in for > > Porte Seguro's meeting in Brazil will consider for > discussion on Mobility > > protocols like H.MMS.General (based on H.225.0 AnnexG or > other protocol > > etc.) > > > > PS: Paul, I would recommend not to delay the approval of > H.225.0 Annex > Gv2, > > if Annex Gv2 does not include the Mobility work. - Paul > > > > regards, > > Paul > > > > Paul K. Reddy > > Rapporteur for Q.5/16 > > Intel Corporation, Mailstop:JF3-377 > > 2111 N.E. 25th Avenue, > > Hillsboro, OR - 97229, USA > > Office Phone # +1 (503)-264-9896 > > Mobile Phone # +1 (503)-807-9564 > > Email: paul.k.reddy(a)intel.com > > > > > > -----Original Message----- > > From: Roy, Radhika R [mailto:rrroy@ATT.COM] > > Sent: Monday, May 21, 2001 9:18 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: Annex Gv2 > > > > > > Hi, Paul: > > > > Let me explain where H.225.0 Annex G may fit with respect > to mobility as > > well as non-mobility as follows: > > > > 1. Anything extension that does NOT deal with MOBILITY in > H.225.0 Annex G > > version 2 can be considered for approval. > > > > 2. Anything that deals with MOBILITY (or with an intention > to support > > mobility indirectly) in H.225.0 Annex G version 2 MUST NOT > be considered > for > > approval because of the following: > > > > a. The scope and reference points of mobility Q.5/16 needs > to be defined > > that is consistent with its charter. > > > > b. H.MMS.x work will be defined and completed in accordance > to item a. > > > > c. All applications can use the common protocol for > HLF/VLF/AuF (and other > > value-added services). It will be a new protocol and will > NOT have any > > application-specific name (e.g., H.225.0 Annex G). > > > > d. As soon as we complete item c, we will see what needs to > be done for > > H.323. In H.323, we may have to extend H.225.0 RAS + > H.225.0 Annex G. > These > > are application-specific extensions to support MOBILITY > (applicable for > each > > application as well: H.310, H.324, IMT-2000, etc.). > > > > This is what has been proposed by AT&T in all contributions. > > > > Hope this will help. > > > > Best regards, > > Radhika R. Roy > > AT&T > > > > -----Original Message----- > > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > > Sent: Sunday, May 20, 2001 10:06 PM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Annex Gv2 > > > > > > Folks, > > > > The editor of Annex G has recommended that we not approve > Annex G at this > > meeting, citing that there is insufficient material to > warrant approval. > I > > have also heard comments from some that additional work > should be done in > > the area of defining reference point D. Of course, we also > have the open > > question of where (if anywhere) Annex G fits into the H.MMS.x work. > > > > For the benefit of those not planning to attend the > meeting, please tell > me > > if you would have objections to *not* approving Annex Gv2 > at this meeting. > > > > Thanks, > > Paul > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Annex Gv2
by Roy, Radhika R 22 May '01

22 May '01

Hi, Paul: We have seen the meeting minutes of Australia and, have significant differences. For example, it is NOT about "interworking" per se as Mr. Bougant (one of the attendees of Australia meeting) pointed out. We do not want to develop anymore INEFFICIENT "interworking" as proposed by Intel's contributions related to the scope of Q.5/16 in the last Australia Rap. meeting. (While people can use the same protocol without duplication, why do they like to develop another protocol for "interworking"?) Accordingly, emails were also sent out to the Sg16 mailing list voicing our concerns. So, the Brazil Sg16 meeting, per AT&T contributions, need to focus on all subjects that have been described in the contributions. With respect to H.225.0 Annex G, I have made clear what needs to be done. Nothing that relates directly or indirectly to MOBILITY will be considered for approval unless the mobility work is finalized (please see the enclosed email). Hope this clarifies the things. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Reddy, Paul K [mailto:paul.k.reddy@intel.com] Sent: Monday, May 21, 2001 7:48 PM To: Roy, Radhika R; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: Annex Gv2 Hi Radhika, With respect to your point on 2a, Q.5/16 has been defined the Objectives, scope, work plan for study period 2001-2004 during last Rapporteur's meeting in Lanceston, Australia. As far as the protocol for H.MMS.1 (Mobility for Multimedia systems based on H.323) recommendation has not been decided as of last meeting. Your contributions and other contributions have come in for Porte Seguro's meeting in Brazil will consider for discussion on Mobility protocols like H.MMS.General (based on H.225.0 AnnexG or other protocol etc.) PS: Paul, I would recommend not to delay the approval of H.225.0 Annex Gv2, if Annex Gv2 does not include the Mobility work. - Paul regards, Paul Paul K. Reddy Rapporteur for Q.5/16 Intel Corporation, Mailstop:JF3-377 2111 N.E. 25th Avenue, Hillsboro, OR - 97229, USA Office Phone # +1 (503)-264-9896 Mobile Phone # +1 (503)-807-9564 Email: paul.k.reddy(a)intel.com -----Original Message----- From: Roy, Radhika R [mailto:rrroy@ATT.COM] Sent: Monday, May 21, 2001 9:18 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Annex Gv2 Hi, Paul: Let me explain where H.225.0 Annex G may fit with respect to mobility as well as non-mobility as follows: 1. Anything extension that does NOT deal with MOBILITY in H.225.0 Annex G version 2 can be considered for approval. 2. Anything that deals with MOBILITY (or with an intention to support mobility indirectly) in H.225.0 Annex G version 2 MUST NOT be considered for approval because of the following: a. The scope and reference points of mobility Q.5/16 needs to be defined that is consistent with its charter. b. H.MMS.x work will be defined and completed in accordance to item a. c. All applications can use the common protocol for HLF/VLF/AuF (and other value-added services). It will be a new protocol and will NOT have any application-specific name (e.g., H.225.0 Annex G). d. As soon as we complete item c, we will see what needs to be done for H.323. In H.323, we may have to extend H.225.0 RAS + H.225.0 Annex G. These are application-specific extensions to support MOBILITY (applicable for each application as well: H.310, H.324, IMT-2000, etc.). This is what has been proposed by AT&T in all contributions. Hope this will help. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Sunday, May 20, 2001 10:06 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Annex Gv2 Folks, The editor of Annex G has recommended that we not approve Annex G at this meeting, citing that there is insufficient material to warrant approval. I have also heard comments from some that additional work should be done in the area of defining reference point D. Of course, we also have the open question of where (if anywhere) Annex G fits into the H.MMS.x work. For the benefit of those not planning to attend the meeting, please tell me if you would have objections to *not* approving Annex Gv2 at this meeting. Thanks, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Annex Gv2
by Reddy, Paul K 22 May '01

22 May '01

Hi Radhika, With respect to your point on 2a, Q.5/16 has been defined the Objectives, scope, work plan for study period 2001-2004 during last Rapporteur's meeting in Lanceston, Australia. As far as the protocol for H.MMS.1 (Mobility for Multimedia systems based on H.323) recommendation has not been decided as of last meeting. Your contributions and other contributions have come in for Porte Seguro's meeting in Brazil will consider for discussion on Mobility protocols like H.MMS.General (based on H.225.0 AnnexG or other protocol etc.) PS: Paul, I would recommend not to delay the approval of H.225.0 Annex Gv2, if Annex Gv2 does not include the Mobility work. - Paul regards, Paul Paul K. Reddy Rapporteur for Q.5/16 Intel Corporation, Mailstop:JF3-377 2111 N.E. 25th Avenue, Hillsboro, OR - 97229, USA Office Phone # +1 (503)-264-9896 Mobile Phone # +1 (503)-807-9564 Email: paul.k.reddy(a)intel.com -----Original Message----- From: Roy, Radhika R [mailto:rrroy@ATT.COM] Sent: Monday, May 21, 2001 9:18 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Annex Gv2 Hi, Paul: Let me explain where H.225.0 Annex G may fit with respect to mobility as well as non-mobility as follows: 1. Anything extension that does NOT deal with MOBILITY in H.225.0 Annex G version 2 can be considered for approval. 2. Anything that deals with MOBILITY (or with an intention to support mobility indirectly) in H.225.0 Annex G version 2 MUST NOT be considered for approval because of the following: a. The scope and reference points of mobility Q.5/16 needs to be defined that is consistent with its charter. b. H.MMS.x work will be defined and completed in accordance to item a. c. All applications can use the common protocol for HLF/VLF/AuF (and other value-added services). It will be a new protocol and will NOT have any application-specific name (e.g., H.225.0 Annex G). d. As soon as we complete item c, we will see what needs to be done for H.323. In H.323, we may have to extend H.225.0 RAS + H.225.0 Annex G. These are application-specific extensions to support MOBILITY (applicable for each application as well: H.310, H.324, IMT-2000, etc.). This is what has been proposed by AT&T in all contributions. Hope this will help. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Sunday, May 20, 2001 10:06 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Annex Gv2 Folks, The editor of Annex G has recommended that we not approve Annex G at this meeting, citing that there is insufficient material to warrant approval. I have also heard comments from some that additional work should be done in the area of defining reference point D. Of course, we also have the open question of where (if anywhere) Annex G fits into the H.MMS.x work. For the benefit of those not planning to attend the meeting, please tell me if you would have objections to *not* approving Annex Gv2 at this meeting. Thanks, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: Annex Gv2
by Roy, Radhika R 21 May '01

21 May '01

Hi, Paul: Let me explain where H.225.0 Annex G may fit with respect to mobility as well as non-mobility as follows: 1. Anything extension that does NOT deal with MOBILITY in H.225.0 Annex G version 2 can be considered for approval. 2. Anything that deals with MOBILITY (or with an intention to support mobility indirectly) in H.225.0 Annex G version 2 MUST NOT be considered for approval because of the following: a. The scope and reference points of mobility Q.5/16 needs to be defined that is consistent with its charter. b. H.MMS.x work will be defined and completed in accordance to item a. c. All applications can use the common protocol for HLF/VLF/AuF (and other value-added services). It will be a new protocol and will NOT have any application-specific name (e.g., H.225.0 Annex G). d. As soon as we complete item c, we will see what needs to be done for H.323. In H.323, we may have to extend H.225.0 RAS + H.225.0 Annex G. These are application-specific extensions to support MOBILITY (applicable for each application as well: H.310, H.324, IMT-2000, etc.). This is what has been proposed by AT&T in all contributions. Hope this will help. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Sunday, May 20, 2001 10:06 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Annex Gv2 Folks, The editor of Annex G has recommended that we not approve Annex G at this meeting, citing that there is insufficient material to warrant approval. I have also heard comments from some that additional work should be done in the area of defining reference point D. Of course, we also have the open question of where (if anywhere) Annex G fits into the H.MMS.x work. For the benefit of those not planning to attend the meeting, please tell me if you would have objections to *not* approving Annex Gv2 at this meeting. Thanks, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Document for the Porto Seguro meeting
by OKUBO Sakae 21 May '01

21 May '01

Dear Mr. Roy, >Kindly upload the following document: > >"Reply by AT&T on Siemens contribution Comments on AT&T contributions to >Q.5/16" This has been placed at the ftp site as <http://standard.pictel.com/ftp/avc-site/0105_Por/Siemens_ATT_H_MMS_comment s.zip> Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 ********************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Contribution for Porto Seguro Q.5/16 (Mobility)
by Roy, Radhika R 21 May '01

21 May '01

Hi, Everyone: Just to let you know that I have also requested Mr. OKUBO to upload the following contribution: "Reply by AT&T on Siemens contribution - (Comments on AT&T contributions to Q.5/16)" Please see this document if you are interested to see comments provided in response to Mr. Ernst Horvath's contribution "TD-xxx H_MMS_comments." The highlights of the comments can be summarized as follows: 1. Every work item on mobility needs to be scoped that is consistent in the light of the overall big picture of Q.5/16. All inconsistencies need to be removed to fulfill the charter of Q.5/16. 2. All reference points need to be consistent with the overall of goal of Q.5/16 - Mobility. 3. The HLF/VLF/AuF protocol MUST be allowed to be used by all applications. No application-specific name (e.g., H.225.0 Annex G) must be used to limit its use only for one application (e.g., H.323). 4. A common mobility management protocol can be used among the value-added HLF, VLF, and AuF database entities without duplicating the same function for all applications. (It defeats the fundamental basis of the ITU whose principal function is use develop the common standard to reduce the system costs.) 5. All call flows related to mobility that have been under discussion for over two years need to be consistent with the overall objectives of Q.5/16 so that all application can use the same generic principle (without limiting to a given application [e.g., H.323]). 6. The same above principle needs to be used for all other value-added services in mobile environment: Policy, QOS, Billing, Authentication, Accounting, Directory, and others. If you have any questions, please let me know. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Roy, Radhika R Sent: Monday, May 21, 2001 10:16 AM To: 'okubo(a)mxz.mesh.ne.jp' Subject: Document for the Porto Seguro meeting Hi, Mr. OKUBO: Kindly upload the following document: "Reply by AT&T on Siemens contribution Comments on AT&T contributions to Q.5/16" Best Regards, Radhika R. Roy AT&T -----Original Message----- From: Horvath Ernst [mailto:ernst.horvath@SIEMENS.AT] Sent: Monday, May 21, 2001 3:36 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Contribution for Porto Seguro Q.5/16 (Mobility) Dear Mr. Okubo, I uploaded contribution "TD-xxx H_MMS_comments" to the Picturetel Incoming directory. This is for discussion in Q.5/16. Kind Regards, Ernst Horvath Siemens AG ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Contribution for Porto Seguro Q.5/16 (Mobility)
by Horvath Ernst 21 May '01

21 May '01

Dear Mr. Okubo, I uploaded contribution "TD-xxx H_MMS_comments" to the Picturetel Incoming directory. This is for discussion in Q.5/16. Kind Regards, Ernst Horvath Siemens AG ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

The Info You Requested 30273
by sabrina_B＠HWMCPLUS.COM 21 May '01

21 May '01

Long Distance Conference Calls 18 Cents Per Minute! -Connect up to 100 participants -No set up fees or contractual fees -Call anytime, from anywhere, to anywhere -Web, Data, and Video Conferencing Available Why pay more for something you don't have to. Learn More About Conference Calls For Less Here http://marketing201.net/ccfl/ This is not SPAM. You have been emailed this message because you have opted to receive information regarding business opportunities. If you feel that your email address has been used without your consent and wish to be removed, click the following link. We will gladly remove you from our distribution list and apologize for any inconvenience. rem0ve992(a)excite.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Annex Gv2
by Paul E. Jones 20 May '01

20 May '01

Folks, The editor of Annex G has recommended that we not approve Annex G at this meeting, citing that there is insufficient material to warrant approval. I have also heard comments from some that additional work should be done in the area of defining reference point D. Of course, we also have the open question of where (if anywhere) Annex G fits into the H.MMS.x work. For the benefit of those not planning to attend the meeting, please tell me if you would have objections to *not* approving Annex Gv2 at this meeting. Thanks, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Annex M.4 for H248
by OKUBO Sakae 19 May '01

19 May '01

Dear Mr. Sayre, >I have emailed to Mr. Bigi the Temporary Document (editor's draft ) for >Annex M.4 of H.248. I have also uploaded this file, AnnexM4H248.zip, to the >Incoming folder on the Pictel site. Can you please move this file to the >Porto Seguro folder? I have done so. Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 ********************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Switching to H.245
by Francois Audet 18 May '01

18 May '01

Or something like "H.323 entities shall only process the first fastStart element it receives for a call". Thanks guys. > -----Original Message----- > From: Sasha Ruditsky [mailto:sasha@RADVISION.COM] > Sent: Friday, May 18, 2001 12:16 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Switching to H.245 > > > Hi François > > Probably I'll try to state you question in more generic way. > > We know that it is possible to perform OLC operations after fast start > completed > and before another Q.931 message (like ALERTING or CONNECT) > with fast start > is sent. > (the simplest probably is to close channel opened using fast start) > (3rd party pause and redirection is of course procedure of this kind) > > What is the meaning of the fast start in such CONNECT message? > > And here I agree with Chris that such fast start elements > should be ignored. > > So probably the text that may solve this and should be added > should state > something like: > "H.323 entity shall process fast start elements only once > during the call." > > BTW Probably the same statement should be done about > h245Address. I just > know one H.323 endpoint that established 3 H.245 connections > when got the > h245Address in CALL PROCEEDING, ALERTING and CONNECT. > > Sasha > > > > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > Sent: Friday, May 18, 2001 6:56 AM > To: ITU-SG16(a)mailbag.cps.INTEL.COM > Subject: Re: Switching to H.245 > > > Francois, > > Good catch! My suggestion would be to add some text saying > that anything > exchanged via H.245 overrides anything done by fastStart, even if the > fastStart happens to arrive later. > > Now what happens if there's a possible scenario someone can > devise where you > manage to get tunnelled and "separate connection" H.245 > contradicting each > other is a thornier problem - can anyone see that happening? > > Regards, > Chris > > Francois Audet wrote: > > > Hum, interesting. > > > > > > > > My follow up question is then: > > > > * A sends SETUP to B with fast start with h245Address and > > tunnelling. ALERTING responds to FS, and the whole TCS and M/S > > process takes place. Then A wants to forward the call > (internally) > > before answer (i.e., in the ALERTING phase). It thus > sends TCS=0, > > TCS=full, OLCs and all that. Then B answers and sends > the CONNECT > > (with the same fastStart as the ALERTING as per earlier > > discussions we had ;^) Wouldn't the content of the fastStart > > contradict what the actual forwarded connections is > really? Would > > it be a problem? > > > > Seems pretty tricky... > > > > -----Original Message----- > > From: Paul Long [mailto:plong@IPDIALOG.COM] > > Sent: Thursday, May 17, 2001 11:52 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: Switching to H.245 > > > > Francois, > > > > > > > > I realize how this could be confusing, but I don't > necessarily see a > > conflict since they all say, "may." For example, if I > say, "X may do > > A or B," and, "X may do B," that does not preclude "X may do A." > > Conversely, if I said "shall" instead of "may," I think > there would > > be real conflicts. I've worked on EPs that are very aggressive > > during call establishment. For example, Setup contains an > > h245Address and indicates support for Fast Connect and H.245 > > Tunneling. Other than all the non-compliant EPs out > there, it worked > > just fine. The EPs also support third-party pause, but I don't > > remember ever testing that particular scenario. As long > as an EP is > > implemented correctly, I don't see anything in the > Recommendation > > that would prevent this from working. > > > > > > > > Paul Long > > > > ipDialog, Inc. > > > > -----Original Message----- > > From: Mailing list for parties associated with > ITU-T Study Group > > 16 [mailto:ITU-SG16@mailbag.cps.INTEL.COM]On Behalf > Of Francois > > Audet > > Sent: Thursday, May 17, 2001 1:07 PM > > To: ITU-SG16(a)mailbag.cps.INTEL.COM > > Subject: Switching to H.245 > > > > Guys, > > > > > > > > H.323/8.1.7.2 says : > > > > After establishment of a call using the Fast Connect > > procedure, either endpoint may determine that it is > > necessary to invoke call features that require > the use of > > H.245 procedures. Either endpoint may initiate > the use of > > H.245 procedures at any point during the call, using > > tunnelling as described in 8.2..1 (if > h245Tunnelling remains > > enabled) or a separate H.245 connection. The process for > > switching to a separate H.245 connection is described in > 8.2.3. > > > > 8.2..3 says: > > > > When H.245 encapsulation or Fast Connect is being used, > > either endpoint may choose to switch to using > the separate > > H.245 connection at any time. > > > > There seem to be some contradiction in there: is it "after > > establishment" or "at any time"? > > > > > > > > Do you have to wait for after CONNECT to establish > a separate > > H.245 channel or not? > > > > > > > > The case I'm interested in would be to send SETUP with > > fastStart, then receive ALERTING with fastStart. > Then can either > > end initiate H.245 before CONNECT? If so, what if > third party > > pause and redirection is initiated before CONNECT? > > > > > > > > ---- > > > > François AUDET, Nortel Networks > > > > mailto:audet@nortelnetworks.com, tel:+1 408 495 3756 > > > > > > > > > -- > Dr Chris Purvis -- Development Manager > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > Winkfield Row, Berkshire. RG42 6LY ENGLAND > Phone: +44 1344 899 007 > Fax: +44 1344 899 001 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com >

1 0

Re: Switching to H.245
by Sasha Ruditsky 18 May '01

18 May '01

Hi François Probably I'll try to state you question in more generic way. We know that it is possible to perform OLC operations after fast start completed and before another Q.931 message (like ALERTING or CONNECT) with fast start is sent. (the simplest probably is to close channel opened using fast start) (3rd party pause and redirection is of course procedure of this kind) What is the meaning of the fast start in such CONNECT message? And here I agree with Chris that such fast start elements should be ignored. So probably the text that may solve this and should be added should state something like: "H.323 entity shall process fast start elements only once during the call." BTW Probably the same statement should be done about h245Address. I just know one H.323 endpoint that established 3 H.245 connections when got the h245Address in CALL PROCEEDING, ALERTING and CONNECT. Sasha -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Friday, May 18, 2001 6:56 AM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: Switching to H.245 Francois, Good catch! My suggestion would be to add some text saying that anything exchanged via H.245 overrides anything done by fastStart, even if the fastStart happens to arrive later. Now what happens if there's a possible scenario someone can devise where you manage to get tunnelled and "separate connection" H.245 contradicting each other is a thornier problem - can anyone see that happening? Regards, Chris Francois Audet wrote: > Hum, interesting. > > > > My follow up question is then: > > * A sends SETUP to B with fast start with h245Address and > tunnelling. ALERTING responds to FS, and the whole TCS and M/S > process takes place. Then A wants to forward the call (internally) > before answer (i.e., in the ALERTING phase). It thus sends TCS=0, > TCS=full, OLCs and all that. Then B answers and sends the CONNECT > (with the same fastStart as the ALERTING as per earlier > discussions we had ;^) Wouldn't the content of the fastStart > contradict what the actual forwarded connections is really? Would > it be a problem? > > Seems pretty tricky... > > -----Original Message----- > From: Paul Long [mailto:plong@IPDIALOG.COM] > Sent: Thursday, May 17, 2001 11:52 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Switching to H.245 > > Francois, > > > > I realize how this could be confusing, but I don't necessarily see a > conflict since they all say, "may." For example, if I say, "X may do > A or B," and, "X may do B," that does not preclude "X may do A." > Conversely, if I said "shall" instead of "may," I think there would > be real conflicts. I've worked on EPs that are very aggressive > during call establishment. For example, Setup contains an > h245Address and indicates support for Fast Connect and H.245 > Tunneling. Other than all the non-compliant EPs out there, it worked > just fine. The EPs also support third-party pause, but I don't > remember ever testing that particular scenario. As long as an EP is > implemented correctly, I don't see anything in the Recommendation > that would prevent this from working. > > > > Paul Long > > ipDialog, Inc. > > -----Original Message----- > From: Mailing list for parties associated with ITU-T Study Group > 16 [mailto:ITU-SG16@mailbag.cps.INTEL.COM]On Behalf Of Francois > Audet > Sent: Thursday, May 17, 2001 1:07 PM > To: ITU-SG16(a)mailbag.cps.INTEL.COM > Subject: Switching to H.245 > > Guys, > > > > H.323/8.1.7.2 says : > > After establishment of a call using the Fast Connect > procedure, either endpoint may determine that it is > necessary to invoke call features that require the use of > H.245 procedures. Either endpoint may initiate the use of > H.245 procedures at any point during the call, using > tunnelling as described in 8.2..1 (if h245Tunnelling remains > enabled) or a separate H.245 connection. The process for > switching to a separate H.245 connection is described in 8.2.3. > > 8.2..3 says: > > When H.245 encapsulation or Fast Connect is being used, > either endpoint may choose to switch to using the separate > H.245 connection at any time. > > There seem to be some contradiction in there: is it "after > establishment" or "at any time"? > > > > Do you have to wait for after CONNECT to establish a separate > H.245 channel or not? > > > > The case I'm interested in would be to send SETUP with > fastStart, then receive ALERTING with fastStart. Then can either > end initiate H.245 before CONNECT? If so, what if third party > pause and redirection is initiated before CONNECT? > > > > ---- > > François AUDET, Nortel Networks > > mailto:audet@nortelnetworks.com, tel:+1 408 495 3756 > > > -- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

AW: Gatekeeper behavior question
by Guntram Diehl 18 May '01

18 May '01

Hi Hans, yes, you have to map IP address + port to an alias. The H.323 standard only talks about "transport addresses" which have to be mapped. And a transport address in the IP case consists of addr+port. Guntram > -----Ursprüngliche Nachricht----- > Von: Hans Viens [mailto:hviens@MEDIATRIX.COM] > Gesendet: Freitag, 18. Mai 2001 14:48 > An: ITU-SG16(a)MAILBAG.INTEL.COM > Betreff: Gatekeeper behavior question > > > Hi folks! > > I just want to pin point a place on the H.323 standard that > talk about the > behavior of a gatekeeper on a specific scenario. My question is: Is it > mandatory for a gatekeeper to accept the registration of a > unit using 1 IP > address and supporting mutiple H.323 endpoint (multiple > ports) (i.e EP1: > 192.168.0.1:2000; EP2: 192.168.0.1:2001 ... ) ? Also, is it > mandatory for a > gatekeeper to translate the alias of an endpoint with both > its IP address & > port number ? > > If you could help me to point me to a section in the H.323 > standard, I would > appreciate it! > > Regards, > > Hans > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: AW: Gatekeeper behavior question
by Frank Derks 18 May '01

18 May '01

Hans, H.323 describes this situation in section 7.2.2. If the aliases _and_ the transport addresses (i.e. IP address + TCP port) are distinct, then the Gatekeeper is able to distinguish the two as really being different. If _either_ the aliases _or_ the transport addresses are identical then it is up to the Gatekeeper implementation to decide what to do. If the alias is the same (and the transport address is not), it is up to the Gatekeeper to decide to accept or reject the registration. If the transport address is the same (and the alias is not), it is advisable to replace the previous registration with the new one. Regards, Frank gdiehl@INNOVAPHONE.COM@SMTP@MAILBAG.INTEL.COM on 18-05-2001 15:39:11 Please respond to gdiehl@INNOVAPHONE.COM@SMTP Sent by: ITU-SG16(a)MAILBAG.INTEL.COM To: ITU-SG16@MAILBAG.INTEL.COM@SMTP cc: Subject: AW: Gatekeeper behavior question Classification: Hi Hans, yes, you have to map IP address + port to an alias. The H.323 standard only talks about "transport addresses" which have to be mapped. And a transport address in the IP case consists of addr+port. Guntram > -----Ursprüngliche Nachricht----- > Von: Hans Viens [mailto:hviens@MEDIATRIX.COM] > Gesendet: Freitag, 18. Mai 2001 14:48 > An: ITU-SG16(a)MAILBAG.INTEL.COM > Betreff: Gatekeeper behavior question > > > Hi folks! > > I just want to pin point a place on the H.323 standard that > talk about the > behavior of a gatekeeper on a specific scenario. My question is: Is it > mandatory for a gatekeeper to accept the registration of a > unit using 1 IP > address and supporting mutiple H.323 endpoint (multiple > ports) (i.e EP1: > 192.168.0.1:2000; EP2: 192.168.0.1:2001 ... ) ? Also, is it > mandatory for a > gatekeeper to translate the alias of an endpoint with both > its IP address & > port number ? > > If you could help me to point me to a section in the H.323 > standard, I would > appreciate it! > > Regards, > > Hans > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Gatekeeper behavior question
by Hans Viens 18 May '01

18 May '01

Hi folks! I just want to pin point a place on the H.323 standard that talk about the behavior of a gatekeeper on a specific scenario. My question is: Is it mandatory for a gatekeeper to accept the registration of a unit using 1 IP address and supporting mutiple H.323 endpoint (multiple ports) (i.e EP1: 192.168.0.1:2000; EP2: 192.168.0.1:2001 ... ) ? Also, is it mandatory for a gatekeeper to translate the alias of an endpoint with both its IP address & port number ? If you could help me to point me to a section in the H.323 standard, I would appreciate it! Regards, Hans ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Switching to H.245
by Francois Audet 18 May '01

18 May '01

Hum, interesting. My follow up question is then: * A sends SETUP to B with fast start with h245Address and tunnelling. ALERTING responds to FS, and the whole TCS and M/S process takes place. Then A wants to forward the call (internally) before answer (i.e., in the ALERTING phase). It thus sends TCS=0, TCS=full, OLCs and all that. Then B answers and sends the CONNECT (with the same fastStart as the ALERTING as per earlier discussions we had ;^) Wouldn't the content of the fastStart contradict what the actual forwarded connections is really? Would it be a problem? Seems pretty tricky... -----Original Message----- From: Paul Long [mailto:plong@IPDIALOG.COM] Sent: Thursday, May 17, 2001 11:52 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Switching to H.245 Francois, I realize how this could be confusing, but I don't necessarily see a conflict since they all say, "may." For example, if I say, "X may do A or B," and, "X may do B," that does not preclude "X may do A." Conversely, if I said "shall" instead of "may," I think there would be real conflicts. I've worked on EPs that are very aggressive during call establishment. For example, Setup contains an h245Address and indicates support for Fast Connect and H.245 Tunneling. Other than all the non-compliant EPs out there, it worked just fine. The EPs also support third-party pause, but I don't remember ever testing that particular scenario. As long as an EP is implemented correctly, I don't see anything in the Recommendation that would prevent this from working. Paul Long ipDialog, Inc. -----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@mailbag.cps.INTEL.COM]On Behalf Of Francois Audet Sent: Thursday, May 17, 2001 1:07 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Switching to H.245 Guys, H.323/8.1.7.2 says : After establishment of a call using the Fast Connect procedure, either endpoint may determine that it is necessary to invoke call features that require the use of H.245 procedures. Either endpoint may initiate the use of H.245 procedures at any point during the call, using tunnelling as described in 8.2.1 (if h245Tunnelling remains enabled) or a separate H.245 connection. The process for switching to a separate H.245 connection is described in 8.2.3. 8.2.3 says: When H.245 encapsulation or Fast Connect is being used, either endpoint may choose to switch to using the separate H.245 connection at any time. There seem to be some contradiction in there: is it "after establishment" or "at any time"? Do you have to wait for after CONNECT to establish a separate H.245 channel or not? The case I'm interested in would be to send SETUP with fastStart, then receive ALERTING with fastStart. Then can either end initiate H.245 before CONNECT? If so, what if third party pause and redirection is initiated before CONNECT? ---- François AUDET, Nortel Networks mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> , tel:+1 408 495 3756

2 1

Switching to H.245
by Francois Audet 17 May '01

17 May '01

Guys, H.323/8.1.7.2 says : After establishment of a call using the Fast Connect procedure, either endpoint may determine that it is necessary to invoke call features that require the use of H.245 procedures. Either endpoint may initiate the use of H.245 procedures at any point during the call, using tunnelling as described in 8.2.1 (if h245Tunnelling remains enabled) or a separate H.245 connection. The process for switching to a separate H.245 connection is described in 8.2.3.<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /> 8.2.3 says: When H.245 encapsulation or Fast Connect is being used, either endpoint may choose to switch to using the separate H.245 connection at any time. There seem to be some contradiction in there: is it "after establishment" or "at any time"? Do you have to wait for after CONNECT to establish a separate H.245 channel or not? The case I'm interested in would be to send SETUP with fastStart, then receive ALERTING with fastStart. Then can either end initiate H.245 before CONNECT? If so, what if third party pause and redirection is initiated before CONNECT? ---- François AUDET, Nortel Networks mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> , tel:+1 408 495 3756

2 1

Documents for the Porto Seguro meeting
by OKUBO Sakae 17 May '01

17 May '01

Dear SG16 experts, For your review, the following 7 documents have been placed at http://standard.pictel.com/ftp/avc-site/0105_Por/ Draft_H323_Annex_O.zip -- Draft H.323 Annex O by the Editor sip-for-video.zip -- Sip for video from delegation of Israel H323_the_need_for_presence.doc -- The imperative need for Presence functionality in various H.323 Systems from delegation of Israel H323_to_enable_presence.doc -- Alternatives for delivery of Presence Information from and to H.323 End Users from delegation of Israel End_to_End_QoS_Control_H323.zip -- SOURCE: Mike Buckley, Rapporteur Q.F/16 TITLE: An Application Level Control of End-to-End QOS Annex_N_May_2001.zip -- SOURCE: Mike Buckley, Editor H.323 Annex N. TITLE: New draft of H.323 Annex N TD-xxx_AnnexR.zip SOURCE: Rapporteur Q.2/16 (P. Jones) TITLE: H.323 Annex R: Robustness Methods for H.323 Entities Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 ********************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: RTCP support in H.248? [RE: RTCP support in H.323]
by Tom-PT Taylor 17 May '01

17 May '01

H.248/Megaco does not have to mention RTCP because support of RTCP at the Media Gateway is implicit. There are a number of statistics related to the RTP package which would be very difficult to gather without the use of RTCP. > -----Original Message----- > From: Horvath Ernst [mailto:ernst.horvath@SIEMENS.AT] > Sent: Thursday, May 17, 2001 4:53 AM > To: ITU-SG16(a)mailbag.cps.INTEL.COM > Subject: RTCP support in H.248? [RE: RTCP support in H.323] > > > And what is the situation in H.248/Megaco? I did not find any > reference to > RTCP in this recommendation. > > Ernst Horvath > Siemens AG > > -----Ursprüngliche Nachricht----- > Von: Rex Coldren [mailto:coldrenr@agcs.com] > Gesendet am: Dienstag, 08. Mai 2001 19:40 > An: ITU-SG16(a)mailbag.cps.INTEL.COM > Betreff: RTCP support in H.323 > All, > I'll be lazy and ask rather than looking through the ASN.1 > to find it... > Is there support in H.323 for signaling to use RTCP? > > There is a current thread on the IETF AVT e-mail reflector where > talk is of making RTCP mandatory (i.e.-changing it from a SHOULD > to a MUST in the RTP specification). The last I heard was that the > MUST would apply to implementing RTCP, and not necessarily to > using it. Presumably the application level call signaling > protocol can > be responsible for signaling whether RTCP was to be used. > > If an endpoint implemented RTCP it should at least benignly ignore > received RTCP reports and would not need to send any. So a given > operator could specify that RTCP not be signaled if it were not > practical in their network. Obvious examples would be wireless > networks and cable networks where there are access bandwidth > constraints. > > > Cheers, > Rex > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com >

1 0

RTCP support in H.248? [RE: RTCP support in H.323]
by Horvath Ernst 17 May '01

17 May '01

And what is the situation in H.248/Megaco? I did not find any reference to RTCP in this recommendation. Ernst Horvath Siemens AG -----Ursprüngliche Nachricht----- Von: Rex Coldren [mailto:coldrenr@agcs.com] Gesendet am: Dienstag, 08. Mai 2001 19:40 An: ITU-SG16(a)mailbag.cps.INTEL.COM Betreff: RTCP support in H.323 All, I'll be lazy and ask rather than looking through the ASN.1 to find it... Is there support in H.323 for signaling to use RTCP? There is a current thread on the IETF AVT e-mail reflector where talk is of making RTCP mandatory (i.e.-changing it from a SHOULD to a MUST in the RTP specification). The last I heard was that the MUST would apply to implementing RTCP, and not necessarily to using it. Presumably the application level call signaling protocol can be responsible for signaling whether RTCP was to be used. If an endpoint implemented RTCP it should at least benignly ignore received RTCP reports and would not need to send any. So a given operator could specify that RTCP not be signaled if it were not practical in their network. Obvious examples would be wireless networks and cable networks where there are access bandwidth constraints. Cheers, Rex ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Annex R TD
by Terry L Anderson 16 May '01

16 May '01

I have submitted the latest draft of H.323 Annex R to the TSB to be included as a rapporteur's TD. But to give earlier access, I have also uploaded it to the incoming directory of the avc-site. TD-xxx_AnnexR.doc Mr Okubo - there is a similarly named file "TDxxx-AnnexR.doc" in the incoming directory that failed to completely upload and should be discarded. -- ------------------------------------------------------------ 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: H.248 TerminationID
by Tom-PT Taylor 16 May '01

16 May '01

I'm afraid we don't have an FAQ yet, though it's probably time to start one. Most questions of this sort get asked on the Megaco list <megaco(a)fore.com>. Anyway, the syntax for a text terminationID requires that it start with an ALPHA, possibly preceded by a "*" wildcard. The basic idea is that you can combine "*" or "$" wildcards with string segments to request selection of all terminations matching the pattern ("*") or any one termination matching the pattern ("$") as the case may be. > -----Original Message----- > From: Leano, Bob [mailto:Bob.Leano@ICN.SIEMENS.COM] > Sent: Tuesday, May 15, 2001 12:27 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.248 TerminationID > > > The megaco call flow examples do not give a rendition for > creating the TerminationId field which consist of a wildcard > and an Id. If I want to specify a particular id, say 1234, and > not want to specify a choose or all, what should my wildcard be? > > Is there an ftp site that clarifies implementation questions > like mine? > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com >

1 0

Tow documents uploaded
by OKUBO Sakae 16 May '01

16 May '01

Dear CHAPRON Jean-Emmanuel, Takashi Suzuki and all, The following two contributions have been placed at the Porto Seguro meeting directory of the ftp site: SOURCE: Rapporteur for Q.3/16 TITLE: H.248 packages for transmission of data over analog lines http://standard.pictel.com/ftp/avc-site/0105_Por/TD_H248_package_analog_lin e.zip SOURCE: NTT DoCoMo, Inc. TITLE: Proposal for the new Annex M.4/H.248 http://standard.pictel.com/ftp/avc-site/0105_Por/Delayed_H248AnnexM4.zip Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 ********************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Comments on H.245v8 & H.263 Annex X
by Dave Lindbergh 15 May '01

15 May '01

Mike/all, A couple of minor comments on the draft H.245v8 in GEN-009 for Brazil: 1) We've some concern that, given the complexity of the current (pre-v8) H.263 caps, a "new vendor" unfamiliar with the history of H.245 and H.263 will be tempted to signal _only_ the new Annex X/H.263 Generic Caps (H.263 profiles) instead of the existing H.263 caps that all current equipment use. If this happens, a video call will fall back all the way to H.261. To avoid this, I suggest adding the following as a "Note" to the H.263 generic cap in Table VIII.1/H.245: <begin text> Note - Use of this capability to signal H.263 "Profiles and Levels" per Annex X/H.263 should always be accompanied in parallel by the signaling of the same modes in H263VideoCapability. This is necessary to ensure that systems which do not recognize the H.263 generic capabilities continue to interwork with newer systems. <end text> I think this is an issue _only_ for H.245, and not for Annex X/H.263 in general, since any new use of H.263 (not involving H.245) will have no such backward-compatibility issue. 2) In the title for Table VIII.1/H.245, the words "capability" and "organizations" are misspelled. If you (as editor) and the list members agree, I suggest these be included in a "corrections" TD for Brazil. Regards, --Dave Lindbergh, PictureTel Corp. ------------------------------------------------------------------- Dave Lindbergh Email: lindbergh(a)pictel.com PictureTel Corporation Voice: +1 978 292 4351 100 Minuteman Road, MS 713 Fax: +1 978 292 3328 Andover MA 01810 USA H.320 video by arrangement PGP fingerprint: C8 3E 28 69 53 0A 4B 87 EF E0 11 CD AC 87 4D CD ------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H.248 TerminationID
by Leano, Bob 15 May '01

15 May '01

The megaco call flow examples do not give a rendition for creating the TerminationId field which consist of a wildcard and an Id. If I want to specify a particular id, say 1234, and not want to specify a choose or all, what should my wildcard be? Is there an ftp site that clarifies implementation questions like mine? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0