- sg16-avd - lists.packetizer.com

asn1 out of standards ?
by Michael Stini 28 Jun '01

28 Jun '01

Hi, I hope that I am addressing the correct mailing list. Where can I get the asn1 definitions related to the several Hxyz standards. Do I have to copy them out of the standard, or are there files / documents dedicated to the asn1 definitions? thank you very much, michael stini ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Summary of 3rd MoIP reliable transport conference call
by James_Renkel＠3COM.COM 27 Jun '01

27 Jun '01

The third in a series of conference calls to discuss a reliable transport protocol to be used with MoIP was held on Friday, June 22, 2001, between representatives of The CommWorks Corp. and Cisco Systems. As agreed at the Porto Seguro, BR, meeting of ITU-T SG16, the goal of these conference calls is to develop a joint contribution to the next meeting of TR-30.1 giving requirements for the MoIP reliable transport mechanism, and possibly an evaluation of existing protocols against those requirements. It is understood that there is a desire, once the requirements and possible evaluations have been presented to TIA TR-30.1 and agreed to by them, to have the requirements and possible evaluations presented to the IETF 51 meeting in London, UK, during the week of 8/5/2001. It is also understood that some parties plan to present a draft protocol proposal to that meeting. On the call from The CommWorks Corp. were: - Jim Renkel. >From Cisco Systems were: - Herb Wildfeuer; and - Mehryar Garakani. The call began by discussing the proposed summary of the first conference call. Cisco asked that the following sentence be added at the end of the 4th paragraph (Which begins "The call began by discussing ...."): It is also understood that some parties plan to present a draft protocol proposal to that meeting. With that addition, the meeting summary was agreed to and approved. After making that addition, Jim will send the meeting summary to relevant e-mail reflectors. Next, the proposed summary of the second conference call was reveiwed and approved as proposed. Jim will also send that summary to relevant e-mail reflectors. Next, the CommWorks proposed language for media stream / protocol stack switching was discussed. The definitions and first proposed agreement were tentatively accepted as proposed. There was much discussion of the second proposed agreement, and Jim will redraft it. Also, these proposals will be copied into a Word document so that changes can be tracked. Next, the meeting returned to Table 1 of CommWork's PCM01-020 contribution to the Nice, FR, rapporteur's meeting. It was agreed to split the "reliable" characteristic into "error detection" and "error correction" requirements. It was also agreed that "non-erasing" and "non-duplicating" were requirements for the reliable transport protocol to be used with MoIP. Jim will draft language stating these requirements. Finally, the next conference call was scheduled for Tuesday, 6/26/2001, 10:30 A.M., CDT, 8:30 A.M. PDT, with the same arrangements as this conference call. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Summary of MoIP reliable transport conference call
by James_Renkel＠3COM.COM 25 Jun '01

25 Jun '01

For those of you that don't have Visio 2000, here is the diagram that was attached to the first conference call summary converted to a .GIF: (See attached file: Reliable transport.gif) Sorry for any inconvenience. Jim Adrian Zakrzewski <azakrzewski(a)telogy.com> on 06/25/2001 09:48:31 AM Please respond to Adrian Zakrzewski <azakrzewski(a)telogy.com> Sent by: Adrian Zakrzewski <azakrzewski(a)telogy.com> To: tr301(a)tiacomm.org cc: (James Renkel/MW/US/3Com) Subject: RE: Summary of MoIP reliable transport conference call Although I knew the type of application I still couldn't open it :(((( The file was created by a newer version of Vision (I have ver. 5.0). James, could you possibly resend the drawing in some non-Microsoft format like .jpg or .bmp or even paste it into a word document. regards, Adrian > -----Original Message----- > From: Michael.McLaughlin(a)lakecommunications.com > [mailto:Michael.McLaughlin@lakecommunications.com] > Sent: Monday, June 25, 2001 6:57 AM > To: tr301(a)tiacomm.org > Cc: tr301(a)tiacomm.org > Subject: Re: Summary of MoIP reliable transport conference call > > > > > > Neither I nor my PC know what type of application is used to > open a VSD > file. > Could you convert it to a Word file for me ? > > Michael. > > > > > ********************************************************************** > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > postmaster(a)lakecommunications.com > > This footnote also confirms that this email message has been swept > by MIMEsweeper for the presence of computer viruses. > > www.lakecommunications.com > ********************************************************************** >

1 0

FW: [OpenH323]Fast Connect & H245 tunneling: do they really work?
by Agboh, Charles 24 Jun '01

24 Jun '01

-----Original Message----- From: Alain Daigle [mailto:daiglea@memotec.com] Sent: Tuesday, June 19, 2001 3:14 PM To: openh323(a)openh323.org Subject: Re: [OpenH323]Fast Connect & H245 tunneling: do they really work? Hi, H.323v2 seems to indicate that with faststart, the opening of a H245 channel is optional. Like in the following sections: 8.1.7.2 Switching to H.245 Procedures After establishment of a call using the Fast Connect procedure, either endpoint may determine that it is necessary to invoke call features that require the use of H.245 procedures. 8.2.3 Switching to a Separate H.245 Connection When H.245 encapsulation or Fast Connect is being used, either endpoint may choose to switch to using the separate H.245 connection at any time. And in the H323 implementation guide (from packetizer), there is a section on how a fastconnect call with no h245 channel should be terminated. Call Termination 2a. The following is how a call shall be terminated if the control channel is not open (Fast Connect was used and no control channel was ever established) but the call-signaling channel is open. Note that, in this case, only the initiating side is required to send ReleaseComplete. I assume that it is an oversight that the two cases are not consistent. I also assume that the remote EP will close the call-signaling channel upon receipt of ReleaseComplete and consider the call terminated. But if the remote is asking for a h245 channel (separate or tunneled) after the call is established, it's mandatory to support that... Alain Daigle ----- Original Message ----- From: "Chris Wayman Purvis" <chriswaymanpurvis(a)hotmail.com> To: <openh323(a)openh323.org> Sent: Tuesday, June 19, 2001 5:11 AM Subject: Re: [OpenH323]Fast Connect & H245 tunneling: do they really work? Nicola, >(2). We partially overcame the problem modifying the Openh323 GK in order >to >force h245Tunneling = TRUE in any case. Everything seems to be working >fine, >with both H.245 Tunnelling capable terminals (e.g. openphone) and H.245 >Tunneling non-capable terminals (e.g. Netmeeting). Now, we hoped to >experience some call setups based on the Fast Connect only, but even the >supposed Fast Connect capable terminals (e.g. ohphone & openphone) try to >perform a (tunneled) H.245 negotiation... even if some capabilieties seems >to be agreed by using the fastStart field... >==>Did anyone experience a TRUE Fast Connect setup (with no additional >FACILITY messages for H.245 tunneling)? With which terminals? If you find a device that does no H.245 negotiation at all, that device is not compliant with H.323. FastStart is a hack to get media flowing as soon as possible; it is not a substitute for H.245. Regards, Chris _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. ------------------------------------------------------------------------ Check the FAQ before asking! - http://www.openh323.org/~openh323/fom.cgi The OpenH323 Project mailing list, using Mailman. To unsubscribe or change your subscription options, goto http://www.openh323.org/mailman/listinfo/openh323 Maintained by Quicknet Technologies, Inc - http://www.quicknet.net ------------------------------------------------------------------------ ------------------------------------------------------------------------ Check the FAQ before asking! - http://www.openh323.org/~openh323/fom.cgi The OpenH323 Project mailing list, using Mailman. To unsubscribe or change your subscription options, goto http://www.openh323.org/mailman/listinfo/openh323 Maintained by Quicknet Technologies, Inc - http://www.quicknet.net ------------------------------------------------------------------------ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: Summary of MoIP reliable transport conference call
by David Duehren 22 Jun '01

22 Jun '01

Why do we get this after the "next conference call" is scheduled. Some of would like to participate. David Duehren Vice President of R&D, CTO dwd(a)brooktrout.com <mailto:dwd@brooktrout.com> Brooktrout, Inc. 410 First Avenue Needham, MA 02494 U.S.A. Tel: +1-781-433-9402 / Fax: +1-781-433-9202 > -----Original Message----- > From: James_Renkel(a)3com.com [mailto:James_Renkel@3com.com] > Sent: Friday, June 22, 2001 2:36 PM > To: itu-sg16(a)mailbag.cps.intel.com; tr301(a)tiacomm.org; > tsg16q11(a)itu.int > Subject: Summary of MoIP reliable transport conference call > > > > > A conference call was held on Friday, June 15, 2001, between > representatives of The CommWorks Corp. and Cisco Systems to begin > discussing the requirements for a reliable transport protocol > to be used > with MoIP, the evaluations of existing protocols against > those requirements, > and the eventual recommendation of an exisitng (possibly > modified) or new > protocol for that purpose. > > On the call from The CommWorks Corp. were: > - Mike Nicholas; and > - Jim Renkel. > > From Cisco Systems were: > - Herb Wildfeuer; and > - Mehryar Garakani. > > The call began by discussing the events that led up to the > call. It was > agreed that the goal of this and future follow-on calls is to > develop a > joint CommWorks / Cisco Systems contribution to the next meeting of > TR-30.1 giving requirements for the MoIP reliable transport mechanism > that could be agreed to by the two companies, and possibly an > evaluation > of existing protocols against these requirements that both > companies could > also agree to. Requirements and evaluations that could not be > agreed to by > the two companies would be left for presentation by each > company separately. > It is understood that there is a desire, once the > requirements and possible > evaluations have been presented to TIA TR-30.1 and agreed to > by them, to have > the requirements and possible evaluations presented to the > IETF 51 meeting > in London, UK, during the week of 8/5/2001. It is also > understood that some > parties plan to present a draft protocol proposal to that meeting. > > It was then agreed that proprietary information previously > disclosed in > contributions to the ITU-T and TIA groups studying MoIP could > be discussed > in these conference calls, but no new proprietary information > should be > first disclosed in these calls. > > It was then suggested and agreed that a small "reference > model" would be > useful in the discussions. The following was agreed to as the > refence model, > subject to future modification as may be necessary: > - The reliable transport issue is bi-directional and > symmetric, but is > perhaps best addressed by: considering the > uni-directional, asymetric > case; then combining the uni-directional case with a > mirror image of > itself to yield the bi-directional case. > - The uni-directional case can be represented by this diagram: > (See attached file: Reliable transport.vsd). > > Discussion then turned to CommWork's contribution PCM01-020, > "Transport > mechanisms in MoIP operations", to the Nice, FR, rapporteur's > meeting of > Q11/16, in particular a row by row discussion of Table 1, "Transport > mechanism characteristics", on page 8 of that contribution. > > It was agreed that the transport protocol must support > two-way, unicast > sessions. It need not support one-way only or multicast > sessions. Jim Renkel > will draft requriements statements reflecting this for > consideration for > inclusion in the joint contribution . > > It was agreed that the protocol should be structure > preserving, but that > this should be described as "packet oriented rather than > stream oriented." > Mehryar Garakani will draft requirements statements > reflecting this for > consideration for inclusion in the joint contribution . > > In considering the next characteristic, "Structure format > discriminating", > it was agreed that the issue really being considered here is that of > switching / transitioning among VoIP, FoIP, and MoIP "modes" > during the > course of a call. While no firm agreement was reached on the > requirements > and mechansim for doing this, the discussion seemed to > indicate that the > companies were close to agreement. Each company will draft > requirements > for this to be exchanged via e-mail prior to and discussed at the next > conference call. > > The next conference call is to be held Tuesday, 6/19/2001, at > 10:30 A.M., > CDT, 8:30 A.M., PDT. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Summary of 2nd MoIP reliable transport conference call
by James_Renkel＠3COM.COM 22 Jun '01

22 Jun '01

Another conference call was held on Tuesday, June 19, 2001, between representatives of The CommWorks Corp. and Cisco Systems to continue discussing a reliable transport protocol to be used with MoIP. On the call from The CommWorks Corp. were: - Mike Nicholas; - Fred Lucas; and - Jim Renkel. >From Cisco Systems were: - Herb Wildfeuer; and - Mehryar Garakani. The call began by discussing the e-mail summary of the previous conference call. As Cisco had just received the summary from CommWorks, they asked for additional time to review it. It was agreed that when conference call summaries were agreed to by all parties, they would be sent to the MoIP e-mail reflectors. Other working e-mails, however, would NOT be sent as is to the MoIP e-mail reflectors, but held until work had progressed to, e.g., a draft joint contribution. That would then be sent to the MoIP e-mail reflectors. Next, additional transport mechanism characteristics from PCM01-020 were considered. It was agreed that the non-corrupting, and order-preserving / sequenced characteristics were desirable for MoIP. Additionally, a characteristic not identified in PCM01-020, namely support for expedited and non-expedited data transfer, was identified and agreed to. Jim will draft requirement language for the non-corrupting characteristic, and Mehryar will draft requirement language for the sequenced and expedited characteristics. The remainder of the meeting was spent discussing media-stream(s) and protocol stack switching. Cisco did not yet have proposed language for this, so CommWork's proposed language was discussed. Several changes and additions to this were tentatively agreed to, and Jim will revise CommWork's proposal for the next conference call. The next conference call was scheduled for Friday, 6/22/2001, 10:30 A.M., CDT, 8:30 A.M. PDT, with the same arrangements as this conference call. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Summary of MoIP reliable transport conference call
by James_Renkel＠3COM.COM 22 Jun '01

22 Jun '01

A conference call was held on Friday, June 15, 2001, between representatives of The CommWorks Corp. and Cisco Systems to begin discussing the requirements for a reliable transport protocol to be used with MoIP, the evaluations of existing protocols against those requirements, and the eventual recommendation of an exisitng (possibly modified) or new protocol for that purpose. On the call from The CommWorks Corp. were: - Mike Nicholas; and - Jim Renkel. >From Cisco Systems were: - Herb Wildfeuer; and - Mehryar Garakani. The call began by discussing the events that led up to the call. It was agreed that the goal of this and future follow-on calls is to develop a joint CommWorks / Cisco Systems contribution to the next meeting of TR-30.1 giving requirements for the MoIP reliable transport mechanism that could be agreed to by the two companies, and possibly an evaluation of existing protocols against these requirements that both companies could also agree to. Requirements and evaluations that could not be agreed to by the two companies would be left for presentation by each company separately. It is understood that there is a desire, once the requirements and possible evaluations have been presented to TIA TR-30.1 and agreed to by them, to have the requirements and possible evaluations presented to the IETF 51 meeting in London, UK, during the week of 8/5/2001. It is also understood that some parties plan to present a draft protocol proposal to that meeting. It was then agreed that proprietary information previously disclosed in contributions to the ITU-T and TIA groups studying MoIP could be discussed in these conference calls, but no new proprietary information should be first disclosed in these calls. It was then suggested and agreed that a small "reference model" would be useful in the discussions. The following was agreed to as the refence model, subject to future modification as may be necessary: - The reliable transport issue is bi-directional and symmetric, but is perhaps best addressed by: considering the uni-directional, asymetric case; then combining the uni-directional case with a mirror image of itself to yield the bi-directional case. - The uni-directional case can be represented by this diagram: (See attached file: Reliable transport.vsd). Discussion then turned to CommWork's contribution PCM01-020, "Transport mechanisms in MoIP operations", to the Nice, FR, rapporteur's meeting of Q11/16, in particular a row by row discussion of Table 1, "Transport mechanism characteristics", on page 8 of that contribution. It was agreed that the transport protocol must support two-way, unicast sessions. It need not support one-way only or multicast sessions. Jim Renkel will draft requriements statements reflecting this for consideration for inclusion in the joint contribution . It was agreed that the protocol should be structure preserving, but that this should be described as "packet oriented rather than stream oriented." Mehryar Garakani will draft requirements statements reflecting this for consideration for inclusion in the joint contribution . In considering the next characteristic, "Structure format discriminating", it was agreed that the issue really being considered here is that of switching / transitioning among VoIP, FoIP, and MoIP "modes" during the course of a call. While no firm agreement was reached on the requirements and mechansim for doing this, the discussion seemed to indicate that the companies were close to agreement. Each company will draft requirements for this to be exchanged via e-mail prior to and discussed at the next conference call. The next conference call is to be held Tuesday, 6/19/2001, at 10:30 A.M., CDT, 8:30 A.M., PDT.

1 0

!! Rates Are At Their Lowest! Refinance Now!
by Mark 22 Jun '01

22 Jun '01

Mortgage Rates have been slashed again! *Lower your monthly payment! *Shorten the term of your loan! *Reduce your interest rate! SAVE MONEY!!! NOW is the time to refinance... rates have NEVER been lower! We CAN assist everyone, even if you've been turned down before! Take just a minute to complete this form and a Loan Consultant will contact you at your convenience. http://www.mortgagelenderpower.com Your information is secure, confidential and you are under NO OBLIGATION for this free analysis. **************************************************************** Since you have received this message you have either responded to one of our offers in the past or your address has been registered with us. If you wish to be removed please reply to: mailto:orlando9524@yahoo.com?subject=remove ********************************************************** ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Private telephone number in H.323v4
by Francois Audet 21 Jun '01

21 Jun '01

Of course... It's the sending side we need to clarify. > Oh, and on this particular case, surely receivers need to look in all > possible places, so it makes little difference where the > transmitter puts > this particular information! >

1 0

Re: Private telephone number in H.323v4
by Callaghan, Robert 21 Jun '01

21 Jun '01

Karl, I think that Francois's enhanced text will also help. Bob ------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks Tel: +1.561.997-3756 Fax: +1.561.997-3403 Email: <mailto:Robert.Callaghan@ICN.Siemens.com> Robert.Callaghan(a)ICN.Siemens.com -------------------------------------------------------- -----Original Message----- From: Klaghofer Karl ICN EN HC SE 81 Sent: Thursday, June 21, 2001 4:06 AM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: AW: Private telephone number in H.323v4 Francois, Paul, Bob and others, Please refer to section 6.1.2 of the most recent H.323 Implementers Guide (TD-031 PLEN) of the Brazil meeting. This IG section clarified previous inconsistencies in H.323 sections 7.8.2.1, 7.8.3.1 and 7.8.4.1 compared to H.225.0. I.e. the mentioned three H.323 sections have been updated for clarification on PNP number usage. Regards, Karl Klaghofer -----Ursprüngliche Nachricht----- Von: Francois Audet [mailto:audet@NORTELNETWORKS.COM] Gesendet: Mittwoch, 20. Juni 2001 01:27 An: ITU-SG16(a)mailbag.cps.INTEL.COM Betreff: Private telephone number in H.323v4 Hi, I just realize a contradiction in H.323v4 and H.225.0v4 concerning the encoding of "private telephone numbers" (i.e., the type we all use at work): * H.225.0v4 says that "Private telephone numbers" shall be encoded in the UUIE as private numbers, and NOT in the Q.931 information elements (Calling party IE, etc.). Let's call this the "Bob method". See Table 18/H.225.0 Note 1. * H.323v4 says that the Q.931 information element is used for "telephone numbers", and that the UUIE is used for things that are not telephone numbers. Let's call this the "Glenn method". See H.323v4/7.8.2.1 and 7.8.2.2. There is no conflict with both method for "public" telephone number, but there is a conflict for "private" telephone numbers. Which method is right, Bob's or Glenn's? ---- François AUDET, Nortel Networks mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> , tel:+1 408 495 3756

1 0

Re: Private telephone number in H.323v4
by Callaghan, Robert 21 Jun '01

21 Jun '01

Paul, I agree. Bob ------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks Tel: +1.561.997-3756 Fax: +1.561.997-3403 Email: <mailto:Robert.Callaghan@ICN.Siemens.com> Robert.Callaghan(a)ICN.Siemens.com -------------------------------------------------------- -----Original Message----- From: Francois Audet [mailto:audet@nortelnetworks.com] Sent: Wednesday, June 20, 2001 7:42 PM To: Callaghan, Robert; 'Glenn FREUNDLICH (E-mail)' Cc: 'SG16 ITU-T (E-mail)'; 'Paul JONES (E-mail)' Subject: RE: Private telephone number in H.323v4 Hi Bob, I understand what you are saying (and I fully agree). However, H.323v4 section 7.8.2.1 on Calling party number contradicts H.225.0 with the following: When address information represents a telephone number, the relevant information may appear in the Calling Party Number IE. This IE contains the caller's number, information about the number, and presentation and screening indicators found in octet 3a. This is the recommended mode of operation for the case where a PSTN Gateway sends a Setup message on the packet network. Alternatively, calling party information may appear in the sourceAddress, presentationIndicator, and screeningIndicator fields of the Setup message. This mode of operation is required when the sourceAddress is not in any form of telephone number (i.e., sourceAddress is not type a dialedDigits or partyNumber). I'm saying that H.323v4 is misleading and should really say the following to be consistent with H.225.0v4. When address information represents a public (E.164) telphone number or a telephone number of unknown type, the relevant information may appear in the Calling Party Number IE. This IE contains the caller's number, information about the number, and presentation and screening indicators found in octet 3a. This is the recommended mode of operation for the case where a PSTN Gateway sends a Setup message on the packet network. Alternatively, calling party information may appear in the sourceAddress, presentationIndicator, and screeningIndicator fields of the Setup message. This mode of operation is required when the sourceAddress is not in any form of a public or unknown telephone number (i.e., sourceAddress is not type a dialedDigits or partyNumber.164Number); an example of such a case is a Private Number which shall be encoded in a sourceAddress.partyNumber.privateNumber. Same applies for 7.8.2.2. Right? -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@icn.siemens.com] Sent: Wednesday, June 20, 2001 11:59 AM To: Audet, Francois [SC2:4K02:EXCH]; 'Glenn FREUNDLICH (E-mail)' Cc: 'SG16 ITU-T (E-mail)'; 'Paul JONES (E-mail)' Subject: RE: Private telephone number in H.323v4 Francois, See H.225.0 Section 7.2.2.4 (Called Party Number): Numbering plan identification (octet #3, bit 1-4) -*** Encoded following the values and rules of Table 4-9/Q.931. If set to "1001" (Private Numbering Plan) in a packet based network originated call, this indicates that (1)the E.164 address is not present in SETUP, and (2)the call will be routed via an alias address in the user-to-user information. This says that the identification of the Private Number Plan requires the call to be routed based on an alias address in the UUI. This also means that the Private Number Plan cannot indicate that a number conforming to a private numbering plan is present in the IE. It is possible to use the value indicating an Unknown Number Plan and place a private number in the IE. However, this is only a digit string without any defined structure. Bob ------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks Tel: +1.561.997-3756 Fax: +1.561.997-3403 Email: <mailto:Robert.Callaghan@ICN.Siemens.com> Robert.Callaghan(a)ICN.Siemens.com -------------------------------------------------------- -----Original Message----- From: Francois Audet [mailto:audet@nortelnetworks.com] Sent: Wednesday, June 20, 2001 1:40 PM To: Callaghan, Robert; 'Glenn FREUNDLICH (E-mail)' Cc: 'SG16 ITU-T (E-mail)'; 'Paul JONES (E-mail)' Subject: RE: Private telephone number in H.323v4 Hi Bob, I'm not sure I understand your point. The way I read it now: * H.323 says "Put a private number in the Q.931 IE"; and * H.225.0 says "Put a private number in the UUIE". Which one is it? I think you are saying H.225.0 is right (I tend to agree and so does Paul). We need to make sure everybody does (Glenn in particular), and H.323 should be clarified, because I would assume most people who read it will think they are supposed to put the IE in the Q.931 information element. -----Original Message----- From: Callaghan, Robert [SMTP:Robert.Callaghan@icn.siemens.com] Sent: Wednesday, June 20, 2001 05:00 To: Audet, Francois [SC2:4K02:EXCH]; 'Glenn FREUNDLICH (E-mail)' Cc: 'SG16 ITU-T (E-mail)'; 'Paul JONES (E-mail)' Subject: RE: Private telephone number in H.323v4 Francois, The problem is that both H.323 and H.225.0 state that in the Q.931 elements used for "telephone numbers" the code point indicating the presence of a private number is used to indicate that the address is in the UUI. It is not possible to conform to this usage and to use this value to indicate that the Q.931 element contains a private number. Bob ------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks Tel: +1.561.997-3756 Fax: +1.561.997-3403 Email: Robert.Callaghan(a)ICN.Siemens.com < mailto:Robert.Callaghan@ICN.Siemens.com <mailto:Robert.Callaghan@ICN.Siemens.com> > -------------------------------------------------------- -----Original Message----- From: Francois Audet [ mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> ] Sent: Tuesday, June 19, 2001 7:27 PM To: Callaghan, Robert; 'Glenn FREUNDLICH (E-mail)' Cc: 'SG16 ITU-T (E-mail)'; 'Paul JONES (E-mail)' Subject: Private telephone number in H.323v4 Hi, I just realize a contradiction in H.323v4 and H.225.0v4 concerning the encoding of "private telephone numbers" (i.e., the type we all use at work): * H.225.0v4 says that "Private telephone numbers" shall be encoded in the UUIE as private numbers, and NOT in the Q.931 information elements (Calling party IE, etc.). Let's call this the "Bob method". See Table 18/H.225.0 Note 1. * H.323v4 says that the Q.931 information element is used for "telephone numbers", and that the UUIE is used for things that are not telephone numbers. Let's call this the "Glenn method". See H.323v4/7.8.2.1 and 7.8.2.2. There is no conflict with both method for "public" telephone number, but there is a conflict for "private" telephone numbers. Which method is right, Bob's or Glenn's? ---- François AUDET, Nortel Networks < mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> >, tel:+1 408 495 3756

1 0

RE: Private telephone number in H.323v4
by Francois Audet 21 Jun '01

21 Jun '01

Hi Bob, I understand what you are saying (and I fully agree). However, H.323v4 section 7.8.2.1 on Calling party number contradicts H.225.0 with the following: When address information represents a telephone number, the relevant information may appear in the Calling Party Number IE. This IE contains the caller's number, information about the number, and presentation and screening indicators found in octet 3a. This is the recommended mode of operation for the case where a PSTN Gateway sends a Setup message on the packet network. Alternatively, calling party information may appear in the sourceAddress, presentationIndicator, and screeningIndicator fields of the Setup message. This mode of operation is required when the sourceAddress is not in any form of telephone number (i.e., sourceAddress is not type a dialedDigits or partyNumber). I'm saying that H.323v4 is misleading and should really say the following to be consistent with H.225.0v4. When address information represents a public (E.164) telphone number or a telephone number of unknown type, the relevant information may appear in the Calling Party Number IE. This IE contains the caller's number, information about the number, and presentation and screening indicators found in octet 3a. This is the recommended mode of operation for the case where a PSTN Gateway sends a Setup message on the packet network. Alternatively, calling party information may appear in the sourceAddress, presentationIndicator, and screeningIndicator fields of the Setup message. This mode of operation is required when the sourceAddress is not in any form of a public or unknown telephone number (i.e., sourceAddress is not type a dialedDigits or partyNumber.164Number); an example of such a case is a Private Number which shall be encoded in a sourceAddress.partyNumber.privateNumber. Same applies for 7.8.2.2. Right? -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@icn.siemens.com] Sent: Wednesday, June 20, 2001 11:59 AM To: Audet, Francois [SC2:4K02:EXCH]; 'Glenn FREUNDLICH (E-mail)' Cc: 'SG16 ITU-T (E-mail)'; 'Paul JONES (E-mail)' Subject: RE: Private telephone number in H.323v4 Francois, See H.225.0 Section 7.2.2.4 (Called Party Number): Numbering plan identification (octet #3, bit 1-4) -********** Encoded following the values and rules of Table 4-9/Q.931. If set to "1001" (Private Numbering Plan) in a packet based network originated call, this indicates that (1)the E.164 address is not present in SETUP, and (2)the call will be routed via an alias address in the user-to-user information. This says that the identification of the Private Number Plan requires the call to be routed based on an alias address in the UUI. This also means that the Private Number Plan cannot indicate that a number conforming to a private numbering plan is present in the IE. It is possible to use the value indicating an Unknown Number Plan and place a private number in the IE. However, this is only a digit string without any defined structure. Bob ------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks Tel: +1.561.997-3756 Fax: +1.561.997-3403 Email: <mailto:Robert.Callaghan@ICN.Siemens.com> Robert.Callaghan(a)ICN.Siemens.com -------------------------------------------------------- -----Original Message----- From: Francois Audet [mailto:audet@nortelnetworks.com] Sent: Wednesday, June 20, 2001 1:40 PM To: Callaghan, Robert; 'Glenn FREUNDLICH (E-mail)' Cc: 'SG16 ITU-T (E-mail)'; 'Paul JONES (E-mail)' Subject: RE: Private telephone number in H.323v4 Hi Bob, I'm not sure I understand your point. The way I read it now: * H.323 says "Put a private number in the Q.931 IE"; and * H.225.0 says "Put a private number in the UUIE". Which one is it? I think you are saying H.225.0 is right (I tend to agree and so does Paul). We need to make sure everybody does (Glenn in particular), and H.323 should be clarified, because I would assume most people who read it will think they are supposed to put the IE in the Q.931 information element. -----Original Message----- From: Callaghan, Robert [SMTP:Robert.Callaghan@icn.siemens.com] Sent: Wednesday, June 20, 2001 05:00 To: Audet, Francois [SC2:4K02:EXCH]; 'Glenn FREUNDLICH (E-mail)' Cc: 'SG16 ITU-T (E-mail)'; 'Paul JONES (E-mail)' Subject: RE: Private telephone number in H.323v4 Francois, The problem is that both H.323 and H.225.0 state that in the Q.931 elements used for "telephone numbers" the code point indicating the presence of a private number is used to indicate that the address is in the UUI. It is not possible to conform to this usage and to use this value to indicate that the Q.931 element contains a private number. Bob ------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks Tel: +1.561.997-3756 Fax: +1.561.997-3403 Email: Robert.Callaghan(a)ICN.Siemens.com < mailto:Robert.Callaghan@ICN.Siemens.com <mailto:Robert.Callaghan@ICN.Siemens.com> > -------------------------------------------------------- -----Original Message----- From: Francois Audet [ mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> ] Sent: Tuesday, June 19, 2001 7:27 PM To: Callaghan, Robert; 'Glenn FREUNDLICH (E-mail)' Cc: 'SG16 ITU-T (E-mail)'; 'Paul JONES (E-mail)' Subject: Private telephone number in H.323v4 Hi, I just realize a contradiction in H.323v4 and H.225.0v4 concerning the encoding of "private telephone numbers" (i.e., the type we all use at work): * H.225.0v4 says that "Private telephone numbers" shall be encoded in the UUIE as private numbers, and NOT in the Q.931 information elements (Calling party IE, etc.). Let's call this the "Bob method". See Table 18/H.225.0 Note 1. * H.323v4 says that the Q.931 information element is used for "telephone numbers", and that the UUIE is used for things that are not telephone numbers. Let's call this the "Glenn method". See H.323v4/7.8.2.1 and 7.8.2.2. There is no conflict with both method for "public" telephone number, but there is a conflict for "private" telephone numbers. Which method is right, Bob's or Glenn's? ---- François AUDET, Nortel Networks < mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> >, tel:+1 408 495 3756

2 1

AW: Private telephone number in H.323v4
by Klaghofer Karl ICN EN HC ID 71 21 Jun '01

21 Jun '01

Francois, Paul, Bob and others, Please refer to section 6.1.2 of the most recent H.323 Implementers Guide (TD-031 PLEN) of the Brazil meeting. This IG section clarified previous inconsistencies in H.323 sections 7.8.2.1, 7.8.3.1 and 7.8.4.1 compared to H.225.0. I.e. the mentioned three H.323 sections have been updated for clarification on PNP number usage. Regards, Karl Klaghofer -----Ursprüngliche Nachricht----- Von: Francois Audet [mailto:audet@NORTELNETWORKS.COM] Gesendet: Mittwoch, 20. Juni 2001 01:27 An: ITU-SG16(a)mailbag.cps.INTEL.COM Betreff: Private telephone number in H.323v4 Hi, I just realize a contradiction in H.323v4 and H.225.0v4 concerning the encoding of "private telephone numbers" (i.e., the type we all use at work): * H.225.0v4 says that "Private telephone numbers" shall be encoded in the UUIE as private numbers, and NOT in the Q.931 information elements (Calling party IE, etc.). Let's call this the "Bob method". See Table 18/H.225.0 Note 1. * H.323v4 says that the Q.931 information element is used for "telephone numbers", and that the UUIE is used for things that are not telephone numbers. Let's call this the "Glenn method". See H.323v4/7.8.2.1 and 7.8.2.2. There is no conflict with both method for "public" telephone number, but there is a conflict for "private" telephone numbers. Which method is right, Bob's or Glenn's? ---- François AUDET, Nortel Networks mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> , tel:+1 408 495 3756

1 0

RE: Private telephone number in H.323v4
by Callaghan, Robert 20 Jun '01

20 Jun '01

Francois, See H.225.0 Section 7.2.2.4 (Called Party Number): Numbering plan identification (octet #3, bit 1-4) -********** Encoded following the values and rules of Table 4-9/Q.931. If set to "1001" (Private Numbering Plan) in a packet based network originated call, this indicates that (1)the E.164 address is not present in SETUP, and (2)the call will be routed via an alias address in the user-to-user information. This says that the identification of the Private Number Plan requires the call to be routed based on an alias address in the UUI. This also means that the Private Number Plan cannot indicate that a number conforming to a private numbering plan is present in the IE. It is possible to use the value indicating an Unknown Number Plan and place a private number in the IE. However, this is only a digit string without any defined structure. Bob ------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks Tel: +1.561.997-3756 Fax: +1.561.997-3403 Email: <mailto:Robert.Callaghan@ICN.Siemens.com> Robert.Callaghan(a)ICN.Siemens.com -------------------------------------------------------- -----Original Message----- From: Francois Audet [mailto:audet@nortelnetworks.com] Sent: Wednesday, June 20, 2001 1:40 PM To: Callaghan, Robert; 'Glenn FREUNDLICH (E-mail)' Cc: 'SG16 ITU-T (E-mail)'; 'Paul JONES (E-mail)' Subject: RE: Private telephone number in H.323v4 Hi Bob, I'm not sure I understand your point. The way I read it now: * H.323 says "Put a private number in the Q.931 IE"; and * H.225.0 says "Put a private number in the UUIE". Which one is it? I think you are saying H.225.0 is right (I tend to agree and so does Paul). We need to make sure everybody does (Glenn in particular), and H.323 should be clarified, because I would assume most people who read it will think they are supposed to put the IE in the Q.931 information element. -----Original Message----- From: Callaghan, Robert [SMTP:Robert.Callaghan@icn.siemens.com] Sent: Wednesday, June 20, 2001 05:00 To: Audet, Francois [SC2:4K02:EXCH]; 'Glenn FREUNDLICH (E-mail)' Cc: 'SG16 ITU-T (E-mail)'; 'Paul JONES (E-mail)' Subject: RE: Private telephone number in H.323v4 Francois, The problem is that both H.323 and H.225.0 state that in the Q.931 elements used for "telephone numbers" the code point indicating the presence of a private number is used to indicate that the address is in the UUI. It is not possible to conform to this usage and to use this value to indicate that the Q.931 element contains a private number. Bob ------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks Tel: +1.561.997-3756 Fax: +1.561.997-3403 Email: Robert.Callaghan(a)ICN.Siemens.com < mailto:Robert.Callaghan@ICN.Siemens.com <mailto:Robert.Callaghan@ICN.Siemens.com> > -------------------------------------------------------- -----Original Message----- From: Francois Audet [ mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> ] Sent: Tuesday, June 19, 2001 7:27 PM To: Callaghan, Robert; 'Glenn FREUNDLICH (E-mail)' Cc: 'SG16 ITU-T (E-mail)'; 'Paul JONES (E-mail)' Subject: Private telephone number in H.323v4 Hi, I just realize a contradiction in H.323v4 and H.225.0v4 concerning the encoding of "private telephone numbers" (i.e., the type we all use at work): * H.225.0v4 says that "Private telephone numbers" shall be encoded in the UUIE as private numbers, and NOT in the Q.931 information elements (Calling party IE, etc.). Let's call this the "Bob method". See Table 18/H.225.0 Note 1. * H.323v4 says that the Q.931 information element is used for "telephone numbers", and that the UUIE is used for things that are not telephone numbers. Let's call this the "Glenn method". See H.323v4/7.8.2.1 and 7.8.2.2. There is no conflict with both method for "public" telephone number, but there is a conflict for "private" telephone numbers. Which method is right, Bob's or Glenn's? ---- François AUDET, Nortel Networks < mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> >, tel:+1 408 495 3756

1 0

RE: Private telephone number in H.323v4
by Francois Audet 20 Jun '01

20 Jun '01

Hi Bob, I'm not sure I understand your point. The way I read it now: * H.323 says "Put a private number in the Q.931 IE"; and * H.225.0 says "Put a private number in the UUIE". Which one is it? I think you are saying H.225.0 is right (I tend to agree and so does Paul). We need to make sure everybody does (Glenn in particular), and H.323 should be clarified, because I would assume most people who read it will think they are supposed to put the IE in the Q.931 information element. > -----Original Message----- > From: Callaghan, Robert [SMTP:Robert.Callaghan@icn.siemens.com] > Sent: Wednesday, June 20, 2001 05:00 > To: Audet, Francois [SC2:4K02:EXCH]; 'Glenn FREUNDLICH (E-mail)' > Cc: 'SG16 ITU-T (E-mail)'; 'Paul JONES (E-mail)' > Subject: RE: Private telephone number in H.323v4 > > Francois, > > The problem is that both H.323 and H.225.0 state that in the Q.931 > elements used for "telephone numbers" the code point indicating the > presence of a private number is used to indicate that the address is in > the UUI. It is not possible to conform to this usage and to use this > value to indicate that the Q.931 element contains a private number. > > Bob > ------------------------------------------------------- > Robert Callaghan > Siemens Enterprise Networks > Tel: +1.561.997-3756 Fax: +1.561.997-3403 > Email: Robert.Callaghan(a)ICN.Siemens.com > <mailto:Robert.Callaghan@ICN.Siemens.com> > -------------------------------------------------------- > > -----Original Message----- > From: Francois Audet [mailto:audet@nortelnetworks.com] > Sent: Tuesday, June 19, 2001 7:27 PM > To: Callaghan, Robert; 'Glenn FREUNDLICH (E-mail)' > Cc: 'SG16 ITU-T (E-mail)'; 'Paul JONES (E-mail)' > Subject: Private telephone number in H.323v4 > > Hi, > > I just realize a contradiction in H.323v4 and H.225.0v4 concerning the > encoding of "private telephone numbers" (i.e., the type we all use at > work): > * H.225.0v4 says that "Private telephone numbers" shall be encoded > in the UUIE as private numbers, and NOT in the Q.931 information elements > (Calling party IE, etc.). Let's call this the "Bob method". See Table > 18/H.225.0 Note 1. > * H.323v4 says that the Q.931 information element is used for > "telephone numbers", and that the UUIE is used for things that are not > telephone numbers. Let's call this the "Glenn method". See H.323v4/7.8.2.1 > and 7.8.2.2. > There is no conflict with both method for "public" telephone number, but > there is a conflict for "private" telephone numbers. > > Which method is right, Bob's or Glenn's? > > ---- > François AUDET, Nortel Networks > <mailto:audet@nortelnetworks.com>, tel:+1 408 495 3756 >

1 0

RE: Private telephone number in H.323v4
by Callaghan, Robert 20 Jun '01

20 Jun '01

Francois, The problem is that both H.323 and H.225.0 state that in the Q.931 elements used for "telephone numbers" the code point indicating the presence of a private number is used to indicate that the address is in the UUI. It is not possible to conform to this usage and to use this value to indicate that the Q.931 element contains a private number. Bob ------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks Tel: +1.561.997-3756 Fax: +1.561.997-3403 Email: <mailto:Robert.Callaghan@ICN.Siemens.com> Robert.Callaghan(a)ICN.Siemens.com -------------------------------------------------------- -----Original Message----- From: Francois Audet [mailto:audet@nortelnetworks.com] Sent: Tuesday, June 19, 2001 7:27 PM To: Callaghan, Robert; 'Glenn FREUNDLICH (E-mail)' Cc: 'SG16 ITU-T (E-mail)'; 'Paul JONES (E-mail)' Subject: Private telephone number in H.323v4 Hi, I just realize a contradiction in H.323v4 and H.225.0v4 concerning the encoding of "private telephone numbers" (i.e., the type we all use at work): * H.225.0v4 says that "Private telephone numbers" shall be encoded in the UUIE as private numbers, and NOT in the Q.931 information elements (Calling party IE, etc.). Let's call this the "Bob method". See Table 18/H.225.0 Note 1. * H.323v4 says that the Q.931 information element is used for "telephone numbers", and that the UUIE is used for things that are not telephone numbers. Let's call this the "Glenn method". See H.323v4/7.8.2.1 and 7.8.2.2. There is no conflict with both method for "public" telephone number, but there is a conflict for "private" telephone numbers. Which method is right, Bob's or Glenn's? ---- François AUDET, Nortel Networks mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> , tel:+1 408 495 3756

1 0

Private telephone number in H.323v4
by Francois Audet 19 Jun '01

19 Jun '01

Hi, I just realize a contradiction in H.323v4 and H.225.0v4 concerning the encoding of "private telephone numbers" (i.e., the type we all use at work): * H.225.0v4 says that "Private telephone numbers" shall be encoded in the UUIE as private numbers, and NOT in the Q.931 information elements (Calling party IE, etc.). Let's call this the "Bob method". See Table 18/H.225.0 Note 1. * H.323v4 says that the Q.931 information element is used for "telephone numbers", and that the UUIE is used for things that are not telephone numbers. Let's call this the "Glenn method". See H.323v4/7.8.2.1 and 7.8.2.2. There is no conflict with both method for "public" telephone number, but there is a conflict for "private" telephone numbers. Which method is right, Bob's or Glenn's? ---- François AUDET, Nortel Networks mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> , tel:+1 408 495 3756

2 1

H323 and NAT
by Santosh Kadam - Silicon Portals 18 Jun '01

18 Jun '01

Hi there, I am a new-bird in the VOIP applications , and I would like to clear some basic doubts. Basically I would like to know, why the H323 clients do not work behind the NAT or the proxy network ? I understand that the H323 non compliant clients like net2Phone are able to talk to the PC which r behind NAT but the H323 compliant applications like netMeeting , I am not able to communicate people behind NAT-Proxy network . why and what it can be preventing that these applications are not able to pass audio behind the NAT? Thanks n Regards, Santosh Kadam. e-mail: san(a)siliconportals.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: Porto Seguro output documents
by OKUBO Sakae 15 Jun '01

15 Jun '01

Dear Christian, >Please find the following attached: >H.248 Annex L Error Codes and Service Change Reasons >H.248 Annex M.2 MG Congestion Handling Package >H.248 Implementors' Guide >H.248 Series Supplement 2: Packages Guide They have been uploaded to the following place: http://standard.pictel.com/ftp/avc-site/0105_Por/ >H248_annexM2_Load_Control.zip >H248_Annex_L_consent.zip >H248_supp2_Packages_guide.zip >PL-015_H248_imp_guide.zip Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 ********************************************************* My contract with TAO finished on 31 March. Please change my e-mail address as above, though okubo(a)giti.or.jp will continue to work for some time. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Porto Seguro output documents
by OKUBO Sakae 14 Jun '01

14 Jun '01

Dear Mike, >I have uploaded H245Version8.zip to the incoming directory. Thank you. This has been moved to /0105_Por directory. Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 ********************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: sourceInfo in LRQ
by Francois Audet 14 Jun '01

14 Jun '01

Agreed. I want to make sure that the case where a Gatekepeer is using the endpoint's address because it is proxying its request. Like this: EP1(+1 408 565 5675) GK1 GK2 EP2(+1 408 495 3756) ARQ(Public.local=4953756) sourceInfo(h323-ID=EP1) ------------------------------> LRQ(Public.local=4953756) sourceInfo(h323-ID=EP1) --------------------------> In this example GK1 doesn't know how to resolve 4953756. It asks GK2 to help. It provides the sourceInfo of EP1 (e.g., an h323-ID or the phone number of the originator). GK2 uses the h323-ID to "figure out" the country code and area code that should be used for the Called party (if EP1 dials a local number, then it is the same country code as EP1's). Of course GK1 can do whatever it pleases since it might be using LRQs for its own purposes, not prompted by an ARQ. -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Thursday, June 14, 2001 10:15 AM To: Audet, Francois [SC2:4K02:EXCH]; ITU-SG16 Subject: Re: sourceInfo in LRQ Francois, I agree with you that what we should do is modify the text to be a bit more tolerant of what "source" means. It might be the source Gatekeeper or it might be the source endpoint's alias. It is possible to find either there today (since either an endpoint or a Gatekeeper may source an LRQ), so the text should reflect that. Paul ----- Original Message ----- From: Francois Audet <mailto:audet@NORTELNETWORKS.COM> To: ITU-SG16(a)mailbag.cps.INTEL.COM <mailto:ITU-SG16@mailbag.cps.INTEL.COM> Sent: Wednesday, June 13, 2001 2:40 PM Subject: sourceInfo in LRQ Hi all, The sourceInfor in LRQ states that it should be the alias address of the originator of the LRQ (as opposed to the originator of the call). One of the consequence of this is that if an endpoint sends an ARQ to its gatekeeper, and its gatekeeper can not resolve it, the LRQ that it will send to other gatekeepers may not have enough information to resolve the address. For example, if the number was a "local" number or a "national" number, the gatekeeper that receives the LRQ will not have enough context (where is the originator of the call) to resolve the address (like the country code of the calling user to figure out the contry code of the called user). Anybody has any views on this? My take is that the LRQ.sourceInfo should really reflect the alias address of the originator of the call (the initial ARQ) as opposed to the gatekeeper that originated the LRQ. An alternative would be to define a new field, but I'm not too keen on this approach since it won't work until H.323v5... ---- François AUDET, Nortel Networks mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> , tel:+1 408 495 3756

1 0

sourceInfo in LRQ
by Francois Audet 14 Jun '01

14 Jun '01

Hi all, The sourceInfor in LRQ states that it should be the alias address of the originator of the LRQ (as opposed to the originator of the call). One of the consequence of this is that if an endpoint sends an ARQ to its gatekeeper, and its gatekeeper can not resolve it, the LRQ that it will send to other gatekeepers may not have enough information to resolve the address. For example, if the number was a "local" number or a "national" number, the gatekeeper that receives the LRQ will not have enough context (where is the originator of the call) to resolve the address (like the country code of the calling user to figure out the contry code of the called user). Anybody has any views on this? My take is that the LRQ.sourceInfo should really reflect the alias address of the originator of the call (the initial ARQ) as opposed to the gatekeeper that originated the LRQ. An alternative would be to define a new field, but I'm not too keen on this approach since it won't work until H.323v5... ---- François AUDET, Nortel Networks mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> , tel:+1 408 495 3756

2 1

Query Regarding H.235 BES
by ivarghis＠HSS.HNS.COM 13 Jun '01

13 Jun '01

Hi I have a doubt regarding using BES (Radius ) in H.235 . The H235v2 has mention that in Radius default mode operation the encryption algorithms which are used is DES-CBC or 3DES-Outer CBC. But since the standard has not mentioned any way in which the keys (one key for DES-CBC and 3 keys for 3DES-OCBC ) should be generated, wouldnt it create an interoperability problem as different vendors will use different techniques for generating the keys. Note : In the case of of Baseline Security Profile the key is generated as follows shared key = sha1(password) Is there any endpoint which has implemented the H.235 BES support. If so can you send me some info regarding that. Thanks and Best Regards Ivan ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H.225.0 Annex G and Mobility
by Douglas Clowes 13 Jun '01

13 Jun '01

Annex G was in part based on the BEST protocol (APC-1480b, APC-1481 Torino Nov-98). That protocol was architected for a mobile-user application, although it is not depicted in the use cases included in APC-1480b. Much of what was in BEST was carried over into Annex G, but some parts were omitted, and other modified. If people are considering using Annex G for mobility, I would recommend a re-read of those documents (which are still available on the ftp site) ftp://standard.pictel.com/avc-site/till_0012/9811_Tor/APC-1480b.zip and ftp://standard.pictel.com/avc-site/till_0012/9811_Tor/APC-1481.zip Regards, Douglas Clowes Savant Solutions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Introducing new ASN.1 notation for imported elements in H.323 - Some ideas
by Frank Derks 12 Jun '01

12 Jun '01

H.323 imports ASN.1 constructs from H.248. If I am correct, these elements must be encoded as OCTET STRINGS. However, specifying elements in these way does not make it clear what is supposed to go in the OCTET STRING, unless this is added as a comment in the ASN.1 or as explanatory text somewhere else in the document. Recently, I was introduced to the TYPE-IDENTIFIER notation and it would seem that its "&Type part" could help to make the ASN.1 a bit clearer. E.g. the StimulusControl structure currently looks like: StimulusControl ::= SEQUENCE { nonStandard NonStandardParameter OPTIONAL, isText NULL OPTIONAL, h248Message OCTET STRING OPTIONAL } According to the text in Annex L/H.323, the h248Message element may contain any H.248 command. Assuming that this refers to the "Command" element from the H.248 ASN.1, the above can be re- written as: StimulusControl ::= SEQUENCE { nonStandard NonStandardParameter OPTIONAL, isText NULL OPTIONAL, h248Message TYPE-IDENTIFIER.&Type(Command) } This makes it clear that what goes in the h248 message, is a (h.248) command. The same can be applied to the following definitions: H248PackagesDescriptor ::= PackagesDescriptor H248SignalsDescriptor ::= SignalsDescriptor I.e. H248PackagesDescriptor ::= TYPE-IDENTIFIER.&Type(PackagesDescriptor) H248SignalsDescriptor ::= TYPE-IDENTIFIER.&Type(SignalsDescriptor) Any ideas? Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0