- sg16-avd - lists.packetizer.com

Re: H.323 and NAT
by Tom-PT Taylor 09 Mar '98

09 Mar '98

How about a protocol that allows applications to discover NAT operating in front of them and obtain external/local address pairs in advance of use? > -----Original Message----- > From: Annika Kilegran [SMTP:Annika.W.Kilegran@TELIA.SE] > Sent: Monday, March 09, 1998 4:06 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.323 and NAT > > Network Address Translation (NAT) is used as a solution to the > problem of few available IPv4 addresses. The idea is to use … [View More]private > addresses within a domain and when IP traffic leaves or enters the > internal network the address fields are translated between the public > IP > addresses and the corresponding private address. A private address is > only associated with a public address when the node communicates > externally. By using this mechanism it is possible to have many more > IP > nodes in the private domain then the number of assigned public IP > addresses to that domain. NAT is a defacto solution to connect for big > groups of users. > > > The combination of NAT and applications exchanging IP addresses in the > protocol (like H.323 does) creates problems. > The applications are either broken, or gets more difficult to run. > There are different solutions for how to be able to run these > application in combination with NAT. We list the > alternatives in the bottom of this mail. > > Does anybody on the mailing have an opinion? > For instance, a Gatekeeper might have to interact with the NAT > (co-located), and possibly act as an application gateway. > By the way the question might com up on the DAVIC meeting next week. > > Best regards, > > Annika Kilegran > > ********************************************************************** > Telia Research > S-136 80 HANINGE, Sweden > Tel +46 8 707 55 15 > Fax +46 8 707 53 10 > Email: annika.w.kilegran(a)telia.se > ********************************************************************** > * > > > The differnt alternatives: > ----------------------------- > 1) Use an Application layer gateway, that translates addresses in the > application protocol. Used today for FTP. > Will work, but will be quite complex for H.323. The Application layer > gateway would typically be co-located with the NAT-box. > > 2) Use the location of servers, and the configuration of servers and > clients to overcome the problem. > DNS is handled this way today. Seems not to work for H.323. > > 3) A combination of alternatives1 and 2 should be possible, and may > acheive a lesser complexity than 1. > > 4) NAT bypass using tunneling over the > local network. The global address is > available in the host and is used in the application, removing the > problem. This kind of solution have been > proposed in contributions to IETF. > > 5) Skip NAT altogether. Instead use IPv.6, or something like NNAT (No > NAT) for IPv.4. NNAT will completely replace NAT, and uses DHCPv.6 for > assigning global addresses. NNAT remains to be specified for > IPv.4 operation. [View Less]

1 0

Re: XRS RequestSeqNum can't be zero
by Jim Toga 06 Mar '98

06 Mar '98

Paul, I'm not positive, (it was in a galaxy far, far away...) I believe the original intent behind not having 0, was so that implementations could recognize a mal-formed or illegal value. The usefulness of this may be debated.... jimt. At 08:48 AM 3/6/98 -0800, you wrote: >>---------- >>From: Ernst Horvath[SMTP:Ernst.Horvath@SIEMENS.AT] >>A clean fix for the problem you discovered would be to allow 0 as a >>special value in RequestSeqNum: >> >> … [View More]

1 0

ad hoc Multipoint Conference - about Gatekeeper routing
by Vincent Chen 06 Mar '98

06 Mar '98

Dear All, Is it a must for the Gatekeeper to route the Call Signalling Channel and H.245 Control Channel in order to support ad hoc Multipoint Conference? If it is a must, what shall the Gatekeeper and MC do? Is it correct that Gatekeeper shall pass (redirect)the transport address of the two endpoints to MC and let MC to start the Capability exchange procedure (TerminalCapabilitySet) with them? So that the previous H.245 channel between the two endpoint … [View More]

2 1

RAS timeToLive not fixed
by Paul Long 06 Mar '98

06 Mar '98

I noticed that timeToLive is still defined in H.225.0v2 (h2250v2w-final-w6.doc) as INTEGER (1..4294967296). Wasn't the max supposed to have been changed in v2 to 4294967295 before Decision? As it is, this field has the distinction of being the only INTEGER field in all of H.32x-dom that won't fit in a 32-bit variable. :-( I think I'll change our ASN.1 syntax to 4294967295. -- Paul Long___________________________http://www.cmpu.net/public/plong Smith Micro Software, Inc.__________http://www.smithmicro.com/

1 0

Re: XRS RequestSeqNum can't be zero
by Paul Long 06 Mar '98

06 Mar '98

>---------- >From: Ernst Horvath[SMTP:Ernst.Horvath@SIEMENS.AT] >A clean fix for the problem you discovered would be to allow 0 as a >special value in RequestSeqNum: > > RequestSeqNum ::= INTEGER (0|1..65535) > -- 0 reserved for XRS if the received message could not be decoded This isn't so clean. This would produce a different, non-interoperable encoding. For example, the value, 8, would produce an ASN.1 PER encoding of 8 instead of 7. The encoding syntax would stay … [View More]

1 0

Re: XRS RequestSeqNum can't be zero
by Ernst Horvath 06 Mar '98

06 Mar '98

Dear Mr. Long, A clean fix for the problem you discovered would be to allow 0 as a special value in RequestSeqNum: RequestSeqNum ::= INTEGER (0|1..65535) -- 0 reserved for XRS if the received message could not be decoded (A similar problem exists in ROSE where the InvokeID - an INTEGER - is used to associate responses with requests; usually the response contains the same InvokeID as the request, except when the request cannot be decoded. In this case a Reject is sent with InvokeID ::= … [View More]

1 0

XRS RequestSeqNum can't be zero
by Paul Long 05 Mar '98

05 Mar '98

Annex H/H.225.0v2 states that "RequestSeqNum ::= INTEGER (1..65535)," but 7.17/H.225.0v2 says that requestSeqNum in XRS "shall be the requestSeqNum of the unknown message, if it can be decoded, and zero otherwise." Two problems: 1. It can't be set to zero because that value would be out of range, so H.225.0 contradicts itself here. 2. If the requestSeqNum of the unknown message cannot be decoded, there is no way to indicate this in the XRS. The receiver of XRS doesn't know whether the value,… [View More]

1 0

Notice of the Q.12-14/16 Yokosuka meeting
by Sakae Okubo 05 Mar '98

05 Mar '98

To Experts of ITU-T SG16 Q.12/16, Q.13/16 and Q.14/16 Cc Mr. P-A. Probst, Chairman of SG16 Mr. G. Helder, Vice-Chairman of SG16 Mr. F. Tosco, Chairman of WP2/16 Mr. F. Bigi, ITU-TSB Mr. T. Geary, Rapporteur for Q.11/16 De Sakae OKUBO Rapporteur for Q.12/16 in ITU-T SG16 Graphics Communication Laboratories 6F Annex Toshin Bldg. 4-36-19 Yoyogi Shibuya-ku, Tokyo 151 Japan Tel: +81 3 5351 0181 Fax: +81 3 … [View More]5351 0184 E-mail: okubo(a)gctech.co.jp Dale SKRAN Rapporteur for Q.13/16 in ITU-T SG16 Ascend Communications, Inc. 621 Shrewsbury Avenue Shrewsbury, NJ 07702 USA Tel: +1 908 450 1635 Fax: +1 908 450 1611 E-mail: Dale.Skran(a)ascend.com Gary Thom Rapporteur for Q.14/16 in ITU-T SG16 Delta Information Systems Inc. Horsham Business Center Bldg. 3 300 Welsh Road, Horsham, PA 19044 Tel: +1 215 657 5270 ex 23 Fax: +1 215 657 5273 E-mail: gthom(a)delta-info.com ------------------------------------------------ Subject: Notice of Q.12-14/16 Rapporteur Meeting Date: 5 March 1998 ------------------------------------------------ Dear SG16 Colleagues, The subject meeting of ITU-T SG16 experts will be held in Yokosuka, Japan at the kind invitation of Group of Interested Organizations in Japan. Please note that Q.11 (system aspects) will meet concurrently at the same place and have joint sessions with Q.12-14/16. 1. Date ^^^^^^^ 14 (Tuesday) - 17 (Friday) April 1998 starting at 9:00 on the first day 2. Venue ^^^^^^^^ Yokosuka Research Park (YRP) YRP Center #1 Building 3-4 Hikarino-oka, Yokosuka-shi 239-0847 Japan Tel: +81 468 47 ???? (to be advised later) Fax: +81 468 47 ???? (to be advised later) 3. Topics (tentative) ^^^^^^^^^^^^^^^^^^^^^ 1) Review of the relevant group meetings 2) Q.12/16 B-ISDN multimedia systems and terminals - Generate white contribution for H.310 V2 - Generate white contribution for H.bmultipoint - Progress in other technical topics 3) Q.13/16 Packet switched multimedia systems and terminals - Liaison to SG8 Q4 re RT fax - H.323 Annex D for RT fax (generate white) - Work with Q.14 on MIBs - Other technical work 4) Q.14/16 Common protocols, MCUs and protocols for interworking with H.300-series terminals - H.235 V2 issues - H.245 V4 for Decision (9/98) - H.245 V5 issues - H.246 Annex B for Determination (9/98) - Other H.246 annexes and issues - H.MediaMIB for Determination (9/98) - Audio and video control - Other technical issues 5) Any other Q.12-14/16 related matters - Interaction with other groups 6) Future work 4. Documents ^^^^^^^^^^^^ /// Registration of the document: by April 3 /// /// Distribution of the document: by April 7 /// /// Use the ftp site or e-mail reflector for distribution. /// 1) When you are going to submit a document, please notify S. Okubo as soon as possible, by April 3 (Friday) at the latest. Document number (APC-1nnn) will be allocated. Early indication of your submission plan is welcome. Note - Prefix "APC" comes from Atm (Q.12/16), Packet based (Q.13/16) and Common protocols (Q.14/16) based on coordination with Q.1 ("Q1City"), Q.3 ("T120"), Q.11 ("Q11"), Q.15 ("Q15") groups. 2) You are advised to include a header as follows: ------------------------------------------------------------------ | | | ITU Telecommunication Standardization Sector Document APC-{1nnn}| | Study Group 16 {Version m if relevant}| | Q.12-14/16 Rapporteur Meeting {Date}| | Yokosuka, 14-17 April 1998 | | | | SOURCE*: { } | | TITLE : { } | | PURPOSE: {Proposal, Discussion, Information, Report, etc.} | | | | _________________________ | | | | | | | | *Contact: Name, e-mail | ------------------------------------------------------------------ 3) All the contributors are requested to distribute their documents as early as possible, at least 7 calendar days in advance of the meeting (by April 7) by posting them at either of the following: - GCL ftp site (please advise S. Okubo of your posting) Site: ftp.gctech.co.jp Login name: itu-t Password: sg15!avc Directory: Incoming - Q.12-14/16 experts reflector e-mail address: itu-sg16(a)mailbag.jf.intel.com Please avoid the use of reflector when your document is voluminous. Use of Word for Windows 2.0 or 6 or pure text is recommended. 4) Input documents can be retrieved from 9804_Yok directory of the ftp site. 5) Please bring 60 copies of your document to Yokosuka. Your cooperation is needed to start the meeting with all the documents at hand; please note that the copying capacity at the meeting site is limited. 5. Logistic information ^^^^^^^^^^^^^^^^^^^^^^^ Please see the invitation which has been provided by the meeting host (/9804_Yok/invitation98.zip at the ftp site). 6. Registration ^^^^^^^^^^^^^^^ Please notify Mr. Harasaki (e-mail: harasaki(a)ccm.CL.nec.co.jp) with copy to Rapporteurs (e-mail: okubo(a)gctech.co.jp, Dale.Skran(a)ascend.com, gthom(a)delta-info.com) as soon as possible if you plan to attend the Yokosuka meeting. 7. Hotel Room Reservation ^^^^^^^^^^^^^^^^^^^^^^^^^ Please directly contact the following hotel using the form contained in the invitation. Yokosuka Prince Hotel 3-27 Hon-cho, Yokosuka 238-0041, Japan Tel: +81 468 21 1111 Fax: +81 468 21 1141 URL: http://www.princehotels.co.jp/yokosuka-e/index.html We are looking forward to meeting with you in Yokosuka. Sincerely yours, Sakae OKUBO Dale SKRAN Gary THOM [View Less]

1 0

Far End Camera Control in H.323
by Anupama Anantharaman 04 Mar '98

04 Mar '98

Hello all, I have some questions pertaining to Far End Camera Control in H.323. I would appreciate it much if someone could please answer them. Is FECC going to be done through the T.120 channel? If so, then is H.281 encapsulated within t.120 stack? Or has the Standards committee come up with a different scheme to do Far End Camera Control? Thanks in advance, Anupama Phone: 408-922-4785 email: anupama(a)vtel.com

1 0

Invitation to the Yokosuka meeting from the host
by Sakae Okubo 03 Mar '98

03 Mar '98

Dear Q.12-14 colleagues, Sakai> I attached the invitation form (including registration form and Sakai> hotel reservation form) for the Yokosuka meeting in "Word95/6.0" Sakai> compatible format. I have created 9804_Yok directory at the ftp site and stored this zipped file. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: … [View More]

1 0