July 2000 - sg16-avd - lists.packetizer.com

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