March 2002 - sg16-avd - lists.packetizer.com

FW: Question about the use of alternateEndpoints in ACF
by Lyons, Terry 05 May '02

05 May '02

> H.225 v4 contains this text: > "7.11.2 AdmissionConfirm (ACF) > ... alternateEndpoints - A sequence of prioritized endpoint alternatives > for destCallSignalAddress or destinationInfo." > > The feature seems intended to support robustness through redundancy in > large networks, > where there may be more than one media gateway capable of serving the same > AdmissionRequest (ARQ). > This would accord with the support for alternate gatekeepers in H.323 v4: > "7.2.6 Alternate gatekeeper procedures > For the purposes of ensuring system availability, redundancy, and > scalability, the Gatekeeper may provide the RAS signalling function by > utilizing multiple physical or logical devices, referred to as Alternate > Gatekeepers. If the endpoint supports the Alternate Gatekeeper procedures > defined in this section, it should include the supportsAltGK field in the > GRQ and RRQ messages. > When an endpoint initiates communication with the Gatekeeper, it may be > provided with a list of Alternate Gatekeepers via the GCF message. If the > Gatekeeper does not respond to the subsequent RRQ, the endpoint shall > attempt to register with the Gatekeeper using the list of Alternate > Gatekeepers provided in the GCF. If no Alternate Gatekeeper responds, the > endpoint shall reinitiate the Gatekeeper discovery process." > > The problem is that there are no procedures specified for the use of > alternateEndpoints. > What is it that causes a caller to terminate its Setup attempt to one > destination and to initiate a Setup attempt to the next destination in > priority order? > > Can we presume that the critical event is receiving a ReleaseComplete? > Then how do we determine whether the release reason or cause code is final > (no further Setup should be sent) or not (try another destination)? > Some calls should end after an announcement is played, eg. "The number you > are calling has been disconnected", > and will never succeed no matter how many alternative endpoints are > attempted. > > If the intention of alternateEndpoints has already been clarified > somewhere, please point me to it and excuse my ignorance. > > - TLyons(a)sonusnet.com +1 732 625-3003 ext 212 >

3 2

Re: [imtch323implementors] Question
by Anatoli Levine 29 Mar '02

29 Mar '02

Gregory, your question is too broad to be answered easily : ). Effectively, there is a lot of solutions on the market today which will allow you to do it - but the real issues are the bandwidth you can have between the 2 sites, presence of firewalls/NATs, security requirements and so on. In general, I would suggest that you will take a look at the products list on H.323 Forum site (http://www.packetizer.com/iptel/h323/products.html) - depending on your specific requirements you should be able to find a solution there. Cheers, Anatoli Gregory wrote: > Hi,I would like to implement a VC through the net between two > companies one located in Brussels and the other in San Diego.What > would be the best solution ?You have to take into account that 5 to 10 > people would attend at each remote site !Thanks for your help, Greg--- > > You are currently subscribed to imtch323implementors as: > alevine(a)radvision.com > To unsubscribe send a blank email to > leave-imtch323implementors-6060E(a)mail.imtc.org

1 0

Question
by Gregory 29 Mar '02

29 Mar '02

Hi, I would like to implement a VC through the net between two companies one located in Brussels and the other in San Diego. What would be the best solution ? You have to take into account that 5 to 10 people would attend at each remote site ! Thanks for your help, Greg

1 0

H.323 Crypto Support
by Brian C. Wiles 25 Mar '02

25 Mar '02

In reading H.235, it seems to be vary vague with regards to how to setup encryption profiles. Also, I see no mention of other crypto algorithms such as Blowfish. To me, the H.235 support for encryption seems too complicated for something that should just needs to exchange keys and algorithms. In developing our H.323 stack, we decided to use SSL and a couple of simple non-standard parameters to provide the key exchange and algorithm negotiation. The reasons we did this was because: 1.) Crypto can be negotiated within the Setup and Connect messages, 2.) We wanted something that would work without an H.245 channel (H.323 Annex F implementation for example), and 3.) We could not find any H.323 products that supported crypto that we needed to be compatible with in the short term. So, unless there are any objections, I propose we add 2 parameters to the H.225 Setup and Connect messages: cryptoKey OCTET STRING OPTIONAL cryptoAlgorithm CryptoAlgorithm CryptoAlgorithm would then be defined as: CryptoAlgorithm ::= CHOICE { DES NULL, Triple-DES NULL, Blowfish NULL, ... } The cryptoKey would be the raw binary data for the key as the algorithm accepts. Since the program would know the length of the octet string, it could calculate the number of bits, if needed. Other algoritmhs could be added. We should probably set a requirement that all crypto-capable endpoints be able to use one of the above algorithms, to increase the chances of making a secure call. I would vote for Blowfish, but I'm not going to go against the majority if something else wins. Hopefully, I have explained this clearly. I think it's about time we came up with a simple solution that is easy to add new algorithms rather than having to use profiles. Our stack has employed essentially this same technique with non-standard parameters, and it has proved very efficient and stable. Plus, it's about time more H.323 endpoints support crypto since the regulations have been relaxed in the U.S. Any comments/flames? -Brian

3 2

Help requested !
by Gregory 22 Mar '02

22 Mar '02

Hello, I'm a student doing some research about VC for the University libre de Bruxelles. My thesis is about a statement of the different uses of VC. The questionnaire is very easy to fill in (it takes 5 '). I'll let you know about the report once I've done it. Thanks for your help, Grégory DUEZ stagiaire - ULB tél: 071/60 02 59 e-mail : gregoryduez(a)belgacom.net Questionnaire : 1) Why do you use videoconference for ? 2) Since how long have you been using videoconference ? 3) The type of material ? (hardware+software+accessories) 4) What are the advantages and disadvantages of VC ? 5) Don't you have any remarks ? 6) Don't you have any useful contacts (e-mail) of people using VC ? (or you can also forward them this e-mail) 7) Name and activites of your company Thanks for your help !

1 0

Question about "packet-based network originated call"
by Lyons, Terry 21 Mar '02

21 Mar '02

> -----Original Message----- > From: Lyons, Terry > Sent: Monday, March 18, 2002 4:47 PM > To: imtch323implementors(a)mail.imtc.org > Cc: ITU-SG16(a)echo.jf.INTEL.COM; Lyons, Terry > Subject: Question about "packet-based network originated call" > > Is this restriction of H.225.0 enforceable? > ------------------------------------------------------------- > Numbering plan identification (octet No. 3, bits 1-4) > - Encoded following the values and rules of Table 4-11/Q.931. A > number in the form of a dialed digit string should be coded as '0000' > Unknown. If set to '1001' (Private Numbering Plan) in a packet-based > network originated call, this indicates that: > 1) the dialed digit string is not present in Setup; and > 2) the call will be routed via an alias address in the > User-user information. > ------------------------------------------------------------- > > 1. How can one tell if it's a "packet-based network originated call"? > All H.323 Setups of practical interest are carried over a packet-based > network, ie. IP, > but did they originate there or were they gatewayed from a circuit-based > network? > Or is the quoted phrase trying to make some other distinction? > > 2. Talk of the dialed digit string and routing seems to fit best 7.2.2.4 > Called Party Number. > However, the passage reproduced above comes from 7.2.2.6 Calling Party > Number. > > > - TLyons(a)sonusnet.com +1 732 625-3003 ext 212 >

1 0

SG16 Feb 2002 outputs - H.248v2
by Christian Groves 12 Mar '02

12 Mar '02

G'Day all, I have uploaded to the following Geneve outputs: pl-031r1_H248_v2.zip to: ftp://standard.pictel.com/avc-site/Incoming/ Regards, Christian

2 1

Re: H.323 Series IG as approved in 2002 Geneva SG16 meeting
by OKUBO Sakae 09 Mar '02

09 Mar '02

Dear Mr. Vivek Bhargava, >I have uploaded the H.323 Series Implementer's Guide as H323SeriesIG.doc to >the Incoming directory at the Pictel server. > >Please make it available as an approved document for the February 2002, >Geneva meeting. Now it is available at /0202_Gen 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 *********************************************************

1 0

Documents from SG16 meeting in Geneva
by Terry L Anderson 04 Mar '02

04 Mar '02

I have uploaded the following documents: pl-029_H.248M_6_InactivityTimer.doc (Consented) pl-033_H248ImplementorsGuide.zip (approved) to the SG16 draft server at: ftp://standard.pictel.com/avc-site/Incoming/ They should soon be moved to: ftp://standard.pictel.com/avc-site/0202_Gen/ Note that since all Implementors Guide items applying to H.248 and Annexes A-E were swept into H.248V1Coregengum and H.248V2, this ImplementorsGuide only contains items applying to other Annexes. New corrections to H.248v1 or v2 will be added to this document in future versions. -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

2 1