- 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 … [View More]

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 … [View More]

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 … [View More]

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 ~~~~~~~~~~… [View More]

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 … [View More]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 > [View Less]

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)… [View More] 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 [View Less]

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 … [View More]

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, &… [View More]

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 … [View More]

1 0