- sg16-avd - lists.packetizer.com

APC-1878, 1883, 1886
by Terry L Anderson 24 Jul '00

24 Jul '00

I have uploaded APC-1878: Reference Points for the use of Annex G APC-1883: CPL: A Language for User Control of Internet Telephony Services (a copy of draft-ietf-iptel-cpl-01.txt for information) APC-1886: RFC-2824: Call Processing Language Framework and Requirements (a copy of RFC-2824 for information) to the incoming directory of the avc-site. -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572(a)skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

1 0

Re: [H.323 Mobility:] Update to Service Definitions for Annex H - > a question
by Jaakko Sundquist 24 Jul '00

24 Jul '00

Hi Marc et al, I just finished reading MD-102a and I have a couple of questions. First of all, though, I want to thank you guys for the excelent contribution, I really liked it. Actually I have just one thing that I don't quite understand. In section 5.1.2 you talk about the Authentication of a H.323 Mobile Terminal and say that it enables the verification of the authenticity of the terminal is context of the association it has with the Mobile User. You also explain this a bit further by adding that this is used to verify that the terminal can act on behalf of the authenticated User using it but you still state that the identity of the terminal is only relevant for the purposes of denying the usage of stolen terminals, etc. (black lists). So my question is that are you talking here about authenticating the terminal or are you referring to authenticating some sort of identifier that is used for the association between the terminal and the user? Your statement in item 3. about not needing to authenticate the user in subsequent terminal re-registrations would also seem to indicate the latter. Thus are you thinking of implementing a way to avoid the User authentication at least in Intra-zone location changes by introducing some sort of temporary local identifier for the terminal/user pair? I know that these are just requirements, but these statements seem to lead to that direction, if I have understood them correctly. The idea seems to be worth while to consider and we should discuss this further, but I don't quite see, how the terminal/user pair could really be authenticated, i.e. you can authenticate the User (by contacting the AuF) and you can authenticate the terminal (if proper cryptographic methods are specified also for the terminal), but how can you authenticate their association? Or am I just reading too much into this? Otherwise the contribution seems fine and I would suggest the addition of its contents to the draft Annex H. Let's have a bit of discussion before that, however. ------------------------------------------------ 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

Re: [Fwd: CPL/323]
by Sakae OKUBO 21 Jul '00

21 Jul '00

Dear Mr. Anderson, >Couyld you give me another APC number for the second CPL document: > >Title: "RFC-2824: Call Processing Language Framework and Requirements" APC-1886 has been allocated to this document. 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

Comments on H.225.0 v4 Whitedraft (sourceAddress)
by Klaghofer Karl ICN EN HC SE 81 20 Jul '00

20 Jul '00

One more try, since it seems that my previous mail I sent out yesterday did not arrive. Regards, Karl Klaghofer > -----Ursprüngliche Nachricht----- > Von: Klaghofer Karl ICN EN HC SE 81 > Gesendet am: Tuesday, July 18, 2000 12:02 > An: 'ITU-SG16(a)mailbag.cps.intel.com' > Betreff: Comments on H.225.0 v4 Whitedraft (sourceAddress) > > Rich and others, > > H.225.0v4 White draft, section 7.3.10 Setup reads: > "... > sourceAddress - Contains the alias addresses for the source; the dialed > digit string of the source is in the Q.931 Calling Party Number IE. The > primary address shall be first. > ..." > > PROPOSED TO BE CORRECTED TO: > "... > sourceAddress - Contains the alias addresses of the source. Note that the > E.164 Number of the source is contained within Calling Party Number > Information Element. The primary address shall be first. > ..." > > Background: > As part of the global v4 change to replace the term "e164" by the term > "dialedDigits" in the whole H.225.0 document, the sentense in current v4 > Whitedraft does not make sense anymore and should be corrected in v4 in > Portland. I think what we wanted to say is that the E.164 number is > contained within the Calling Party Number IE and not the dialed digit > string ! Dialed digit string (unstructured number which maybe may include > prefixes, etc would be put into sourceAddress.dialedDigits). > Note: There might be further sections where the simple replacement of the > term e164 by term dialed digits may have caused vagueness, since term e164 > in v2 was actually used for both - real E.164 but also unstructured digit > strings. > > Regards, > Karl Klaghofer > ------------------------------------------------------- > Karl Klaghofer, Siemens AG > Dpmt ICN EN HC D81, VoIP Architecture & Standardization > Hofmannstr. 51, 81359 Munich, Germany > Tel.: +49 89 722 31488; Fax.: +49 89 722 37629 > Mail: karl.klaghofer(a)icn.siemens.de > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

SIP-H.323 Interworking Draft
by Roy, Radhika R, ALCOO 20 Jul '00

20 Jul '00

Hi, Everyone: We are now pleased to inform that the "SIP-H.323 Interworking Requirements" Internet-Draft has been completed. You can find the draft as follows: Title : SIP-H.323 Interworking Requirements Author(s) : H. Agrawal, R. R. Roy, V. Palawat, A. Johnston, C. Agboh, K. Singh, and H. Schulzrinne Filename : draft-agrawal-sip-h323-interworking-reqs-00.txt Pages : 19 Date : 12-Jul-00 Abstract: "This document describes the requirements for the logical entity known as the interworking function (IWF) that will allow the interworking between the SIP(Session Initiation Protocol) and H.323 networks." This draft is expected to be presented in the 48th IETF meeting in Pittsburgh, USA (July 31 - August 4, 2000) and may become an Informational RFC if no future comments are received. The next step is to produce the "SIP-H.323 Interworking" draft for producing an IETF RFC based on this requirement draft. Best regards, Radhika R. Roy AT&T

1 0

[H.323 Mobility:] Update to Service Definitions for Annex H
by Roelands Marc 20 Jul '00

20 Jul '00

Hi all, I uploaded the updated version of MD-102 to ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/MD-102a_ServiceDefi nitions.zip . (it contains change bars to mark the added text) Regards, Marc Roelands Siemens ICN Dept. NC SD Atealaan 34 B-2200 Herentals Belgium Tel.: +32 14253965 Fax: +32 14222994 E-mail: marc.roelands(a)siemens.atea.be ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: H.323v4 and Annex D
by Francois Audet 19 Jul '00

19 Jul '00

Francois, The bi-directional TCP support was added during the last Geneva meeting. No issues were raised in Osaka. If there are issues with it, hopefully people will find them before November! We could specify that H.323 use H.245v7-- I do not see any reason why we should not consider that option. The only reason that I did not increase the revision number is that Annex D may be implemented optionally. If somebody chooses to implement H.323v4 without Annex D support, there is nothing they would need from H.245v7. I have no problem with mandating v7 for H.323v4. It is a small editorial change: a "7" instead of a "6" ;^) However, it really makes no difference at all to me. I'll be agreeable with whatever the experts believes makes the most sense. Me too.

1 0

H.323v4 and Annex D
by Francois Audet 19 Jul '00

19 Jul '00

Hi all, H.323v4 Annex D refers to an H.245 codepoint (t38FaxTcpOptions) that is only present in H.245v7 and not in H.246v6. How do we fix this? I think it is too late to fix H.245v6 isn't it? The alternatives would be: * Require H.245v7 for H.323v4, instead fo H.245v6 * Pull out Annex D of H.323 and make it require a different version of H.245. (Extremely bad idea since the Annex has a lot of other useful material) * Pull out the bidirectional TCP thing we added on-the-spot at the last meeting. At least until the next revision. Any views? Am I missing something? Also, there is a reference to something called t38Capability in Annex D: it should be t38Fax. (This is editorial). ----- François Audet Tel:+1 408 565 5675 <mailto:audet@NortelNetworks.com> mailto:audet@NortelNetworks.com Nortel Networks Fax:+1 408 565 2375 <http://www.nortelnetworks.com/> http://www.NortelNetworks.com

2 1

Re: [H.323 Mobility:] Service Definitions for Annex H
by Roy, Radhika R, ALCOO 19 Jul '00

19 Jul '00

Hi, Everyone: Further along the line of service definitions, I like to draw your attention related to AT&T contributions submitted (D.353 and D.354) in the last February'00 (Geneva) meeting. We can also discuss some of the definitions provided there along with Siemens's and Intel's contributions. In this connection, I am enclosing the copy of D.353 only. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Roelands Marc [mailto:Marc.Roelands@SIEMENS.ATEA.BE] Sent: Wednesday, July 19, 2000 3:37 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: [H.323 Mobility:] Service Definitions for Annex H Hi all, I have just uploaded MD-102 on Service Definitions for discussion, at ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/MD-102_ServiceDefin itions.zip . It is the first part of several Siemens/Intel inputs for the new chapter 5 for which input was requested in Osaka. I hope to send an updated/extended version still in a few days (i.e. before my holidays). (Since it is only a 19K file, I attach it here too.) Regards, Marc Roelands Siemens ICN Dept. NC SD Atealaan 34 B-2200 Herentals Belgium Tel.: +32 14253965 Fax: +32 14222994 E-mail: marc.roelands(a)siemens.atea.be

1 0

[H.323 Mobility:] Service Definitions for Annex H
by Roelands Marc 19 Jul '00

19 Jul '00

Hi all, I have just uploaded MD-102 on Service Definitions for discussion, at ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/MD-102_ServiceDefin itions.zip . It is the first part of several Siemens/Intel inputs for the new chapter 5 for which input was requested in Osaka. I hope to send an updated/extended version still in a few days (i.e. before my holidays). (Since it is only a 19K file, I attach it here too.) Regards, Marc Roelands Siemens ICN Dept. NC SD Atealaan 34 B-2200 Herentals Belgium Tel.: +32 14253965 Fax: +32 14222994 E-mail: marc.roelands(a)siemens.atea.be

1 0

Re: Request for an APC number
by Sakae OKUBO 19 Jul '00

19 Jul '00

Dear Rohit Gupta, >Is it possible to register a contribution to ITU-T SG16 for non-ITU >members? I wish to register > a contribution to suggest ammendments in the H.323 standard. > > Rohit Gupta > Hughes Software Systems > India Thank you for your contribution, to which APC-1885 has been allocated. 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

APC documents
by Sakae OKUBO 18 Jul '00

18 Jul '00

Dear Dale, APC-1884 has been allocated to your contribution: >"Decomposition of Gatekeeper Functions inside a Domain" source SONUS To other experts, please note the following contribution has been registered: >APC-1883 >Source: Columbia University >Title: CPL: A Language for User Control of Internet Telephony Services 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

H.225.0 v4 white paper: ASN.1 problem
by Horvath Ernst 18 Jul '00

18 Jul '00

The following definition (added for support of mobile systems) is not correct ASN.1: TBCD-STRING ::= OCTET STRING (FROM ("0123456789#*abc")) The keyword "FROM" indicates a "permitted alphabet" constraint and can only be applied to character string types, not to OCTET STRING. A possible correct definition would be: TBCD-STRING ::= IA5String (FROM ("0123456789#*abc")) The resulting PER encoding is 4 bit per character, but the digits do not represent BCD values since # and * come first in the canonical ordering of characters, i.e. "#" is encoded as '0000', "*" as '0001', "0" as '0010', "a" as '1100', etc. Question to the mobility experts who introduced this ASN.1 type: Is this an acceptable solution? Ernst Horvath Siemens AG ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Contribution number
by Sakae OKUBO 17 Jul '00

17 Jul '00

Dear Mr. Audet, In response to your request, the following APC numbers have been allocated to your two contributions: APC-1881 Nortel Networks Enforcing symmetric operation in the context of slow start for H.323v4 APC-1882 Nortel Networks Minor correction to H.323 Annex M.1 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

Annex E Question.
by Sasha Ruditsky 17 Jul '00

17 Jul '00

> Hi > > I believe that the following paragraph from the H.323 Annex E may be > understood differently by different people: > ------- > E.2.3.5 Session field > The session field shall be present in all payloads. The Session value > shall contain the CRV from the Q.931 messages. Specifically, the call > reference flag shall be included as the most significant bit of the > CallReferenceValue. This restricts the actual CRV to the range of 0 > through 32767, inclusive. > ------- > > I think this means that the Annex E session field is different (in the > Flag bit) for Setup and Connect messages of the same call. (Exactly like > CRV is). > I agree that the alternation of the 16th bit of the Annex E session field > in the messages of the same session (call) moving in different directions > is required, > but I do not think that the described behavior is obvious from the field's > name and its description. > > If there is agreement on the fact that the messages belonging to the same > call but moving in opposite directions shall have different values of the > 16th bit of the Annex E session field, that probably we need to state > this explicitly in the E.2.3.5. I agree that this is ALMOST what is > written their, but we all know how ambiguous may be the CRV-like field > description. > > > Sasha > > *********************************************** > Alexander(Sasha) Ruditsky > RADVision Ltd. > 24 Raul Wallenberg St. > Tel Aviv 69719 Israel > > Tel: +972-3-645-5220 > Fax: +972-3-645-6464 > Direct: +972-3-645-5273 > sasha(a)radvision.rad.co.il > *********************************************** > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

3 2

Re: [H.323 Mobility:]H.246 Annex E.1 and Annex E.2 White drafts
by Reddy, Paul K 17 Jul '00

17 Jul '00

Hi Everybody, Please visit Pictel site for reviewing the final H.246 Annex E.1 and H.246 Annex E.2 document, which are submitted for decision during November meeting in Geneva. http://standard.pictel.com/ftp/avc-site/011_Gen and http://standard.pictel.com/ftp/avc-site/Incoming Please review the documents and provide you comments to me at your earliest convenience. regards, Paul Editor of H.246 Annex E.1 & H.246 Annex E.2 Paul K. Reddy Intel Corporation Office Phone# +1 (503)-264-9896 Mobile Phone# +1 (503)-807-9564 Email: paul.k.reddy(a)intel.com -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] Sent: Wednesday, July 12, 2000 1:10 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] About GK discovery Hi Radhika et al, You're right, there is no point in continuing this discussion without other members' participation in it. I'll just make a couple of short points and then wait for hopefully somebody else to make their comments. > Therefore, all wireless environment is NOT bandwidth restrictive. Nor is wireline, of course. The point was that when you introduced the idea of the MGA, your argument was that it would SAVE bandwidth. In fact, as far as I could understand, this was the only argument you had for the use of MGA. Now you are saying that, although the MGA probably uses more bandwidth than the GRQ scheme, it is alright, because in some networks, the bandwidth is not so scarse. We discussed the idea of the MGA in Osaka and if you can remember, none of the participants of the discussion were supporting the addition of this message to H.323 (or RAS, to be more specific). When the bandwidth issue was discussed, I remember that you were asked to produce some data or information that would support the idea that in some cases the MGA would save bandwidth. So far you have not done so. So, as I said earlier, I'm happy to include the MGA in the annex, if you are able to convince, not only me, but other memebers interested in the issue, about the merits of the MGA scheme. Unfortunately this discussion hasn't been participated by the others so far. The idea of better interworking with mobile IP might be a reason for introducing the MGA. However, you yourself asked for technical reasoning and now I'm asking the same from you. Modelling other protocols is often a good guide in protocol design (and we surely have used it), but my opinion (and I feel it is shared by many others) is that just saying that because some other protocol has some, in this case alternate, mechanisms for doing something, is not a technical reason for adding exactly the same mechanisms to our protocol. You are asking me to explain why mobile IP uses these two mechanisms, but I think it is you who should explain that and furthermore explain why both of these are needed in H.323. Now, let's open the discussion for other members, I can see that this dialogue is not leading us anywhere. -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

Programme published for the "Implementing H.323" conference
by Paul E. Jones 16 Jul '00

16 Jul '00

Everyone, For those who are interested, UpperSide has published the programme for the upcoming conference on "Implementing H.323". You'll find the link to the programme on this page: http://www.upperside.fr/bah323.htm Best Regards, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Updated H.246 Annex E.1 document uploaded into Incoming dir of AVC-SITE on Pictel
by Sakae OKUBO 16 Jul '00

16 Jul '00

Dear Mr. Reddy, >I have uploaded the updated H.246 Annex E.1 White draft document into >Incoming directory of AVC-SITE. Please move it to Geneva November meeting >directory. This has been moved as requested: ftp://standard.pictel.com/avc-site/0011_Gen/H246AnnexE.1_White.zip or http://standard.pictel.com/ftp/avc-site/0011_Gen/H246AnnexE.1_White.zip 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

[Robustness] 7/13 teleconf
by Terry L Anderson 13 Jul '00

13 Jul '00

No one responded that they planned to join the teleconf today and indeed no one but me dialed in. I hope that this is due to the extremely short notice for the call rather than a loss of interest by those that have been participating. We will have another call next week and the following weeks on Thursdays at 11:00 EDT (15:00 UT) Thursday: July 20, July 27, Aug 3 11:00 EDT (15:00 UT) for 2 hr Phone: 1 888 559 7255 (calling from US) Phone: 1 908 860 0000 (calling from outside US) code: 531480 I would appreciate email directly to me mailto:tla@lucent.com (lets don't bother the reflector with this) if you plan to dial in so that I can adjust the number of ports if necessary. The current very rough draft of our annex is in the avc-site/Incoming/Robustness-AHG directory as: AnnexRdraft0711.doc. ftp://standard.pictel.com/avc-site/Incoming/Robustness-AHG/AnnexRdraft0711.… I will try to have an improved version on the site before the next call so look for AnnexRdraft#### representing a later date. If anyone has material for discussion at future calls, please post by ftp to the Robustness-AHG directory and send mail to the SG16 reflector with '[Robustness]' in the subject line. -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572(a)skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

1 0

Mr.L's TG configuration feature
by Li Li 13 Jul '00

13 Jul '00

Please see the attached. Open with Sharon's cellphone number. A firstcut writeup about what needs to be done for aug 14th deliverable to Mr.l on the trip enhancement. Comments and corrections are appreciated. Cheers, li ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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:] About GK discovery
by Roy, Radhika R, ALCOO 12 Jul '00

12 Jul '00

Hi, Jaakko: You are right that someone else should also take part in the technical discussion other than the two of us. Editor's main role is to perform moderation while providing fair chances for all. First of all, mobile IP did a very good argument while they designed the protocol, and bandwidth argument has been one of them. One of the points has been that bandwidth can be changed if the frequency of the "agent discovery" (similar to our MGA)message is changed. If you look into specs of mobile IP very carefully, you can see it (If needed, I can discuss with you in great detail what mobile IP did in the upcoming August'00 meeting). Even mobile IP folks prefer that "agent discovery message (similar to our MGA)" should be used instead of "agent solicitation (similar to our GRQ)." they have placed restrictions in using the "agent solicitation (similar to our GRQ)" message in mobile IP, but not for the "agent discovery message (similar to our MGA)" message. However, 3GPP folks did not like this. They like to use mobile IP's "agent discovery" message, but do not like multicast. So, they like to use "agent discovery" message using the unicast method. They have designed an implementation method how "unicast" should be done. As a result, they have created a "pseudo dynamic" environment for agent discovery. I guess that their primary concern has been to save the bandwidth not by reducing the frequency of the message, rather by making the situation less dynamic for the mobile environment using unicast method so that only bare minimum bandwidth is used. I am inviting technical comments from all members if they have any concerns related to the MGA message as proposed by AT&T contributions. Best regards, Radhika R. Roy -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@nokia.com] Sent: Wednesday, July 12, 2000 4:10 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] About GK discovery Hi Radhika et al, You're right, there is no point in continuing this discussion without other members' participation in it. I'll just make a couple of short points and then wait for hopefully somebody else to make their comments. > Therefore, all wireless environment is NOT bandwidth restrictive. Nor is wireline, of course. The point was that when you introduced the idea of the MGA, your argument was that it would SAVE bandwidth. In fact, as far as I could understand, this was the only argument you had for the use of MGA. Now you are saying that, although the MGA probably uses more bandwidth than the GRQ scheme, it is alright, because in some networks, the bandwidth is not so scarse. We discussed the idea of the MGA in Osaka and if you can remember, none of the participants of the discussion were supporting the addition of this message to H.323 (or RAS, to be more specific). When the bandwidth issue was discussed, I remember that you were asked to produce some data or information that would support the idea that in some cases the MGA would save bandwidth. So far you have not done so. So, as I said earlier, I'm happy to include the MGA in the annex, if you are able to convince, not only me, but other memebers interested in the issue, about the merits of the MGA scheme. Unfortunately this discussion hasn't been participated by the others so far. The idea of better interworking with mobile IP might be a reason for introducing the MGA. However, you yourself asked for technical reasoning and now I'm asking the same from you. Modelling other protocols is often a good guide in protocol design (and we surely have used it), but my opinion (and I feel it is shared by many others) is that just saying that because some other protocol has some, in this case alternate, mechanisms for doing something, is not a technical reason for adding exactly the same mechanisms to our protocol. You are asking me to explain why mobile IP uses these two mechanisms, but I think it is you who should explain that and furthermore explain why both of these are needed in H.323. Now, let's open the discussion for other members, I can see that this dialogue is not leading us anywhere. -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: [H.323 Mobility:] About GK discovery
by Jaakko Sundquist 12 Jul '00

12 Jul '00

Hi Radhika et al, You're right, there is no point in continuing this discussion without other members' participation in it. I'll just make a couple of short points and then wait for hopefully somebody else to make their comments. > Therefore, all wireless environment is NOT bandwidth restrictive. Nor is wireline, of course. The point was that when you introduced the idea of the MGA, your argument was that it would SAVE bandwidth. In fact, as far as I could understand, this was the only argument you had for the use of MGA. Now you are saying that, although the MGA probably uses more bandwidth than the GRQ scheme, it is alright, because in some networks, the bandwidth is not so scarse. We discussed the idea of the MGA in Osaka and if you can remember, none of the participants of the discussion were supporting the addition of this message to H.323 (or RAS, to be more specific). When the bandwidth issue was discussed, I remember that you were asked to produce some data or information that would support the idea that in some cases the MGA would save bandwidth. So far you have not done so. So, as I said earlier, I'm happy to include the MGA in the annex, if you are able to convince, not only me, but other memebers interested in the issue, about the merits of the MGA scheme. Unfortunately this discussion hasn't been participated by the others so far. The idea of better interworking with mobile IP might be a reason for introducing the MGA. However, you yourself asked for technical reasoning and now I'm asking the same from you. Modelling other protocols is often a good guide in protocol design (and we surely have used it), but my opinion (and I feel it is shared by many others) is that just saying that because some other protocol has some, in this case alternate, mechanisms for doing something, is not a technical reason for adding exactly the same mechanisms to our protocol. You are asking me to explain why mobile IP uses these two mechanisms, but I think it is you who should explain that and furthermore explain why both of these are needed in H.323. Now, let's open the discussion for other members, I can see that this dialogue is not leading us anywhere. -Jaakko ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

[Robustness] Teleconferences (and attn Mr OKUBO)
by Terry L Anderson 11 Jul '00

11 Jul '00

We need to begin a series of teleconferences to work on the H.323 Annex R: Robustness draft for Portland. The hope is to have it ready for determination at Geneva in November and so we need to get it reasonably complete in Portland. I have created a rough draft by merging material from all of the relevant APCs and TDs from the last few meetings, but it still needs a lot of work to complete it and make it all consistent. I will be smoothing it up but need the help of the Robustness Group is addressing the missing pieces and checking that I captured our agreements correctly. (Rich Bowen - I don't believe that our previous exchange on Status timers is reflected in this draft yet). I have uploaded this rough draft to the avc-site/Incoming directory as: AnnexRdraft0711.doc. ftp://standard.pictel.com/avc-site/Incoming/AnnexRdraft0711.doc I would like to keep from filling everyone's mailboxes with big attachments and so will upload drafts to the avc-site for our discussions. Mr OKUBO - would it be possible to for us to have a subdirectory of the Incoming directory for this use like the Mobility folks have been using? Last spring the Robustness group held conf calls on Thursdays at 11:00 AM EDT (15:00 UT or GMT). I would like to reactivate that series for the next month, but the first call will NOT fit the pattern. I would like to schedule the first call this Thursday: July 13 11:30 EDT (15:30 UT) for 1 hr Phone: 1 630 979 0100 code: 531 480 Note the time is 11:30 NOT 11:00 for this first call. I apologize for the short notice but would like to get started with a short organizational meeting with those that can attend. We need to work fast as I will be one vacation for two weeks immediately before the Portland meeting and so we only have one month to work. The other calls will fit a pattern: July 20, July 27, Aug 3 11:00 EDT (15:00 UT) for 2 hr Phone: 1 888 559 7255 (calling from US) Phone: 1 908 860 0000 (calling from outside US) code: 531480 I would appreciate email directly to me mailto:tla@lucent.com (lets don't bother the reflector with this) if you plan to dial in so that I can adjust the number of ports if necessary. -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572(a)skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

2 1

Re: [H.323 Mobility:] About GK discovery
by Roy, Radhika R, ALCOO 11 Jul '00

11 Jul '00

Hi, Jaakko: Let me clarify few things as follows: 1. All RAS messages are OPTIONAL. 2. H.323 mobility is applicable for all networking environment: Wireless [pico-, micro-, macro-cell]), wireless LAN, and/or wire-line network. Therefore, all wireless environment is NOT bandwidth restrictive. So, all H.323 entities are supposed to understand all RAS messages following the same principles. That is, if one does not like to use MGA, they will use GRQ (a simple timeout mechanism will do this). Please see how mobile IP is using these mechanisms. We do not need to re-INVENT the wheel. With respect to unicast implementation, kindly see how 3GPP is implementing mobile IP's "agent advertisement (similar to our MGA)" message. As I told you in my earlier emails sometime ago, the unicast method becomes psedo-dynamic considering the mobile environment. Last of all, it would be helpful to understand why mobile IP is using both "agent solicitation (like our GRQ)" and "agent advertisement (like our MGA)" for their solutions. Please also see why 3GPP has also accepted the mobile IP's both messages in their bandwidth restrictive environment. 3GPP's wireless networking environment will be one of our targets for implementation of our mobile H.323 solution. Mobile H.323 solution will NOT fly if the lower layer mobility (like 3GPP's mobile IP, IETF mobile IP) solution is NOT complemented or supported. H.323 mobility solution MUST provide a "hook" to interwork with the mobile IP. As an editor, I suggest to take a break for now and let other members participate in technical discussions because you are doing both - writing all you stuffs directly into the document as if you are making it a Rapporteur contribution as well opposing other contributions. The question is: Who will act moderator when there are disputes? I would not raise this question if you would explain why IETF and 3GPP folks are using both "agent solicitation (like our GRQ)" and "agent advertisement message (like our proposed MGA)" of mobile IP to solve the mobility problems. Best regards, Radhika R. Roy -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@nokia.com] Sent: Tuesday, July 11, 2000 6:27 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] About GK discovery 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 H & I uploaded
by Glen Freundlich 11 Jul '00

11 Jul '00

The white drafts for H.248 Annexes H & I have been uploaded to the Incoming directory at the Pictel avc-site. -- 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