- sg16-avd - lists.packetizer.com

Re: [H.323 Mobility:] About GK discovery
by Jaakko Sundquist 11 Jul '00

11 Jul '00

Hi again Radhika et al, The discussion seems to be directed only to the MGA issue, but that's fine... I would like to encourage other members to join in as well. Maybe I should at first clarify the situation that I am thinking of when we discuss these different gatekeeper discovery methods. The general case in a global mobile H.323 system would be that when a terminal changes location so that it needs to find a new gatekeeper, it does not have any knowledge of the part of the H.323 system it is about to attach to. In other words, it does not know the addresses of any gatekeepers to which it should register (obviously) nor would it know which gatekeeper discovery method is used (or which is the default one) in this environment. Similarly, of course, the gatekeepers in that part of the H.323 system are unaware of the new terminal and the default gatekeeper discovery method that it wishes to use, before the terminal sends some message (e.g. the GRQ) to them. The rest of my comments (identified with [Jaakko:]) below. > In Osaka, it was told that the multicast of MGA is a problem > because of > bandwidth consumption. However, using of MGA in a unicast > mode does not pose > any problems with respect to the bandwidth consumption. [Jaakko:] In Osaka we discussed mostly the case in which the last link towards the terminals is a radio link, e.g. the cellular access network case. I think it was quite clearly stated that multicasting the MGA message to all radio channels would be a waste of bandwidth (which is always scarce in radio links) compared to the GRQ method in which the multicasting is done only once per a terminal location change. How would you use unicasting in this case? In particular to whom would you unicast the MGA? If we think about other types of media, i.e. non-wireless terminal access, the situation may be somewhat different in some cases. Ultimately the normal ethernet uses broadcasting anyway, so multicasting the MGA to all terminals in a segment would consume the same amount of bandwidth as unicasting the message to one of the terminals. In this case the bandwidth consumption would be a function of the frequency of the multi/unicasted MGA messages, whereas when using the GRQ method the bandwidth consumption would be a function of the location changes of the terminal. Thus, the MGA method would be more efficient only when terminal location changes occur more frequently on average than the frequency at which the MGA is sent. When remembering that the period between two consecutive MGA messages should not be too long so that the terminal does not need to wait for it too long when it changes location, the MGA method does not seem to be more efficient very often. Also, this reasoning applies only to cases in which multicasting and unicasting consume the same amount of bandwidth. If this is not the case, the situation becomes even worse for the MGA method. I do not understand what you mean by "using the MGA in a unicast mode". To whom it is unicasted? Who unicasts it? When is it unicasted? (See my description of the general GK discovery situation above.) > > That is why, the post-Osaka emails were sent by to clarify the meeting > minutes. > > Therefore, MGA can be implemented using multicast or unicast method as > desired by implementation. In this respect, I have also > mentioned the work > that is being done in 3GPP. They also embraced the mobile IP > concept where > both agent solicitation (similar to our GRQ) and agent advertisement > (similar to our proposed MGA) are used. 3GPP has also > proposed to use the > agent advertisement message (similar to our proposed MGA) as "unicast" > method as a mechanism to reduce the bandwidth consumption. [Jaakko:] Do you have any pointers to the documents of 3GPP for this issue? I would be very interested to take a look at them. As I do not understand the concept of unicasted MGAs, I do not see how bandwidth consumption could be reduced. > In this respect, as I was told in the Osaka meeting, I have > clarified why > MGA is an excellent proposal to interwork with mobile IP and > 3GPP system if > one wants to use mobile H.323 in the upper layer. [Jaakko:] If I understand correctly, the 3GPP is thinking of using mobile IP protocol in some way to provide a certain level of mobility. Now, I do not see, how the inclusion of MGA (or any other message) would help the interworking of mobility enhanched H.323 and mobile IP. The agent advertisement and the agent solicitation are messages of the mobile IP protocol. Thus the H.323 layer is not aware nor can use these messages. Or am I totally wrong when I think that you can not send an MGA message inside mobile IP's agent advertisement message? Or what do you mean by the MGA helping when interworking with mobile IP? Surely, it does not help in any way just to have similar methods (or messages) in the upper (H.323) layer as in the lower (mobile IP) layer, if these have no connection with each other. > Furthermore, MGA is not a mandatory, but is an OPTIONAL > message. If one does > not like to use, they may not use it. [Jaakko:] Yes, but even an optional message must have some practical use, or in this case a clear advantage, at least in some cases (preferably cases that would actually apply in a reasonbly big portion of real life implementations), compared to the multicasted GRQ. For example, if I would bring in a contribution proposing a new optional message called IA (Ilves Advertisement), which would contain the text: "Ilves is the best!", would you be happy to accept that? That message would probably make the fans of my favorite ice-hockey team very happy, but I doubt, if that is a big enough purpose for introducing such a big change in the protocol as adding a message is, even if the message is optional. Furthermore, I strongly believe that a multicasting scheme (i.e. multicasted GRQs or the MGA scheme) is necessary in a real global mobile H.323 system for discovering the visited GK. (Mr. Kumar proposed in Osaka schemes involving either the User inputting the location or the Home GK being able to tell the address of the Visited GK. I don't think that either of these is a good enough or scalable method for global usage. See my comments of the general GK discovery case.) Thus, if we have two alternate multicasting methods for the GK discovery, which one should the terminal try first? If the terminal expects to use the MGA, how long should it wait for the MGA message, before sending the GRQ, i.e. how long should the default period between the MGAs be? If the default period is short, the terminal does not have to wait long, but in this case the bandwidth consumption of MGAs becomes large, because of frequent transmissions. The terminal is not reachable while it is waiting for the MGA, so the period can not be very long either. On the other hand, if multicasting GRQs is the default GK discovery method, no terminal will wait for the MGA anyway. If the terminal can be configured to use either of these methods, the gatekeepers will always have to implement both methods and so the MGA will actually not be optional for the gatekeepers. So, my question is: What is the problem that the GRQ method has and that would be solved by using the MGA? I will be happy to include the method in the standard, if you can show that there is a clear advantage in using it (in a way that also others beside me accept the reasoning). > The conclusion is that both GRQ and MGA message will > complement each other > as the agent solicitation and agent advertisement message > complement each > other in mobile IP (as well as 3GPP), and thereby opens the way for > interworking between mobile H.323 and mobile IP (when H.323 > is implemented > over the IP layer). In my opinion, we do not need both methods. Again, how would the inclusion of MGA open the way for interworking between mobile H.323 and mobile IP? > Without any mechanisms like MGA in H.323, mobility in H.323 > will be highly > "INCOMPLETE" and the mobile H.323 standard will almost be > "meaningless" when > the interworking with lower "mobile IP" layer is concerned. I > do believe > that we should NOT let it happen to the mobile H.323 standard. > > I like to see that people should provide any "technical" > reasons in this > "public" email reflector (that is received by the SG16 people > worldwide) why > MGA is not acceptable. I will provide justification for each > email and we > will go from there. > [RRR] Please see my reply provided above. Please provide your or other > members' "TECHNICAL" arguments against my explanations provided above > instead of "simply" saying that you are not "convinced" or > something like > that. This is a qualitative statement and does not provide > any technical > explanations. I have a problem here. You say that I only provide "non-technical" or "qualitative" arguments. That may have been true in my last email, but I found it a bit difficult to provide new technical arguments, when I did not actually find any new technical arguments supporting the use of MGA in your email (the one you sent right after Osaka). Perhaps I just did not understand something, so could you clarify your statements a bit? In the same manner, I could ask you to explain in technical terms, why H.323 will be "INCOMPLETE" without the MGA (just using mobile IP as a model is not a technical argument) and what exactly is the mobile H.323 to mobile IP interworking that you are talking about? Your original argument for using the MGA was that the method saves bandwidth. That argument was counter-argumented quite heavily in Osaka and I haven't seen a single technical argument from you that would prove otherwise. When I used the phrase: "I'm still not convinsed" I was meaning just that. I'm sorry, if I did not make myself clear, but I just did not want to write the same arguments used in Osaka once again. I hope that I have produced better technical arguments in this email. Anyway, let's continue the discussion and perhaps address other issues as well, after you have produced your comments on the new draft. -Jaakko ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: H.323 Annex M.1
by Sakae OKUBO 10 Jul '00

10 Jul '00

Dear Mr. Audet, APC-1880 has been allocated to your contribution: >H.323 Annex M.1 "Tunnelling of signalling protocols (QSIG) in H.323" Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: APC numbers
by Sakae OKUBO 10 Jul '00

10 Jul '00

Dear Mr. Andreson, In response to your request, the following APC-numbers have been allocated to your contributions: APC-1878 >Title: Draft H.323 Annex R (Robustness) >Source: Editor, Terry Anderson APC-1879 >Title: Reference Points for the Use of Annex G >Source: Lucent Technologies, Terry Anderson Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [H.323 Mobility:] A new H.323 Annex H Draft
by Roy, Radhika R, ALCOO 10 Jul '00

10 Jul '00

Hi, Jakko and all: Please see my response provided below [RRR]. In Osaka, it was told that the multicast of MGA is a problem because of bandwidth consumption. However, using of MGA in a unicast mode does not pose any problems with respect to the bandwidth consumption. That is why, the post-Osaka emails were sent by to clarify the meeting minutes. Therefore, MGA can be implemented using multicast or unicast method as desired by implementation. In this respect, I have also mentioned the work that is being done in 3GPP. They also embraced the mobile IP concept where both agent solicitation (similar to our GRQ) and agent advertisement (similar to our proposed MGA) are used. 3GPP has also proposed to use the agent advertisement message (similar to our proposed MGA) as "unicast" method as a mechanism to reduce the bandwidth consumption. In this respect, as I was told in the Osaka meeting, I have clarified why MGA is an excellent proposal to interwork with mobile IP and 3GPP system if one wants to use mobile H.323 in the upper layer. Furthermore, MGA is not a mandatory, but is an OPTIONAL message. If one does not like to use, they may not use it. The conclusion is that both GRQ and MGA message will complement each other as the agent solicitation and agent advertisement message complement each other in mobile IP (as well as 3GPP), and thereby opens the way for interworking between mobile H.323 and mobile IP (when H.323 is implemented over the IP layer). Without any mechanisms like MGA in H.323, mobility in H.323 will be highly "INCOMPLETE" and the mobile H.323 standard will almost be "meaningless" when the interworking with lower "mobile IP" layer is concerned. I do believe that we should NOT let it happen to the mobile H.323 standard. I like to see that people should provide any "technical" reasons in this "public" email reflector (that is received by the SG16 people worldwide) why MGA is not acceptable. I will provide justification for each email and we will go from there. Best regards, Radhika R. Roy -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@nokia.com] Sent: Monday, July 10, 2000 3:16 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] A new H.323 Annex H Draft Hi Radhika et al, Let's try to start a bit of discussion... > It is nice to see that you and Mr. Kumar had a communication > related to GRQ > and you have included in the contribution. Yes, actually Mr. Kumar raised this point already in Osaka, but it seems to have been kind of lost in the conversations. At least I did not quite grasp this issue at that time. It does seem a perfectly valid point though (if someone has a counter-argument, please inform us). [RRR] I also think that it is a reasonable idea. If other members have any counter arguments, please let us know. > > I wonder what happened to the emails that I sent to the SG16 > email "public" > reflector related to MGA message! I have not seen any counter > arguments > related to this in the email reflector. I like to see that > MGA message is > also included (with both unicast and multicast option as suit the > implementation). Your emails did arrive, or at least I saw them. The reflector seems to have been quite quiet recently, perhaps some people are having their holidays (I did, before I had time to comment on your emails). As for the MGA issue. I think we had a quite good discussion on that in Osaka and it seemed to me that really no one else was in favor of the idea. Most people, including myself, came to the conclusion that the MGA scheme would be less efficient instead of being more efficient than multicasting GRQs. Thus far I haven't seen anything that would convince me otherwise (I don't remember exactly, what you said in your last email about the MGA, but I did read it and did not find any new arguments in favor of the MGA). Furthermore, I think that having two alternate multicasting schemes for gatekeeper discovery would only lead to difficulties both in making an explicit and robust annex as well as in implementation of the mobile H.323 system described in the annex. [RRR] Please see my reply provided above. Please provide your or other members' "TECHNICAL" arguments against my explanations provided above instead of "simply" saying that you are not "convinced" or something like that. This is a qualitative statement and does not provide any technical explanations. > > I would also appreciate that you should start discussing in the email > reflector before any further update is made in the document > so that we can > participate in the process for updating the document. The > discussion can be > formulated as follows: > > 1. What you want to propose and why > 2. Pros and cons of the proposals > 3. Invite comments from the members > 4. Update the document based on item 3 As you mentioned, I have tried to do steps 1 and 2 in the emails I have sent to the reflector. The idea behind this approach of me sending a draft (or editor's draft, if you will) every once in a while is step 3. By sending a whole new draft, I'm trying to force people to react to the changes. Step 4 will naturally be done after the discussions about the changes. You said that you will produce your comments on the new draft soon, good, that is precisely want I wanted (step 3). I hope others will do the same. [RRR] I already provided my initial comments before going to the Osaka meeting with respect to your initial draft that was produced by you. Your original draft has not been changed much since then what has been in pre-Osaka meeting. If you look into those comments sent by me via emails and during the conference calls before the Osaka meeting, you may have a feel what I have to say. However, it is a valid point that I have to make my time to provide comments on your latest draft. -Jaakko ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: APC Numbers for Portland
by Sakae OKUBO 10 Jul '00

10 Jul '00

Dear Mr. Klaghofer, In response to your request, APC-numbers have been allocated as follows: APC-1876 >* Draft Call Offer Supplementary Service for H.323 (Source: Editor) APC-1877 >* Draft Call Intrusion Supplementary Service for H.323 (Source: >Editor) Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [H.323 Mobility:] A new H.323 Annex H Draft
by Jaakko Sundquist 10 Jul '00

10 Jul '00

Hi Radhika et al, Let's try to start a bit of discussion... > It is nice to see that you and Mr. Kumar had a communication > related to GRQ > and you have included in the contribution. Yes, actually Mr. Kumar raised this point already in Osaka, but it seems to have been kind of lost in the conversations. At least I did not quite grasp this issue at that time. It does seem a perfectly valid point though (if someone has a counter-argument, please inform us). > > I wonder what happened to the emails that I sent to the SG16 > email "public" > reflector related to MGA message! I have not seen any counter > arguments > related to this in the email reflector. I like to see that > MGA message is > also included (with both unicast and multicast option as suit the > implementation). Your emails did arrive, or at least I saw them. The reflector seems to have been quite quiet recently, perhaps some people are having their holidays (I did, before I had time to comment on your emails). As for the MGA issue. I think we had a quite good discussion on that in Osaka and it seemed to me that really no one else was in favor of the idea. Most people, including myself, came to the conclusion that the MGA scheme would be less efficient instead of being more efficient than multicasting GRQs. Thus far I haven't seen anything that would convince me otherwise (I don't remember exactly, what you said in your last email about the MGA, but I did read it and did not find any new arguments in favor of the MGA). Furthermore, I think that having two alternate multicasting schemes for gatekeeper discovery would only lead to difficulties both in making an explicit and robust annex as well as in implementation of the mobile H.323 system described in the annex. > > I would also appreciate that you should start discussing in the email > reflector before any further update is made in the document > so that we can > participate in the process for updating the document. The > discussion can be > formulated as follows: > > 1. What you want to propose and why > 2. Pros and cons of the proposals > 3. Invite comments from the members > 4. Update the document based on item 3 As you mentioned, I have tried to do steps 1 and 2 in the emails I have sent to the reflector. The idea behind this approach of me sending a draft (or editor's draft, if you will) every once in a while is step 3. By sending a whole new draft, I'm trying to force people to react to the changes. Step 4 will naturally be done after the discussions about the changes. You said that you will produce your comments on the new draft soon, good, that is precisely want I wanted (step 3). I hope others will do the same. -Jaakko ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H.323 v4 and H.323 IG
by Sakae OKUBO 09 Jul '00

09 Jul '00

Dear Q12-14/16 experts, > APC-1874 > > Draft H.323 version 4 > > APC-1875 > > H.323-series Implementers Guide They have been moved to the following place: ftp://standard.pictel.com/avc-site/0008_Port/ or http://standard.pictel.com/ftp/avc-site/0008_Port/ Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: APC numbers
by Sakae OKUBO 09 Jul '00

09 Jul '00

Dear Mr. Jones, In response to your request, the following numbers have been allocated to your two contributions: APC-1874 > Draft H.323 version 4 APC-1875 > H.323-series Implementers Guide Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: White paper draft of H.323v4
by Sakae OKUBO 09 Jul '00

09 Jul '00

Dear Mr. Jones, >And, of course I can't get it right the first time :-) So, you'll see two >files there. One is called "newer H.323...". That's the file that should >be kept. The correct one has been renamed and moved to /0011_Gen directory. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

FW: [IPTEL] CPL: H.323 issues
by Francois Audet 09 Jul '00

09 Jul '00

For those interested. -----Original Message----- From: Jonathan Lennox [mailto:lennox@cs.columbia.edu] Sent: Friday, July 07, 2000 3:17 PM mailto:iptel@lists.bell-labs.com Subject: [IPTEL] CPL: H.323 issues The primary area still missing in the CPL spec is H.323 work. I'm unfortunately not very knowlegeable about this, so if some H.323 experts could assist with this it would be very helpful. Here are the general issues that I feel need to be addressed: 1. I understand that work is in progress to define an H.323 url as an annex of the H.323 specification. What is the status of this? Are copies of available? Will these URLs be appropriate to use in CPL <location> and <address-switch> tags? 2. Is the unpacking of H.323 addresses as specified for CPL's <address-switch> address subfield matching correct, and complete for at least a useful subset of H.323 addresses? 3. What free-form strings does H.323 signalling carry that a CPL should be able to match? I understand H.225 has a "data" string, but it's not clear to me what it's for. 4. Is there some H.323 counterpart to SIP caller preferences and callee capabilities that should either be used or mapped into CPL, for <lookup> and <remove-location>? Since Our Esteemed Working Group Chair has expressed a strong interest in moving CPL along to Proposed Standard soon, these points *need* to be addressed. If no one else comments on them, I'll have to guess based on my own (very limited) understanding of H.323, which will probably mean a much weaker CPL specification all around. -- Jonathan Lennox lennox(a)cs.columbia.edu _______________________________________________ IPTEL mailing list IPTEL(a)lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel

2 1

White paper draft of H.323v4
by Paul E. Jones 09 Jul '00

09 Jul '00

Mr. Okubo, I have placed a copy of the white paper draft for H.323v4 (which includes Annex D/H.323) in the incoming directory of the AVC site. Thanks, Paul

1 0

Re: Deficiency in Annex M, specifically M.2?
by Callaghan, Robert 07 Jul '00

07 Jul '00

Daniel, Non-ITU variants can have OIDs that are defined by the controlling body. OID for non-ITU variants should not be defined by the ITU. It is too easy to omit one and then there is a problem. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Daniel Eskenazi [mailto:deskenaz@cisco.com] Sent: Friday, July 07, 2000 3:40 PM To: Francois Audet Cc: Callaghan, Robert; 'Mailing list for parties associated with ITU-T Study Group 16'; paulej(a)cisco.com Subject: Re: Deficiency in Annex M, specifically M.2? Hi Francois, Are you saying that even if the OID hierarchy is underneath ITU H 225, it is still not advisable to enumerate non-ITU variants? I am not very knowledgeable about OID manners so I didn't realize this is frowned upon. Regarding variants for QSIG, I suppose you could have a complicated OID hierarchy underneath Annex M (1) that lists the version for each functional area (basic call, generic protocol, supp services, etc). There's no reason the hierarchy can't be different underneath each Annex M protocol, is there? My original concern was for ISUP - I take it the ability to discriminate version(s) is important for QSIG as well? Thanks, Daniel Eskenazi > Francois Audet wrote: > > I don't think you want to use the ITU OID for ISUP > when using, for example, the North American variant. > > An aditional problem is that there is no such thing as a version for > QSIG. You have versions for basic call control, and another version > for the > generic functional protocol, others for individual supplementary > services. > I'm not sure how to solve that. > > > -----Original Message----- > > From: Daniel Eskenazi [mailto:deskenaz@cisco.com] > > Sent: Friday, July 07, 2000 12:02 PM > > To: Callaghan, Robert; Audet, Francois [SC9:4K02:EXCH] > > Cc: 'Mailing list for parties associated with ITU-T Study Group 16'; > > > paulej(a)cisco.com > > Subject: Re: Deficiency in Annex M, specifically M.2? > > > > > > > > Bob (and Francois, who also mentioned the same thing), > > > > Agreed, this would work too, and I'm not opposed > > to that solution. My thinking was that adding the > > new fields would be slightly easier for implementors, > > since an endpoint that is interested in tunneling, > > for example, all ISUP variants but no QSIG variants can > > easily determine that the tunneled data is ISUP rather > > than QSIG just by matching the hard-coded ISUP OID, > > without having to "parse" the OID. On the other hand, > > the OID approach has the advantage of not requiring any > > ASN.1 changes. > > > > But even with OID approach, Annex M.2 (and potentially M.1) need > > minor chang(es), since they are hard-coded to indicate a single > > OID value for QSIG or ISUP. We would need to define a new > > OID hierarchy for specifying Annex-M Protocol/Variant/Version, > > and refer to the OID hierarchy from within Annex-M.2(and > > possibly M.1). Agreed? > > > > Thanks, > > > > Daniel Eskenazi > > > > "Callaghan, Robert" wrote: > > > > > > Daniel, > > > > > > This problem can also be solved by having different Object > > Ids for each > > > variant of ISUP. > > > > > > Bob > > > > > > > > -------------------------------------------------------------- > > -------------- > > > ----------------------------- > > > > > > Hi Jan, > > > > > > Annex M.2 does not seem to provide any standard mechanism for > > > specifying the variant of ISUP that is being tunneled. > > Therefore ISUP > > > tunneling as currently defined in Annex M.2 will only work > properly > > > if both H.323 endpoints are connected to ISUP equipment using the > > > exact same type and version of ISUP. Do you agree? > > > > > > Assuming that I didn't miss something and this is a valid > > > concern, the addition of type and version fields would solve > > > this problem. I believe Protocol type and version information > > > would be universally useful for all tunneled protocols, so I > > > propose that the tunneledSignallingMessage construct be enhanced > > > to provide fields for protocolType (or maybe it should be called > > > protocolVariant?) and protocolVersion; exact format TBD. > > > > > > Any comments? > > > > > > Thanks, > > > > > > -- > > > Daniel Eskenazi .|. .|. dve(a)cisco.com OR > deskenaz(a)cisco.com > > > Cisco Systems ..::|::..::|::.. 919-472-3891 > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > For help on this mail list, send "HELP ITU-SG16" in a message to > > > listserv(a)mailbag.intel.com > > > > -- > > Daniel Eskenazi .|. .|. dve(a)cisco.com OR deskenaz(a)cisco.com > > > Cisco Systems ..::|::..::|::.. 919-472-3891 > > -- Daniel Eskenazi .|. .|. dve(a)cisco.com OR deskenaz(a)cisco.com Cisco Systems ..::|::..::|::.. 919-472-3891 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Deficiency in Annex M, specifically M.2?
by Callaghan, Robert 07 Jul '00

07 Jul '00

Daniel, The problem in the past with defining variants of ISUP is that many variants are controlled by national bodies. This will make it hard to define these in an ITU-T defined structure. (But you are welcome to try.) I have no problem changing the OID to a list of. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Daniel Eskenazi [mailto:deskenaz@cisco.com] Sent: Friday, July 07, 2000 3:02 PM To: Callaghan, Robert; audet(a)nortelnetworks.com Cc: 'Mailing list for parties associated with ITU-T Study Group 16'; paulej(a)cisco.com Subject: Re: Deficiency in Annex M, specifically M.2? Bob (and Francois, who also mentioned the same thing), Agreed, this would work too, and I'm not opposed to that solution. My thinking was that adding the new fields would be slightly easier for implementors, since an endpoint that is interested in tunneling, for example, all ISUP variants but no QSIG variants can easily determine that the tunneled data is ISUP rather than QSIG just by matching the hard-coded ISUP OID, without having to "parse" the OID. On the other hand, the OID approach has the advantage of not requiring any ASN.1 changes. But even with OID approach, Annex M.2 (and potentially M.1) need minor chang(es), since they are hard-coded to indicate a single OID value for QSIG or ISUP. We would need to define a new OID hierarchy for specifying Annex-M Protocol/Variant/Version, and refer to the OID hierarchy from within Annex-M.2(and possibly M.1). Agreed? Thanks, Daniel Eskenazi "Callaghan, Robert" wrote: > > Daniel, > > This problem can also be solved by having different Object Ids for each > variant of ISUP. > > Bob > > ---------------------------------------------------------------------------- > ----------------------------- > > Hi Jan, > > Annex M.2 does not seem to provide any standard mechanism for > specifying the variant of ISUP that is being tunneled. Therefore ISUP > tunneling as currently defined in Annex M.2 will only work properly > if both H.323 endpoints are connected to ISUP equipment using the > exact same type and version of ISUP. Do you agree? > > Assuming that I didn't miss something and this is a valid > concern, the addition of type and version fields would solve > this problem. I believe Protocol type and version information > would be universally useful for all tunneled protocols, so I > propose that the tunneledSignallingMessage construct be enhanced > to provide fields for protocolType (or maybe it should be called > protocolVariant?) and protocolVersion; exact format TBD. > > Any comments? > > Thanks, > > -- > Daniel Eskenazi .|. .|. dve(a)cisco.com OR deskenaz(a)cisco.com > Cisco Systems ..::|::..::|::.. 919-472-3891 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com -- Daniel Eskenazi .|. .|. dve(a)cisco.com OR deskenaz(a)cisco.com Cisco Systems ..::|::..::|::.. 919-472-3891 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Deficiency in Annex M, specifically M.2?
by Francois Audet 07 Jul '00

07 Jul '00

> Hi Francois, > > Are you saying that even if the OID hierarchy is underneath > ITU H 225, it is still not advisable to enumerate non-ITU variants? > I am not very knowledgeable about OID manners so I didn't realize > this is frowned upon. No, I'm saying the current OID for ISUP refers specifically to an ITU-T Recomendation, not the concept of "ISUP" (the OID is owned by ITU). To refer to, lets say, an ANSI version would require an ANSI OID. > Regarding variants for QSIG, I suppose you could have a complicated > OID hierarchy underneath Annex M (1) that lists the version for each > functional area (basic call, generic protocol, supp services, etc). > There's no reason the hierarchy can't be different underneath each > Annex M protocol, is there? Yeah. So this seems to be too complicated, which is why we just say "QSIG". > My original concern was for ISUP - I take it the ability to > discriminate version(s) is important for QSIG as well? I don't think it is as important since most implementation have already converged to the ISO standard

1 0

Re: Deficiency in Annex M, specifically M.2?
by Francois Audet 07 Jul '00

07 Jul '00

I don't think you want to use the ITU OID for ISUP when using, for example, the North American variant. An aditional problem is that there is no such thing as a version for QSIG. You have versions for basic call control, and another version for the generic functional protocol, others for individual supplementary services. I'm not sure how to solve that. > -----Original Message----- > From: Daniel Eskenazi [mailto:deskenaz@cisco.com] > Sent: Friday, July 07, 2000 12:02 PM > To: Callaghan, Robert; Audet, Francois [SC9:4K02:EXCH] > Cc: 'Mailing list for parties associated with ITU-T Study Group 16'; > paulej(a)cisco.com > Subject: Re: Deficiency in Annex M, specifically M.2? > > > > Bob (and Francois, who also mentioned the same thing), > > Agreed, this would work too, and I'm not opposed > to that solution. My thinking was that adding the > new fields would be slightly easier for implementors, > since an endpoint that is interested in tunneling, > for example, all ISUP variants but no QSIG variants can > easily determine that the tunneled data is ISUP rather > than QSIG just by matching the hard-coded ISUP OID, > without having to "parse" the OID. On the other hand, > the OID approach has the advantage of not requiring any > ASN.1 changes. > > But even with OID approach, Annex M.2 (and potentially M.1) need > minor chang(es), since they are hard-coded to indicate a single > OID value for QSIG or ISUP. We would need to define a new > OID hierarchy for specifying Annex-M Protocol/Variant/Version, > and refer to the OID hierarchy from within Annex-M.2(and > possibly M.1). Agreed? > > Thanks, > > Daniel Eskenazi > > "Callaghan, Robert" wrote: > > > > Daniel, > > > > This problem can also be solved by having different Object > Ids for each > > variant of ISUP. > > > > Bob > > > > > -------------------------------------------------------------- > -------------- > > ----------------------------- > > > > Hi Jan, > > > > Annex M.2 does not seem to provide any standard mechanism for > > specifying the variant of ISUP that is being tunneled. > Therefore ISUP > > tunneling as currently defined in Annex M.2 will only work properly > > if both H.323 endpoints are connected to ISUP equipment using the > > exact same type and version of ISUP. Do you agree? > > > > Assuming that I didn't miss something and this is a valid > > concern, the addition of type and version fields would solve > > this problem. I believe Protocol type and version information > > would be universally useful for all tunneled protocols, so I > > propose that the tunneledSignallingMessage construct be enhanced > > to provide fields for protocolType (or maybe it should be called > > protocolVariant?) and protocolVersion; exact format TBD. > > > > Any comments? > > > > Thanks, > > > > -- > > Daniel Eskenazi .|. .|. dve(a)cisco.com OR deskenaz(a)cisco.com > > Cisco Systems ..::|::..::|::.. 919-472-3891 > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > -- > Daniel Eskenazi .|. .|. dve(a)cisco.com OR deskenaz(a)cisco.com > Cisco Systems ..::|::..::|::.. 919-472-3891 >

2 1

Re: [H.323 Mobility:] A new H.323 Annex H Draft
by Roy, Radhika R, ALCOO 07 Jul '00

07 Jul '00

Hi, Jaakko and Everyone: It is nice to see that you and Mr. Kumar had a communication related to GRQ and you have included in the contribution. I wonder what happened to the emails that I sent to the SG16 email "public" reflector related to MGA message! I have not seen any counter arguments related to this in the email reflector. I like to see that MGA message is also included (with both unicast and multicast option as suit the implementation). I would also appreciate that you should start discussing in the email reflector before any further update is made in the document so that we can participate in the process for updating the document. The discussion can be formulated as follows: 1. What you want to propose and why 2. Pros and cons of the proposals 3. Invite comments from the members 4. Update the document based on item 3 Items 1 and 2 can be formulated in a simple and concise manner (in fact you did in many cases). Please note that I am encouraging for updating, but defining a process how an editor can update a contribution in absence of any contributions (or conference calls) from any members other than the editor. (I also plan to provide my comments on the latest document. However, I am busy with so many works that I am yet to find time.) Finally, I appreciate your efforts in carrying this work. Best regards, Radhika R. Roy > -----Original Message----- > From: Jaakko Sundquist [SMTP:jaakko.sundquist@nokia.com] > Sent: Friday, July 07, 2000 8:40 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: [H.323 Mobility:] A new H.323 Annex H Draft > > Hi all, > > I have uploaded the new H.323 Annex H Draft to URL: > ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/Md-101b_H323Annex > HDraft.zip > > > Most changes to the previous version are in chapter 7 (H.323 Mobility > Functional Requirements), most parts of which have been rewritten. > > Some changes have been introduced also to section 10.5.1 concerning the > contents of the authentication messages towards the AuF. Mr. Kumaar has > pointed out that authentication values are (normally) calculated over the > whole GRQ message and thus it is necessary to send the whole GRQ message > to > the AuF. I have not found anything that would disprove this point and thus > I > assume that this is the way we must specify the authentication procedure. > I'm also quite aware that the effects of the inclusion of the GRQ message > have probably not been throughly added to the section, but I wanted to get > this version out before weekend and still have a mention of the issue in > the > draft. I would like to hear (or read) any comments that the experts have > regarding this section as I'm not a very good expert on H.235. > > Furthermore, I'll try to work out the next version of the annex as soon as > possible and I'm hoping to add quite much stuff on the information flow > and > message content definitions. I would also like to see contributions > especially on these areas. > > I hope that not all of you are spending your holidays and I actually get > some comments ;-). > > Anyway, have a nice weekend, everyone! > > ------------------------------------------------ > Jaakko Sundquist * > +358 50 3598281 * Audere est Facere! > jaakko.sundquist(a)nokia.com * > ------------------------------------------------ > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Deficiency in Annex M, specifically M.2?
by Callaghan, Robert 07 Jul '00

07 Jul '00

Daniel, This problem can also be solved by having different Object Ids for each variant of ISUP. Bob ---------------------------------------------------------------------------- ----------------------------- Hi Jan, Annex M.2 does not seem to provide any standard mechanism for specifying the variant of ISUP that is being tunneled. Therefore ISUP tunneling as currently defined in Annex M.2 will only work properly if both H.323 endpoints are connected to ISUP equipment using the exact same type and version of ISUP. Do you agree? Assuming that I didn't miss something and this is a valid concern, the addition of type and version fields would solve this problem. I believe Protocol type and version information would be universally useful for all tunneled protocols, so I propose that the tunneledSignallingMessage construct be enhanced to provide fields for protocolType (or maybe it should be called protocolVariant?) and protocolVersion; exact format TBD. Any comments? Thanks, -- Daniel Eskenazi .|. .|. dve(a)cisco.com OR deskenaz(a)cisco.com Cisco Systems ..::|::..::|::.. 919-472-3891 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: Intellectual property/patents on H.323 Annex K???
by Francois Audet 07 Jul '00

07 Jul '00

&#*&?$"@, I also copied M.1 from some other draft (I don't remember which one). I will insert the "not" and send it back to the ITU. I suspect that M.2 may have the same problem since I believe it was copied from M.1. > -----Original Message----- > From: Espen Skjæran (ETO) [mailto:Espen.Skjaeran@ETO.ERICSSON.SE] > Sent: Friday, July 07, 2000 6:46 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Intellectual property/patents on H.323 Annex K??? > > > Frank, > This is positively a mistake. I copied the whole header from > H.323 Annex M.1 in Geneva (PL-39.doc), which of some reason > had this text instead of the original (claiming "... not > received..."). This has now been updated in the latest > version of Annex M.1. > > To my knowledge, ITU has not received any notice about this. > I haven't done any exhaustive IPR search on this, but do not > know of anything that will block this recommendation. > > Regards, > Espen > > -----Original Message----- > From: Frank Derks [mailto:frank.derks@PHILIPS.COM] > Sent: 5. juli 2000 11:26 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Intellectual property/patents on H.323 Annex K??? > > > H.323 Annex K/APC-1811 (May 2000 meeting), states that the > ITU has "...received notice of intellectual property, > protected by patents, which may be required to implement this > recommendation". Is anyone in a position to inform me which > patent(s) are > involved? > > Regards, > > Frank > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com >

1 0

Deficiency in Annex M, specifically M.2?
by Daniel Eskenazi 07 Jul '00

07 Jul '00

Hi Jan, Annex M.2 does not seem to provide any standard mechanism for specifying the variant of ISUP that is being tunneled. Therefore ISUP tunneling as currently defined in Annex M.2 will only work properly if both H.323 endpoints are connected to ISUP equipment using the exact same type and version of ISUP. Do you agree? Assuming that I didn't miss something and this is a valid concern, the addition of type and version fields would solve this problem. I believe Protocol type and version information would be universally useful for all tunneled protocols, so I propose that the tunneledSignallingMessage construct be enhanced to provide fields for protocolType (or maybe it should be called protocolVariant?) and protocolVersion; exact format TBD. Any comments? Thanks, -- Daniel Eskenazi .|. .|. dve(a)cisco.com OR deskenaz(a)cisco.com Cisco Systems ..::|::..::|::.. 919-472-3891 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

APC-1872, 1873
by Glen Freundlich 07 Jul '00

07 Jul '00

I have placed 2 liaisons from SG11 on the Pictel avc-site: APC-1872: Liaison to SG16 On Interaction Between Intelligent Network Systems and H.248 APC-1873: Liaison to SG16 On Interworking Between H.323 Systems and Intelligent Network Systems Regards, Glen -- Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 1

Re: Intellectual property/patents on H.323 Annex K???
by Espen Skj�ran 07 Jul '00

07 Jul '00

Frank, This is positively a mistake. I copied the whole header from H.323 Annex M.1 in Geneva (PL-39.doc), which of some reason had this text instead of the original (claiming "... not received..."). This has now been updated in the latest version of Annex M.1. To my knowledge, ITU has not received any notice about this. I haven't done any exhaustive IPR search on this, but do not know of anything that will block this recommendation. Regards, Espen -----Original Message----- From: Frank Derks [mailto:frank.derks@PHILIPS.COM] Sent: 5. juli 2000 11:26 To: ITU-SG16(a)mailbag.cps.intel.com Subject: Intellectual property/patents on H.323 Annex K??? H.323 Annex K/APC-1811 (May 2000 meeting), states that the ITU has "...received notice of intellectual property, protected by patents, which may be required to implement this recommendation". Is anyone in a position to inform me which patent(s) are involved? Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

[H.323 Mobility:] A new H.323 Annex H Draft
by Jaakko Sundquist 07 Jul '00

07 Jul '00

Hi all, I have uploaded the new H.323 Annex H Draft to URL: ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/Md-101b_H323AnnexHD raft.zip . Most changes to the previous version are in chapter 7 (H.323 Mobility Functional Requirements), most parts of which have been rewritten. Some changes have been introduced also to section 10.5.1 concerning the contents of the authentication messages towards the AuF. Mr. Kumaar has pointed out that authentication values are (normally) calculated over the whole GRQ message and thus it is necessary to send the whole GRQ message to the AuF. I have not found anything that would disprove this point and thus I assume that this is the way we must specify the authentication procedure. I'm also quite aware that the effects of the inclusion of the GRQ message have probably not been throughly added to the section, but I wanted to get this version out before weekend and still have a mention of the issue in the draft. I would like to hear (or read) any comments that the experts have regarding this section as I'm not a very good expert on H.235. Furthermore, I'll try to work out the next version of the annex as soon as possible and I'm hoping to add quite much stuff on the information flow and message content definitions. I would also like to see contributions especially on these areas. I hope that not all of you are spending your holidays and I actually get some comments ;-). Anyway, have a nice weekend, everyone! ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.com * ------------------------------------------------ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Comments on H.225v4 and H.323v4
by <Morgan Potter> 07 Jul '00

07 Jul '00

Rich/Paul, I have the following comments on H.225v4 and H.323v4. H.225 /p168: neededfeatures has been moved from conferenceGoal to elsewhere in the Setup message. I understand from Pete that inclusion of neededFeatures in the conferenceGoal has caused problems for Cisco gateways. Moving neededFeatures out of the conferenceGoal however, means that feature negotiation can never be used with versions other than H.323v4. If we are not going to use the conference Goal, (and the use of conferenceGoal is our preferred option!), It would be better to leave out the term neededFeatures altogether and use desiredFeatures. H.323 /p75: The change of name from 'package' to 'parameter' is inappropriate. If the name has to be changed from 'package', it should be changed to genericFeature. H.225 /ANNEX H: There should be a global change of terminology from genericParameter to generic Feature. Regards, Morgan Potter ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

4 5

H.248 Annex F uploaded to the Pictel site
by Gunnar Hellstrom 06 Jul '00

06 Jul '00

I have just uploaded H.248 Annex F, facsimile, text conversation and call discrimination packages to the Pictel site in white draft form.. Regards Gunnar ------------------------------------------ Gunnar Hellstrom LM Ericsson E-mail gunnar.hellstrom(a)omnitor.se Tel +46 8 556 002 03 Mob +46 708 204 288 fax +46 8 556 002 06 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

white drafts for H.248 Annexes J & K
by Glen Freundlich 06 Jul '00

06 Jul '00

I have placed white drafts for H.248 Annex J and H.248 Annex K in the Incoming directory of the Pictel avc-site. These annexes have not changed since determination, with the exception that the hex package ID in each annex was changed according to Osaka TD-14. Regards, Glen -- Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0