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

Re: H.323 and NAT
by Scott Bradner 09 Mar '98

09 Mar '98

Just to let you know - the IETF has just created a new working group to look at NAT issues. If anyone on this list would like to join the mailing list the instructions are in the working group charter ( http://www.ietf.org/html.charters/nat-charter.html ) Following Annika's questions - if you have any worries or suggestions for the IETF WG to keep in mind relative to H.323 please send them to the NAT mailing list thanks Scott

1 0

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 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.

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: >> >> 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 the same (same number >of bits, etc.), but the semantics would change (values are normalized >differently). An alternative would be INTEGER (1..65535|65536), but even >though normalization is now the same (1-based instead of 0-based), the >new, reserved value, 65536, would cause a semantic decode error in an >ASN.1 decoder still using the old range, 1..65535. I don't see any clean >way to fix it. > >BTW, does anyone know why RequestSeqNum wasn't defined as INTEGER >(0..65535) in the first place? This would have provided a much more >natural wrap-around from 65535 to 0. Not a big deal, though. Just >wondering. > >Paul Long >Smith Micro > > ************************************************************************* *** +1-503-264-8816(voice) +1-503-264-3485(fax) *** *** jtoga(a)ideal.intel.com Intel - Hillsboro, OR. *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41*** *************************************************************************

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 can becomes two H.245 between the two endpoint and the MC? GateKeeper / \ One H.245 Control Channel between / \ Endpoint1 and Endpoint2 / \ routed by Gatekeeper Endpoint1 Endpoint2 MC / \ Two H.245 Control Channels between / \ the two endpoint and MC / \ Endpoint1 Endpoint2 Thank you for answering my question! Best Regards, Vincent Chen E-mail: VincentSHChen(a)acer.com.tw

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 the same (same number of bits, etc.), but the semantics would change (values are normalized differently). An alternative would be INTEGER (1..65535|65536), but even though normalization is now the same (1-based instead of 0-based), the new, reserved value, 65536, would cause a semantic decode error in an ASN.1 decoder still using the old range, 1..65535. I don't see any clean way to fix it. BTW, does anyone know why RequestSeqNum wasn't defined as INTEGER (0..65535) in the first place? This would have provided a much more natural wrap-around from 65535 to 0. Not a big deal, though. Just wondering. Paul Long Smith Micro

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 ::= NULL. The same approach could be used in H.225.0, but this would be a rather drastic change totally incompatible with version 1). Ernst Horvath Siemens AG Paul Long wrote: > 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, let's say 1, > reflects the value of the decoded requestSeqNum of the unknown message > or is a dummy value used in place of an undecodable requestSeqNum. IOW, > to the receiver of the XRS message, the value of the requestSeqNum field > may _or may not_ refer to a message it sent, and therefore the value > cannot be trusted. I don't know of any way to fix this. Maybe we can > just always assume that the value is valid--it was successfully decoded > from the unknown message--and don't worry about the small chance of it > being wrong. > > > Apart from these problems, the passage quoted, above, from > 7.17/H.225.0v2 implies that RequestSeqNum is unique across all outgoing > RAS messages; otherwise, what is the point of providing it in XRS--how > could the receiver of an XRS identify which message was not understood > if it uses a separate requestSeqNum variable for each xRQ? I know that > the scope of RequestSeqNum was discussed several months ago, and I agree > with the consensus that a receiver of an xRQ should not make any > assumptions about the scope. I just wanted to point out that a receiver > of XRS can only reliably use the requestSeqNum field if it uses a global > RequestSeqNum in outgoing xRQs. > > Paul Long > Smith Micro >

1 0

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

06 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, let's say 1, reflects the value of the decoded requestSeqNum of the unknown message or is a dummy value used in place of an undecodable requestSeqNum. IOW, to the receiver of the XRS message, the value of the requestSeqNum field may _or may not_ refer to a message it sent, and therefore the value cannot be trusted. I don't know of any way to fix this. Maybe we can just always assume that the value is valid--it was successfully decoded from the unknown message--and don't worry about the small chance of it being wrong. Apart from these problems, the passage quoted, above, from 7.17/H.225.0v2 implies that RequestSeqNum is unique across all outgoing RAS messages; otherwise, what is the point of providing it in XRS--how could the receiver of an XRS identify which message was not understood if it uses a separate requestSeqNum variable for each xRQ? I know that the scope of RequestSeqNum was discussed several months ago, and I agree with the consensus that a receiver of an xRQ should not make any assumptions about the scope. I just wanted to point out that a receiver of XRS can only reliably use the requestSeqNum field if it uses a global RequestSeqNum in outgoing xRQs. Paul Long Smith Micro

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 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

1 0

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

05 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