- sg16-avd - lists.packetizer.com

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

Re: Calling Party Number
by Francois Audet 06 Jul '00

06 Jul '00

Yes, I agree with your points. This should probably be documented. > -----Original Message----- > From: Klaghofer Karl ICN EN HC SE 81 > [mailto:Karl.Klaghofer@ICN.SIEMENS.DE] > Sent: Thursday, July 06, 2000 12:37 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Calling Party Number > > > Francois, > Some further thoughts on this issue, > > A calling party may provide both E.164 number and PNP number > within H.323 > (applies also in case of calling party being in SCN (e.g. PBX). > I agree, the E.164 address should be in H.225.0 Calling Party > Number IE; the > PNP address should be within the > Setup-UUIE.sourceAddress.partyNumber.privateNumber field. > > A second E.164 number - if received from the SCN - may be > sent further by > an ingress GWY within a second H.225.0 Calling Party Number > IE if the two > calling party number option is supported. > The alternative to map this second E.164 number received into > Setup-UUIE.sourceAddress.partyNumber.publicNumber field is > not recommended, > since we currently in H.225.0 have the problem that the > SetupUUIE.presentatioIndicator and > SetupUUIE.screeningIndicatir always apply > to all alias addresses in Setup-UUIE (PNP, E.164, etc) which > might be a > problem. > > Furthermore, you may want to provide any kind of > modified/prefixed calling > party number (e.g. by GWY or GK). This should then be placed within > Setup-UUIE.sourceAddress.dialledDigits field. > > Regards, > Karl > > -----Ursprüngliche Nachricht----- > Von: Francois Audet [mailto:audet@NORTELNETWORKS.COM] > Gesendet am: Donnerstag, 6. Juli 2000 19:38 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: Re: Reference which version of Q.931, etc.? > > > > Francois, > > I do not know of any impact directly. However, it will be > necessary to > verify what the impact might be, if any. > > As an additional though, Q.931 supports two Calling Party > IEs. Do we need > two calling party structures in ASN.1 for equivalent support? > > > I am not sure. > > I tought the 2 Calling Party IEs are only use when one is > public-network-provided (i.e., verified by Ma Bell) and the > other is "user" > or "private-network" provided. In that case, it might be > sufficient to only > use the information element (the 2 of them) since it will > always be E.164 > numbers (at least for the E.164 number). I could see 2 IEs > (one with the > verified E.164 number, the other with the un-verified > user-provided number), > or 1 IE (with the verified number) and 1 ASN.1 with the > private number. > > What do you think? > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com >

1 0

Re: [V4] H.323 URL
by Orit Levin 06 Jul '00

06 Jul '00

Paul! These are my comments: 1) I prefer that both, syntax and text, explicitly say the same. (So how about my syntax + your wording ?) 3) Agreed. It is up to you to come up with the text, that will be clear enough, but, in the same time, will not be restrictive for the sake of Annex O work. 4) Nothing is required to be corrected here. We can drop this Note 4 at all. May be it is more confusing then clarifying. It just says, that in other protocols, the IP address definition may be different. 5) RFC2396 clearly defines and explains the "escaped" part (among other general things). BTW: I am going on vacation for two weeks starting from Saturday. (I really need it.) Cheers, Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit(a)radvision.com -----Original Message----- From: Paul E. Jones <paulej(a)packetizer.com> To: Orit Levin <orit(a)radvision.com>; ITU-SG16(a)mailbag.cps.intel.com <ITU-SG16(a)mailbag.cps.intel.com> Date: Thursday, July 06, 2000 12:35 AM Subject: Re: Re: [V4] H.323 URL >Orit, > >> 2) TD-40a defines user without "1*" on purpose, keeping the possibility to >> have an empty user defintion. In this way both user and host are >"optional", >> but you can exactly parse and understand their meaning. This may be useful >> in Discovery Procedures (as mentioned in TD-40a). > >I changed the syntax as follows: > H323-URL = "H323:" [ user ] [ "@" hostport ] >and I changed the text below to read >``As indicated in the syntax, the user string and the hostport string are >both optional, though at least one shall be present.'' > >How is that? > >> 3) Use of DNS technology is the main reason... It is not the only one... >> Agreed, of cause. Still, a short "motivation" phrase to be included into >> H.323v4 is desired. (I also agree that Annex O should describe the >> recommended procedures :-) > > >Motivation without procedure is not very helpful. We must have a >contribution that clearly defines the procedure. > >> 4) "Note 4" says "The H323-URL is defined to use a form without brackets". > > >Perhaps I am missing something here. Specifically what needs to be >corrected? Currently, the syntax does not use brackets for IPv4 addresses. > >> 6) In regards to "escaped". I had the same dilemma while writing the >> original APC-1775. "One of the RFCs " summarizes the explanations already >> existing in referenced by us general RFCs. So, I think, we don't need a >> summary here. > > >Do you recall which RFC and section discusses the "escaped" production? > >Thanks, >Paul > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Calling Party Number
by Klaghofer Karl ICN EN HC SE 81 06 Jul '00

06 Jul '00

Francois, Some further thoughts on this issue, A calling party may provide both E.164 number and PNP number within H.323 (applies also in case of calling party being in SCN (e.g. PBX). I agree, the E.164 address should be in H.225.0 Calling Party Number IE; the PNP address should be within the Setup-UUIE.sourceAddress.partyNumber.privateNumber field. A second E.164 number - if received from the SCN - may be sent further by an ingress GWY within a second H.225.0 Calling Party Number IE if the two calling party number option is supported. The alternative to map this second E.164 number received into Setup-UUIE.sourceAddress.partyNumber.publicNumber field is not recommended, since we currently in H.225.0 have the problem that the SetupUUIE.presentatioIndicator and SetupUUIE.screeningIndicatir always apply to all alias addresses in Setup-UUIE (PNP, E.164, etc) which might be a problem. Furthermore, you may want to provide any kind of modified/prefixed calling party number (e.g. by GWY or GK). This should then be placed within Setup-UUIE.sourceAddress.dialledDigits field. Regards, Karl -----Ursprüngliche Nachricht----- Von: Francois Audet [mailto:audet@NORTELNETWORKS.COM] Gesendet am: Donnerstag, 6. Juli 2000 19:38 An: ITU-SG16(a)mailbag.cps.intel.com Betreff: Re: Reference which version of Q.931, etc.? Francois, I do not know of any impact directly. However, it will be necessary to verify what the impact might be, if any. As an additional though, Q.931 supports two Calling Party IEs. Do we need two calling party structures in ASN.1 for equivalent support? I am not sure. I tought the 2 Calling Party IEs are only use when one is public-network-provided (i.e., verified by Ma Bell) and the other is "user" or "private-network" provided. In that case, it might be sufficient to only use the information element (the 2 of them) since it will always be E.164 numbers (at least for the E.164 number). I could see 2 IEs (one with the verified E.164 number, the other with the un-verified user-provided number), or 1 IE (with the verified number) and 1 ASN.1 with the private number. What do you think? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Reference which version of Q.931, etc.?
by Francois Audet 06 Jul '00

06 Jul '00

I would agree that it should be the 1998 version (not that it matters since we are not using Q.931 in the first place, but our own "interpretation" of it). Are we even allowed to refer to "superceded" versions of a Recommendation? > -----Original Message----- > From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] > Sent: Thursday, July 06, 2000 5:11 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Reference which version of Q.931, etc.? > > > Rich, > > I guess that I misunderstood what you were saying. I agree that your > proposed solution is the only practical one at this time. > > As to Q.932, etc. I think that it would be best to keep all > references to > the versions in v2 for the same reason as for Q.931. > > Bob > > ------------------------------------------------------------------ > Robert Callaghan > Siemens Enterprise Networks > Tel: +1.561.923.1756 Fax: +1.561.923.1403 > Email: Robert.Callaghan(a)ICN.Siemens.com > ------------------------------------------------------------------ >>

1 0

Re: Reference which version of Q.931, etc.?
by Francois Audet 06 Jul '00

06 Jul '00

Francois, I do not know of any impact directly. However, it will be necessary to verify what the impact might be, if any. As an additional though, Q.931 supports two Calling Party IEs. Do we need two calling party structures in ASN.1 for equivalent support? I am not sure. I tought the 2 Calling Party IEs are only use when one is public-network-provided (i.e., verified by Ma Bell) and the other is "user" or "private-network" provided. In that case, it might be sufficient to only use the information element (the 2 of them) since it will always be E.164 numbers (at least for the E.164 number). I could see 2 IEs (one with the verified E.164 number, the other with the un-verified user-provided number), or 1 IE (with the verified number) and 1 ASN.1 with the private number. What do you think?

1 0