- sg16-avd - lists.packetizer.com

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

Including RTCP report packets in IRR
by frank.derks＠PHILIPS.COM 28 Dec '01

28 Dec '01

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

3 4

FW: Including RTCP report packets in IRR
by Alan Clark 28 Dec '01

28 Dec '01

Paul/ Roni I tried posting this to the SG16 reflector but it didn't get sent out ....... Alan -----Original Message----- From: Alan Clark [mailto:alan@telchemy.com] Sent: Wednesday, December 26, 2001 9:36 AM To: 'ITU-SG16(a)echo.jf.INTEL.COM' Subject: RE: Including RTCP report packets in IRR Paul/ Roni/ Frank We have been introducing this general topic via ETSI TIPHON and more recently presented at the IETF-52 AVT session. We believe that RTCP stats are not sufficient for VoIP purposes and also share the concern expressed by others on this thread that it is vital to have several approaches to getting data from the endpoints. The approach we advocate is:- (i) Calculate call quality metrics in the endpoint It is necessary to consider the "burstiness" of packet loss in order to assess impact on VoIP call quality - PLC is effective at hiding isolated lost packets but not bursts. VQmon (ETSI TS101 329-5 Annex E) is a lightweight E model based algorithm for estimating call quality that incorporates a burst packet loss model. (ii) Recognize that there are several "audiences" for the data In some networks both the network operations/ management and billing groups would like to have access to call quality data however their requirements are different. - operations/management .. real time event reporting, SNMP access, test and diagnosis .. may need access to data during a call .. needs support for fault isolation - billing .. end of call metrics .. feed back through end of call messages (iii) Provide several ways to get data out We would like to see multiple ways of extracting data both from the end-points and mid-flow. These should include extended RTCP reports with call quality metrics, end of call (DRQ or equivalent) and SNMP access. Alan Clark Telchemy -----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@echo.jf.INTEL.COM]On Behalf Of Even ,Roni Sent: Tuesday, December 25, 2001 9:33 AM To: ITU-SG16(a)echo.jf.INTEL.COM 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 >

2 1

Re: Including RTCP report packets in IRR
by Even ,Roni 28 Dec '01

28 Dec '01

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 > > >

2 1

RE: New draft of H.MMS.1
by Roy, Radhika R, ALCTA 28 Dec '01

28 Dec '01

Hi, Paul: You are right that I am proposing the generic protocol only for item 1 (not for items 2 and 3). This has been the main thrust of all my contributions over the years. People may not have enough time to go through all of my contributions/proposals in detail. It is a win-win situation for all of us. If anyone has any concerns, I will always be available to explain in depth. I appreciate your support. Best regards, Radhika +1 732 420 1580 rrroy(a)att.com -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Wednesday, December 26, 2001 11:46 PM To: Roy, Radhika R, ALCTA; Vivek Bhargava; Klaghofer Karl ICN EN HC ID 14; Horvath Ernst Siemens AT; Paul K'; BOUGANT Francois FTRD/DAC/ISS; Miner Gleason; Euchner Martin ICN M SR 3 Cc: Vivek Bhargava; Orit Levin Subject: Re: New draft of H.MMS.1 Radhika, As you know, I've not been able to be present at all of the mobility meetings, but I thought that you had championed the idea of having a generic protocol for at least (2) below, rather than using Annex G-- I suppose I didn't pay enough attention. So, your proposing that only (1) be new and generic, while the others be realized by extending the existing protocols. I'd agree with that approach. Paul ----- Original Message ----- From: "Roy, Radhika R, ALCTA" <rrroy(a)att.com> To: "Vivek Bhargava" <vbhargava(a)cisco.com>; "Paul E. Jones" <paulej(a)packetizer.com>; "Klaghofer Karl ICN EN HC ID 14" <Karl.Klaghofer(a)icn.siemens.de>; "Horvath Ernst Siemens AT" <ernst.horvath(a)siemens.at>; "Paul K'" <paul.k.reddy(a)intel.com>; "BOUGANT Francois FTRD/DAC/ISS" <francois.bougant(a)rd.francetelecom.com>; "Miner Gleason" <mgleason(a)cisco.com>; "Euchner Martin ICN M SR 3" <Martin.Euchner(a)icn.siemens.de> Cc: "Vivek Bhargava" <vbharga(a)cisco.com>; "Orit Levin" <orit(a)radvision.com> Sent: Wednesday, December 26, 2001 10:41 AM Subject: RE: New draft of H.MMS.1 > Hi, Paul, Vivek, and All: > > Let me clarify again as follows: > > 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? > > I like to see more discussion on this. > > Best regards, > > Radhika R. Roy > rrroy(a)att.com > > -----Original Message----- > From: Vivek Bhargava [mailto:vbhargava@cisco.com] > Sent: Monday, December 24, 2001 9:10 PM > To: Paul E. Jones; Roy, Radhika R, ALCTA; Klaghofer Karl ICN EN HC ID > 14; Horvath Ernst Siemens AT; Paul K'; BOUGANT Francois FTRD/DAC/ISS; > Miner Gleason; Euchner Martin ICN M SR 3 > Cc: Vivek Bhargava; Orit Levin > Subject: Re: New draft of H.MMS.1 > > > I think a new protocol will be inevitable if the VLF and HLF functions are > separated from the BE. If it is always assumed to be co-located with the BE > then H.225 AnnexG can be extended to cover those. > > Vivek. > > ----- Original Message ----- > From: "Paul E. Jones" <paulej(a)packetizer.com> > To: "Roy, Radhika R, ALCTA" <rrroy(a)att.com>; "Klaghofer Karl ICN EN HC ID > 14" <Karl.Klaghofer(a)icn.siemens.de>; "Horvath Ernst Siemens AT" > <ernst.horvath(a)siemens.at>; "Paul K'" <paul.k.reddy(a)intel.com>; "BOUGANT > Francois FTRD/DAC/ISS" <francois.bougant(a)rd.francetelecom.com>; "Miner > Gleason" <mgleason(a)cisco.com>; "Euchner Martin ICN M SR 3" > <Martin.Euchner(a)icn.siemens.de> > Cc: "Vivek Bhargava" <vbharga(a)cisco.com>; "Orit Levin" <orit(a)radvision.com> > Sent: Sunday, December 23, 2001 9:48 PM > Subject: Re: New draft of H.MMS.1 > > > > Radhika, > > > > Now I'm terribly confused... I thought you wanted us to develop a generic > > mobility protocol (or set of protocols) that were not explicitly tied to > > H.323. In this message, you're proposing that we simply extend the > > H.323-based protocols. Did I miss something? > > > > Paul > > > > ----- Original Message ----- > > From: "Roy, Radhika R, ALCTA" <rrroy(a)att.com> > > To: "Klaghofer Karl ICN EN HC ID 14" <Karl.Klaghofer(a)icn.siemens.de>; > "Paul > > E. Jones" <paulej(a)packetizer.com>; "Horvath Ernst Siemens AT" > > <ernst.horvath(a)siemens.at>; "Paul K'" <paul.k.reddy(a)intel.com>; "BOUGANT > > Francois FTRD/DAC/ISS" <francois.bougant(a)rd.francetelecom.com>; "Miner > > Gleason" <mgleason(a)cisco.com>; "Euchner Martin ICN M SR 3" > > <Martin.Euchner(a)icn.siemens.de> > > Cc: "Vivek Bhargava" <vbharga(a)cisco.com>; "Orit Levin" > <orit(a)radvision.com> > > Sent: Saturday, December 22, 2001 11:59 AM > > Subject: RE: New draft of H.MMS.1 > > > > > > > Hi, Paul and All: > > > > > > I think that Karl's approach is opening up a big debate what has been > > going on for many years and, some AT&T contributions made over the years > can > > also be looked into. Other contributions including Intel's can also be > > looked into in this area. > > > > > > What Paul has suggested is the DHCP-based "Discovery" of the GK. It is > in > > generic sense, not so much specific about the mobile or non-mobile > > environment. I would consider Paul's suggestion has a different flavor and > > let us continue discussion along this line what is used in the generic > > Internet. > > > > > > With respect H.22x, I have few questions. I do not know whether we > really > > want to have a separate protocol to achieve the objectives. In the last > > conference call, we have seen that the objective this protocol is NOT > clear > > because we have a protocol that is used among the BEs that is known as > > H.225.0 Annex G. We have also a protocol that is used among the GKs and it > > is known as H.225.0 RAS. So, why do we need a separate protocol like H.22x > > that to be used among the BEs? It will create more confusions. > > > > > > So, the proposal is as follows: > > > > > > 1. H.225.0 RAS and Q.931 is used among the GKs and no new protocol will > be > > developed that will be used among the GKs. Rather the same H.225.0 RAS and > > Q.931 protocol needs to be extended to serve the purposes for both > > non-mobile and mobile cases. (If we do not follow this fundamental concept > > of the protocol development, we will create more confusions.) Some > > contributions are already there (made over the years). > > > > > > 2. H.225.0 Annex G is used among the BEs and no new protocol will be > > developed that will be used among the BEs. Rather the same H.225.0 Annex G > > protocol needs to be extended to serve the purposes for both non-mobile > and > > mobile cases. (If we do not follow this fundamental concept of the > protocol > > development, we will create more confusions.) > > > > > > > > > Comments on H.22x: > > > > > > 1. We have seen the contributions on H.22x and we discussed this in the > > last conference call. We have seen that this does not justify that we need > > to develop a separate NEW protocol. Rather the same objectives can be > > achieved extending H.225.0 Annex G in its address parameters. Only couple > of > > more alias addresses are needed to be added in H.225.0 Annex G. > > > > > > 2. For security, we have seen that it needs to be global one. That is, > the > > whole security model needs to address both mobile and non-mobile > situations > > equally along with all other message sets other than AccessRequest. > > > > > > 3. We have NOT seen a single justification why we need separate > protocols > > like H.22x among the GKs or BEs while we have exiting protocols? > > > > > > I like to see technical justifications why we need a separate protocols > > like H.22x among the BEs or GKs. > > > > > > Best regards, > > > > > > Radhika R. Roy > > > rrroy(a)att.com > > > > > > -----Original Message----- > > > From: Klaghofer Karl ICN EN HC ID 14 > > > [mailto:Karl.Klaghofer@icn.siemens.de] > > > Sent: Tuesday, December 18, 2001 3:10 AM > > > To: Roy, Radhika R, ALCTA; Paul E. Jones; Horvath Ernst Siemens AT; Paul > > > K'; BOUGANT Francois FTRD/DAC/ISS; Miner Gleason; Euchner Martin ICN M > > > SR 3 > > > Cc: Vivek Bhargava; Orit Levin > > > Subject: AW: New draft of H.MMS.1 > > > > > > > > > Hi to all, > > > > > > Another way of locating a GK which should be covered by the standard - > > > especially for User Mobility - is that the RRQ is first sent to the GK > > that > > > served this endpoint previously (last serving GK). This GK then > determines > > > typically based on User ID and Password entered by the mobile user which > > GK > > > to serve the mobile user (home gk). H.323 Alternate GK procedures are > then > > > used to redirect registration to the home gk, if required. > > > > > > This works for Mobility within an administrative domain, where it is > > anyway > > > easier to let the home gk serve the mobile user. > > > > > > This also works for inter-domain communication with the difference that > > the > > > mobile user is not redirected to the home gk but served by the visited > gk. > > > Of course the visited gk has to find out the home domain to tell the new > > > location update via H.22x. > > > > > > Regards, > > > Karl > > > > > > -----Ursprüngliche Nachricht----- > > > Von: Roy, Radhika R, ALCTA [mailto:rrroy@att.com] > > > Gesendet am: Dienstag, 18. Dezember 2001 02:04 > > > An: Paul E. Jones; Horvath Ernst Siemens AT; Paul K'; BOUGANT Francois > > > FTRD/DAC/ISS; Miner Gleason; Euchner Martin ICN M SR 3 > > > Cc: Klaghofer Karl ICN EN HC ID 14; Vivek Bhargava; Orit Levin > > > Betreff: RE: New draft of H.MMS.1 > > > > > > Hi, Paul: > > > > > > I think that you have made a good point. Let us see whether the use of > > DHCP > > > will have any problems. > > > > > > Comments on Paul's proposal are highly welcomed. > > > > > > Best regards, > > > Radhika > > > > > > -----Original Message----- > > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > > Sent: Sunday, December 16, 2001 9:34 PM > > > To: Horvath Ernst; 'Paul K''; 'BOUGANT Francois FTRD/DAC/ISS'; 'Miner > > > Gleason'; Roy, Radhika R, ALCTA; EUCHNER MARTIN > > > Cc: KLAGHOFER KARL; Vivek Bhargava; Orit Levin > > > Subject: Re: New draft of H.MMS.1 > > > > > > > > > In the area where we describe GK discovery, I'd really like to see us > > expand > > > on the use of DHCP. As you know, DHCP can provide a device with all > sorts > > > of parameters, from the domain name of the network, to DNS servers, to > its > > > IP addresses, to default gateways, etc. It would be nice to see if we > > could > > > somehow signal what the GK (or list of GKs) should be for any H.323 > > device. > > > Failing that, we could propose that endpoints try to locate a GK by > > looking > > > for an SRV record for "_h323_gk_". The endpoint could send an RRQ to > that > > > device and that device could send an RRJ with a list of alternate GKs if > > it > > > wishes to redirect the GK to a specific GK for registration. > > > > > > One thing I would prefer not to use are the TXT records. We're > proposing > > to > > > use SRV records in Annex O for resolving H.323 URLs. I'd like to stick > > with > > > the SRV for registration if DHCP assignment is not an option. The > > > description of SRV records and TXT records in H.225.0 is in an > informative > > > section of H.225.0 that, in my opinion, we should consider removing from > > the > > > Recommendation... does it give us any value at this point? > > > > > > Paul > > > > > > ----- Original Message ----- > > > From: "Horvath Ernst" <ernst.horvath(a)siemens.at> > > > To: "'Paul K''" <paul.k.reddy(a)intel.com>; "'BOUGANT Francois > > FTRD/DAC/ISS'" > > > <francois.bougant(a)rd.francetelecom.com>; "'Miner Gleason'" > > > <mgleason(a)cisco.com>; "'ALCOO''" <rrroy(a)ATT.COM>; "EUCHNER MARTIN" > > > <Martin.Euchner(a)icn.siemens.de> > > > Cc: "KLAGHOFER KARL" <Karl.Klaghofer(a)icn.siemens.de>; "'Paul E. Jones'" > > > <paulej(a)PACKETIZER.COM> > > > Sent: Friday, December 14, 2001 8:06 AM > > > Subject: New draft of H.MMS.1 > > > > > > > > > > Dear mobility experts, > > > > > > > > sorry for sending such a large file by mail, but the picturetel server > > > keeps > > > > refusing me. > > > > > > > > Attached is an updated draft as input to next week's phone conference. > > It > > > > obsoletes AVD-2139rev1 from the last conference call. Revision marks > in > > > this > > > > document are against the original AVD-2139, not against AVD-2139rev1. > > > > > > > > Regards, > > > > Ernst > > > > > > > > > > > > > >

1 0

Re: Including RTCP report packets in IRR
by Even ,Roni 27 Dec '01

27 Dec '01

Alan, This is a good description of the requirements. The question I had was how to convey it to the mid-flow entity who do not have access to the RTCP. Is it by IRR which is H.323 specific or do we need something that will work both for H.323 and SIP. Roni -----Original Message----- From: Alan Clark [mailto:alan@telchemy.com] Sent: Thursday, December 27, 2001 5:42 PM To: paulej(a)packetizer.com; Roni Even (E-mail) Subject: FW: Including RTCP report packets in IRR Paul/ Roni I tried posting this to the SG16 reflector but it didn't get sent out ....... Alan -----Original Message----- From: Alan Clark [mailto:alan@telchemy.com] Sent: Wednesday, December 26, 2001 9:36 AM To: 'ITU-SG16(a)echo.jf.INTEL.COM' Subject: RE: Including RTCP report packets in IRR Paul/ Roni/ Frank We have been introducing this general topic via ETSI TIPHON and more recently presented at the IETF-52 AVT session. We believe that RTCP stats are not sufficient for VoIP purposes and also share the concern expressed by others on this thread that it is vital to have several approaches to getting data from the endpoints. The approach we advocate is:- (i) Calculate call quality metrics in the endpoint It is necessary to consider the "burstiness" of packet loss in order to assess impact on VoIP call quality - PLC is effective at hiding isolated lost packets but not bursts. VQmon (ETSI TS101 329-5 Annex E) is a lightweight E model based algorithm for estimating call quality that incorporates a burst packet loss model. (ii) Recognize that there are several "audiences" for the data In some networks both the network operations/ management and billing groups would like to have access to call quality data however their requirements are different. - operations/management .. real time event reporting, SNMP access, test and diagnosis .. may need access to data during a call .. needs support for fault isolation - billing .. end of call metrics .. feed back through end of call messages (iii) Provide several ways to get data out We would like to see multiple ways of extracting data both from the end-points and mid-flow. These should include extended RTCP reports with call quality metrics, end of call (DRQ or equivalent) and SNMP access. Alan Clark Telchemy -----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@echo.jf.INTEL.COM]On Behalf Of Even ,Roni Sent: Tuesday, December 25, 2001 9:33 AM To: ITU-SG16(a)echo.jf.INTEL.COM 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

Re: Including RTCP report packets in IRR
by Even ,Roni 26 Dec '01

26 Dec '01

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 >

2 1

January Meeting of TR-30.1
by Les Brown 21 Dec '01

21 Dec '01

All, Attached is the announcement for the next meeting of TIA TR-30.1. One of the primary tasks for this meeting is to make significant progress on modem-over IP. At our December meeting, it was agreed that we must be more proactive in driving the work on Annexes to H.323 and H.248 to support V.moip. The goal, albeit agressive, is still to complete the work on V.moip by the February SG16 meeting. If we are able to accomplish this, we will need to make sure that supporting Annexes to the aforementioned Recommendations are also ready for approval. With this in mind, Herb Wildfeuer (Cisco) has volunteered to act as the Editor for these Annexes and to try to prepare a first draft for our January meeting. He will be soliciting help from ITU-T Q2,3/16 committee members as well as members of ITU-T Q11/16 and TIA TR-30.1 between now and our January meeting via E-mail reflector. Please help Herb with this difficult task. I would also like to invite interested members of Q2,3/16 to participate in our January meeting. Another key issue that we need to make progress on is call discrimination for V.moip, and the coordination of this with the work on T.38 Annex 3. There has been a flurry of activity on the TIA TR-30.5 E-mail reflector recently on this subject. Between this discussion and discussions at the last TR-30.1 meeting, it is clear that there are some fundamental disagreements concerning what V.moip should specify with respect to call discrimination. I would like to encourage further discussion on this subject on both the TR-30.5 and TR-30.1 E-mail reflectors, and by a larger cross section of our membership, before our January meeting. If we are unable to resolve the differences by the January meeting, I very much doubt that we will be able to Consent V.moip in February. I would also like to invite interested members of Q14/16 to participate in our January meeting. I look forward to seeing you in sunny California. Les Brown, Chair TIA TR-30.1, Rapporteur Q11/16

1 0

January Meeting of TR-30.1
by Les Brown 21 Dec '01

21 Dec '01

All, Attached is the announcement for the next meeting of TIA TR-30.1. One of the primary tasks for this meeting is to make significant progress on modem-over IP. At our December meeting, it was agreed that we must be more proactive in driving the work on Annexes to H.323 and H.248 to support V.moip. The goal, albeit agressive, is still to complete the work on V.moip by the February SG16 meeting. If we are able to accomplish this, we will need to make sure that supporting Annexes to the aforementioned Recommendations are also ready for approval. With this in mind, Herb Wildfeuer (Cisco) has volunteered to act as the Editor for these Annexes and to try to prepare a first draft for our January meeting. He will be soliciting help from ITU-T Q2,3/16 committee members as well as members of ITU-T Q11/16 and TIA TR-30.1 between now and our January meeting via E-mail reflector. Please help Herb with this difficult task. I would also like to invite interested members of Q2,3/16 to participate in our January meeting. Another key issue that we need to make progress on is call discrimination for V.moip, and the coordination of this with the work on T.38 Annex 3. There has been a flurry of activity on the TIA TR-30.5 E-mail reflector recently on this subject. Between this discussion and discussions at the last TR-30.1 meeting, it is clear that there are some fundamental disagreements concerning what V.moip should specify with respect to call discrimination. I would like to encourage further discussion on this subject on both the TR-30.5 and TR-30.1 E-mail reflectors, and by a larger cross section of our membership, before our January meeting. If we are unable to resolve the differences by the January meeting, I very much doubt that we will be able to Consent V.moip in February. I would also like to invite interested members of Q14/16 to participate in our January meeting. I look forward to seeing you in sunny California. Les Brown, Chair TIA TR-30.1, Rapporteur Q11/16

1 0

Meeting of Q.1 during SG16
by patrick.luthi＠ties.itu.ch 18 Dec '01

18 Dec '01

Dear Experts, Just a short message to let you know that Q.1 is planning to meet as a question in 2 half day sessions and likely in a joint Q.2, 3, G session during the upcoming SG16 meeting (Feb. 5-15, 2002). The agenda and workplan will be published later by the WP2 Chairman, but here are some of the items that will be covered: - Recommendations for Consent: H.324 (revised), H.222.0 Corr. 2 (new) - Documents for Approval: H.320 series Implementor's Guide, T.120 series Implementor's Guide - Finalize H.320 harmonization with new H.263 Annex X - Progress the work on H.324 Annex Security - Review of the items relative to H.320, H.324, T.120, etc. If you need to communcicate with me before the meeting, please contact me at my ITU address (patrick.luthi(a)ties.itu.int) I am looking forward to seing you in Geneva and wish you a happy holiday season! Best regards, Patrick Luthi Rapporteur (chairman) for the ITU-T multimedia systems, terminals and data-conferencing Experts group (Question 1/16)

1 0

AW: Including RTCP report packets in IRR
by Horvath Ernst 17 Dec '01

17 Dec '01

Frank, my company has thought about this approach as well. We are preparing a contribution on this topic for the SG16 meeting in February 2002. Regards, Ernst > -----Ursprüngliche Nachricht----- > Von: frank.derks(a)PHILIPS.COM [mailto:frank.derks@PHILIPS.COM] > Gesendet am: Montag, 17. Dezember 2001 08:43 > An: ITU-SG16(a)echo.jf.INTEL.COM > Betreff: 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

Re: [Mobility] Resending the email with H.235 Annex G added to th e agenda of ITU-T SG16 WP2 Q.2/Q.5/Q.G Conference Call meetings informat i on
by Reddy, Paul K 06 Dec '01

06 Dec '01

Hi Karl, I will address this in the next conference call meeting. H.22x is in the scope of Q.5. We are targeting the H.22x work to be complete by February 2002 along with H.MMS.1 recommendations. Regards, Paul -----Original Message----- From: Klaghofer Karl ICN EN HC ID 14 [mailto:Karl.Klaghofer@icn.siemens.de] Sent: Friday, November 30, 2001 12:51 AM To: Reddy, Paul K Cc: ITU-SG16(a)echo.jf.INTEL.COM Subject: AW: [Mobility] Resending the email with H.235 Annex G added to th e agenda of ITU-T SG16 WP2 Q.2/Q.5/Q.G Conference Call meetings informat i on Hi Paul, I do not see the H.22x standard being listed as document within the scope of these upcoming Q.5 conference calls. Who (which Question) will drive the H.22x standard ? How can H.MMS.1 for example be completed by February if the actual protocol that would be used for mobility management (H.22x) is out of the scope of these Q.5 discussions ? Thanks, Karl Klaghofer, Siemens -----Ursprüngliche Nachricht----- Von: Reddy, Paul K [mailto:paul.k.reddy@INTEL.COM] Gesendet: Mittwoch, 28. November 2001 23:01 An: ITU-SG16(a)echo.jf.INTEL.COM Betreff: Re: [Mobility] Resending the email with H.235 Annex G added to th e agenda of ITU-T SG16 WP2 Q.2/Q.5/Q.G Conference Call meetings informati on Dear ITU-T SG16 WP2 Colleagues and Mobility Experts, Sorry for the delay in sending this email to the reflector and also due the outages of the SG16 reflector last week the last sent email could not be posted on this reflector. Please accept our apologies. As Rapporteur of Question_5/SG16 (Mobility for Multimedia Systems and Services) agreed in Dublin, Ireland Rapporteur's meeting to organize 3 two hours conference call meetings during Nov, Dec and January months before ITU-T SG16 face to face meeting during February, 2002 in Geneva, Switzerland. The goal of following conference call meetings are to make progress on the following recommendations: 1. H.MMS.0: User/Service Mobility Management for H.323 Multimedia Systems. 2. H.MMS.1: Terminal Mobility Management for H.323 Multimedia Systems. 3. H.MMS.2: Inter-working and Interoperability between Mobility Management for Multimedia systems and Cellular PLMNs. 4. H.MMS.3: Presence and Instant Messaging Services for mobile and non-mobile Multimedia systems. 5. H.MMS.4: Inter-working and Interoperability between H.MMS.3 and current Presence and IM systems 6. H.235 Annex-G: Security for Multimedia Mobility (User, Terminal, Service) services. For the status of the above recommendations and related documents, please see the enclosed Dublin's Q.5 Rapporteur's meeting report. Also, please go to URL <http://standard.pictel.com/ftp/avc-site/0110_Dub> http://standard.pictel.com/ftp/avc-site/0110_Dub for Q.5/16 documents. Guidelines for contributing and participating in the following Conference calls: 1. Companies and individual experts are welcome to contribute by uploading the contributions to ftp site: ftp://standard.pictel.com/avc-site/Incoming/Q5conf/ By due dates of each conference call meetings Contributions submission due dates: * For November 30, 2001 conference call is midnight (Pacific standard time) of Nov 28, 2001 * For December 18, 2001 conference call is midnight (Pacific standard time) of Dec 14, 2001 * For January 25, 2002 conference call is midnight (Pacific standard time) of Jan 18, 2001 2. Reply to this email to <mailto:paul.k.reddy@intel.com> paul.k.reddy(a)intel.com and get confirmation of your attendance on each of the conference call meetings in order to reserve the bridge port for a guarantee access during the conference call meetings. 3. Agenda for each Conference call meeting: * Introduction * Review contributions in the following order(Note: continue where we left off in one conference call meeting to another) i. H.MMS.1 (Terminal Mobility for H.323 MM systems) and H.22x.x (Mobility Management protocol and procedures) contributions. This recommendation is targeted for approval during Feb, 2002 SG16 meeting in Geneva. ii. H.MMS.0 (User Mobility, Service Mobility for Multimedia systems) contributions. This recommendation is targeted for approval during October, 2002 SG16 meeting in Geneva. iii. H.MMS.3 (Presence and IM services for mobile and non-mobile Multimedia Systems (e.g., H.323 systems)). This recommendation is targeted for approval during October, 2002 SG16 meeting in Geneva. iv. H.MMS.4 (Inter-working and Interoperability between H.MMS.3 and current Presence and IM systems). This recommendation is targeted for approval during Feb, 2003 SG16 meeting in Geneva. v. H.MMS.2 (Inter-working and Interoperability between Mobility Management for MM systems and Cellular PLMNs). This recommendation is targeted for approval during October, 2003 SG16 meeting in Geneva. vi. H.235 Annex G (Security for Multimedia Mobility Services). This recommendation with Security for Terminal mobility service is targeted for approval during Feb, 2002 SG16 meeting in Geneva. If you have any questions, please email Q.5/16 Rapporteur (Mr. Paul K. Reddy) at <mailto:paul.k.reddy@intel.com> paul.k.reddy(a)intel.com Conference call Bridge information: Conference call Meeting 1: Start: Nov 30, 2001 07:00 Pacific Standard Time End: Nov 30, 2001 09:00 Pacific Standard Time Duration: 120 minutes Moderator REDDY, PAUL K US Dial-In Number: 1-877-299-1938 International Dial-In Number: 1-617-801-9666 Passcode: 9899887 --------------------------------------------------- Conference Call Meeting 2: Start: Dec 18, 2001 07:00 Pacific Standard Time End: Dec 18, 2001 09:00 Pacific Standard Time User Instructions: Date: Tuesday, December 18, 2001 Lines: 10 Duration: 120 minutes Moderator REDDY, PAUL K US Dial-In Number: 1-877-299-1938 International Dial-In Number: 1-617-801-9666 Passcode: 6449818 ----------------------------------------------------- Conference Call Meeting 3: Start: Jan 25, 2002 07:00 Pacific Time End: Jan 25, 2002 09:00 Pacific Time Moderator REDDY, PAUL K US Dial-In Number: 1-877-299-1938 International Dial-In Number: 1-617-801-9666 Passcode: 3708752 ----------------------------------------------------- regards, Paul Paul K. Reddy Rapporteur of Q.5/16 ITU-T SG16 Working Party 2 Intel Labs, 2111 N.E. 25th Avenue, mailstop: JF3-377 Hillsboro, OR-97124, USA Tel: +1 (503)-264-9896 E-mail: paul.k.reddy(a)intel.com

1 0

Report of Q.5 (mobility) phone conference, 30 November 2001
by Horvath Ernst 06 Dec '01

06 Dec '01

Report of Q.5/SG16 (Mobility) conference call on November 30, 2001 (prepared by Ernst Horvath) Participants: Messrs. Bougant (FT), Euchner (Siemens), Horvath (Siemens); part time participation: Messrs. Reddy (Intel), Roy (AT&T) 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 and TD-FB-01a. Due to time limits, only the temporary documents were discussed. Results: 1) The proposals in TD-EH-01 and -02 regarding new recommendation H.22x were accepted. Mr. Reddy clarified the timeframe: => Target date for H.MMS.1, H.22x and H.225.0 Annex G: February 2002 Target date for H.MMS.0: October 2002 => Open issue: Editorship for H.22x (AI for Mr. Reddy to clarify. Is Mr. Ruditsky (Radvision) intereted?) 2) The rest of the time was spent on TD-EH-03 (comments on H.MMS.0) and TD-FB-01a (answers to these comments): * There are two possible "scopes" for H.MMS.0: (a) a framework for all other mobility work in SG16 or (b) a specification of service and user mobility. In case (a) other mobility documents (in particular H.MMS.1) could refer to H.MMS.0 for definitions, architecture and general concepts; in case (b) every mobility document would have to define its own architecture etc. Given the timeframe (see above), case (b) is the more sensible approach. Contributions on this issue are welcome (by email or by joining the next conference call). * Split of topics between H.MMS.0 and H.MMS.1: User mobility has also impacts on terminal mobility and cannot be eliminated completely from H.MMS.1. The figures in TD-FB-01a were not well understood and need further discussion by email. * The architecture for mobility is still unclear. In particular the role of MAFE was unclear (a single element here, but represents different elements in real systems, e.g. GK and BE in H.323). It was suggested to leave details of the MA (multimedia application, e.g. H.323) domain out of H.MMS.0 This needs further discussion by email. * It was decided to remove all protocol stuff from H.MMS.0 and refer to H.22x instead. The information flows will be specified on a high level of abstraction (in form of primiitves, as already present in some examples). * All message flow charts need to be reworked. More discussion needed (by email). 3) The next conference call on December 18, 2001 will continue with review of the remaining documents. Input on open items (architecture, scope or split of functionality) is urgently needed.

1 0

Report of the Dublin meeting AVD-2174
by OKUBO Sakae 05 Dec '01

05 Dec '01

Dear SG16 experts, On behalf of Mr. Paul Jones, manager of the Dublin meeting, I have placed the meeting report at the following place: ftp://standard.pictel.com/avc-site/0110_Dub/AVD-2174.zip or http://standard.pictel.com/ftp/avc-site/0110_Dub/AVD-2174.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 *********************************************************

1 0

AW: [Mobility] Resending the email with H.235 Annex G added to th e agenda of ITU-T SG16 WP2 Q.2/Q.5/Q.G Conference Call meetings informat i on
by Klaghofer Karl ICN EN HC ID 14 30 Nov '01

30 Nov '01

Hi Paul, I do not see the H.22x standard being listed as document within the scope of these upcoming Q.5 conference calls. Who (which Question) will drive the H.22x standard ? How can H.MMS.1 for example be completed by February if the actual protocol that would be used for mobility management (H.22x) is out of the scope of these Q.5 discussions ? Thanks, Karl Klaghofer, Siemens -----Ursprungliche Nachricht----- Von: Reddy, Paul K [mailto:paul.k.reddy@INTEL.COM] Gesendet: Mittwoch, 28. November 2001 23:01 An: ITU-SG16(a)echo.jf.INTEL.COM Betreff: Re: [Mobility] Resending the email with H.235 Annex G added to th e agenda of ITU-T SG16 WP2 Q.2/Q.5/Q.G Conference Call meetings informati on Dear ITU-T SG16 WP2 Colleagues and Mobility Experts, Sorry for the delay in sending this email to the reflector and also due the outages of the SG16 reflector last week the last sent email could not be posted on this reflector. Please accept our apologies. As Rapporteur of Question_5/SG16 (Mobility for Multimedia Systems and Services) agreed in Dublin, Ireland Rapporteur's meeting to organize 3 two hours conference call meetings during Nov, Dec and January months before ITU-T SG16 face to face meeting during February, 2002 in Geneva, Switzerland. The goal of following conference call meetings are to make progress on the following recommendations: 1. H.MMS.0: User/Service Mobility Management for H.323 Multimedia Systems. 2. H.MMS.1: Terminal Mobility Management for H.323 Multimedia Systems. 3. H.MMS.2: Inter-working and Interoperability between Mobility Management for Multimedia systems and Cellular PLMNs. 4. H.MMS.3: Presence and Instant Messaging Services for mobile and non-mobile Multimedia systems. 5. H.MMS.4: Inter-working and Interoperability between H.MMS.3 and current Presence and IM systems 6. H.235 Annex-G: Security for Multimedia Mobility (User, Terminal, Service) services. For the status of the above recommendations and related documents, please see the enclosed Dublin's Q.5 Rapporteur's meeting report. Also, please go to URL <http://standard.pictel.com/ftp/avc-site/0110_Dub> http://standard.pictel.com/ftp/avc-site/0110_Dub for Q.5/16 documents. Guidelines for contributing and participating in the following Conference calls: 1. Companies and individual experts are welcome to contribute by uploading the contributions to ftp site: ftp://standard.pictel.com/avc-site/Incoming/Q5conf/ By due dates of each conference call meetings Contributions submission due dates: * For November 30, 2001 conference call is midnight (Pacific standard time) of Nov 28, 2001 * For December 18, 2001 conference call is midnight (Pacific standard time) of Dec 14, 2001 * For January 25, 2002 conference call is midnight (Pacific standard time) of Jan 18, 2001 2. Reply to this email to <mailto:paul.k.reddy@intel.com> paul.k.reddy(a)intel.com and get confirmation of your attendance on each of the conference call meetings in order to reserve the bridge port for a guarantee access during the conference call meetings. 3. Agenda for each Conference call meeting: * Introduction * Review contributions in the following order(Note: continue where we left off in one conference call meeting to another) i. H.MMS.1 (Terminal Mobility for H.323 MM systems) and H.22x.x (Mobility Management protocol and procedures) contributions. This recommendation is targeted for approval during Feb, 2002 SG16 meeting in Geneva. ii. H.MMS.0 (User Mobility, Service Mobility for Multimedia systems) contributions. This recommendation is targeted for approval during October, 2002 SG16 meeting in Geneva. iii. H.MMS.3 (Presence and IM services for mobile and non-mobile Multimedia Systems (e.g., H.323 systems)). This recommendation is targeted for approval during October, 2002 SG16 meeting in Geneva. iv. H.MMS.4 (Inter-working and Interoperability between H.MMS.3 and current Presence and IM systems). This recommendation is targeted for approval during Feb, 2003 SG16 meeting in Geneva. v. H.MMS.2 (Inter-working and Interoperability between Mobility Management for MM systems and Cellular PLMNs). This recommendation is targeted for approval during October, 2003 SG16 meeting in Geneva. vi. H.235 Annex G (Security for Multimedia Mobility Services). This recommendation with Security for Terminal mobility service is targeted for approval during Feb, 2002 SG16 meeting in Geneva. If you have any questions, please email Q.5/16 Rapporteur (Mr. Paul K. Reddy) at <mailto:paul.k.reddy@intel.com> paul.k.reddy(a)intel.com Conference call Bridge information: Conference call Meeting 1: Start: Nov 30, 2001 07:00 Pacific Standard Time End: Nov 30, 2001 09:00 Pacific Standard Time Duration: 120 minutes Moderator REDDY, PAUL K US Dial-In Number: 1-877-299-1938 International Dial-In Number: 1-617-801-9666 Passcode: 9899887 --------------------------------------------------- Conference Call Meeting 2: Start: Dec 18, 2001 07:00 Pacific Standard Time End: Dec 18, 2001 09:00 Pacific Standard Time User Instructions: Date: Tuesday, December 18, 2001 Lines: 10 Duration: 120 minutes Moderator REDDY, PAUL K US Dial-In Number: 1-877-299-1938 International Dial-In Number: 1-617-801-9666 Passcode: 6449818 ----------------------------------------------------- Conference Call Meeting 3: Start: Jan 25, 2002 07:00 Pacific Time End: Jan 25, 2002 09:00 Pacific Time Moderator REDDY, PAUL K US Dial-In Number: 1-877-299-1938 International Dial-In Number: 1-617-801-9666 Passcode: 3708752 ----------------------------------------------------- regards, Paul BM__MailAutoSigPaul K. Reddy Rapporteur of Q.5/16 ITU-T SG16 Working Party 2 Intel Labs, 2111 N.E. 25th Avenue, mailstop: JF3-377 Hillsboro, OR-97124, USA Tel: +1 (503)-264-9896 E-mail: paul.k.reddy(a)intel.com

1 0

Re: [Mobility] Resending the email with H.235 Annex G added to th e agenda of ITU-T SG16 WP2 Q.2/Q.5/Q.G Conference Call meetings informati on
by Reddy, Paul K 28 Nov '01

28 Nov '01

Dear ITU-T SG16 WP2 Colleagues and Mobility Experts, Sorry for the delay in sending this email to the reflector and also due the outages of the SG16 reflector last week the last sent email could not be posted on this reflector. Please accept our apologies. As Rapporteur of Question_5/SG16 (Mobility for Multimedia Systems and Services) agreed in Dublin, Ireland Rapporteur's meeting to organize 3 two hours conference call meetings during Nov, Dec and January months before ITU-T SG16 face to face meeting during February, 2002 in Geneva, Switzerland. The goal of following conference call meetings are to make progress on the following recommendations: 1. H.MMS.0: User/Service Mobility Management for H.323 Multimedia Systems. 2. H.MMS.1: Terminal Mobility Management for H.323 Multimedia Systems. 3. H.MMS.2: Inter-working and Interoperability between Mobility Management for Multimedia systems and Cellular PLMNs. 4. H.MMS.3: Presence and Instant Messaging Services for mobile and non-mobile Multimedia systems. 5. H.MMS.4: Inter-working and Interoperability between H.MMS.3 and current Presence and IM systems 6. H.235 Annex-G: Security for Multimedia Mobility (User, Terminal, Service) services. For the status of the above recommendations and related documents, please see the enclosed Dublin's Q.5 Rapporteur's meeting report. Also, please go to URL http://standard.pictel.com/ftp/avc-site/0110_Dub <http://standard.pictel.com/ftp/avc-site/0110_Dub> for Q.5/16 documents. Guidelines for contributing and participating in the following Conference calls: 1. Companies and individual experts are welcome to contribute by uploading the contributions to ftp site: ftp://standard.pictel.com/avc-site/Incoming/Q5conf/ By due dates of each conference call meetings Contributions submission due dates: * For November 30, 2001 conference call is midnight (Pacific standard time) of Nov 28, 2001 * For December 18, 2001 conference call is midnight (Pacific standard time) of Dec 14, 2001 * For January 25, 2002 conference call is midnight (Pacific standard time) of Jan 18, 2001 2. Reply to this email to paul.k.reddy(a)intel.com <mailto:paul.k.reddy@intel.com> and get confirmation of your attendance on each of the conference call meetings in order to reserve the bridge port for a guarantee access during the conference call meetings. 3. Agenda for each Conference call meeting: * Introduction * Review contributions in the following order(Note: continue where we left off in one conference call meeting to another) i. H.MMS.1 (Terminal Mobility for H.323 MM systems) and H.22x.x (Mobility Management protocol and procedures) contributions. This recommendation is targeted for approval during Feb, 2002 SG16 meeting in Geneva. ii. H.MMS.0 (User Mobility, Service Mobility for Multimedia systems) contributions. This recommendation is targeted for approval during October, 2002 SG16 meeting in Geneva. iii. H.MMS.3 (Presence and IM services for mobile and non-mobile Multimedia Systems (e.g., H.323 systems)). This recommendation is targeted for approval during October, 2002 SG16 meeting in Geneva. iv. H.MMS.4 (Inter-working and Interoperability between H.MMS.3 and current Presence and IM systems). This recommendation is targeted for approval during Feb, 2003 SG16 meeting in Geneva. v. H.MMS.2 (Inter-working and Interoperability between Mobility Management for MM systems and Cellular PLMNs). This recommendation is targeted for approval during October, 2003 SG16 meeting in Geneva. vi. H.235 Annex G (Security for Multimedia Mobility Services). This recommendation with Security for Terminal mobility service is targeted for approval during Feb, 2002 SG16 meeting in Geneva. If you have any questions, please email Q.5/16 Rapporteur (Mr. Paul K. Reddy) at paul.k.reddy(a)intel.com <mailto:paul.k.reddy@intel.com> Conference call Bridge information: Conference call Meeting 1: Start: Nov 30, 2001 07:00 Pacific Standard Time End: Nov 30, 2001 09:00 Pacific Standard Time Duration: 120 minutes Moderator REDDY, PAUL K US Dial-In Number: 1-877-299-1938 International Dial-In Number: 1-617-801-9666 Passcode: 9899887 --------------------------------------------------- Conference Call Meeting 2: Start: Dec 18, 2001 07:00 Pacific Standard Time End: Dec 18, 2001 09:00 Pacific Standard Time User Instructions: Date: Tuesday, December 18, 2001 Lines: 10 Duration: 120 minutes Moderator REDDY, PAUL K US Dial-In Number: 1-877-299-1938 International Dial-In Number: 1-617-801-9666 Passcode: 6449818 ----------------------------------------------------- Conference Call Meeting 3: Start: Jan 25, 2002 07:00 Pacific Time End: Jan 25, 2002 09:00 Pacific Time Moderator REDDY, PAUL K US Dial-In Number: 1-877-299-1938 International Dial-In Number: 1-617-801-9666 Passcode: 3708752 ----------------------------------------------------- regards, Paul Paul K. Reddy Rapporteur of Q.5/16 ITU-T SG16 Working Party 2 Intel Labs, 2111 N.E. 25th Avenue, mailstop: JF3-377 Hillsboro, OR-97124, USA Tel: +1 (503)-264-9896 E-mail: paul.k.reddy(a)intel.com

1 0