February 1999 - sg16-avd - lists.packetizer.com

documents uploaded
by Glen Freundlich 08 Feb '99

08 Feb '99

Dear Mr. Okubo, I have uploaded APCs 1526, 1527, 1528, 1530, 1531, 1545, and 1546 into the Incoming directory of the avc ftp site. Regards, Glen Freundlich -- Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA

1 0

Text conversation documents uploaded
by Gunnar Hellstrom 08 Feb '99

08 Feb '99

The documents APC1503a.zip and APC1504.zip, introducing text conversation in the H.323 environment have been uploaded to the incoming directory of the FTP-site for the upcoming q13 meeting. Best regards Gunnar Hellström Representing the National Post and Telecom Agency, Sweden. ------------------------------------------------ Gunnar Hellström Omnitor AB Alsnögatan 7, 4tr S-116 41 Stockholm SWEDEN Tel +46 751 100 501 Fax +46 8 556 002 06 E-mail: gunnar.hellstrom(a)omnitor.se WWW: www.omnitor.se ------------------------------------------------

1 0

APC-1550 uploaded
by Hong Liu 08 Feb '99

08 Feb '99

Hi, all, I have uploaded APC-1550.zip to the incoming directory. --Hong

1 0

Uploads
by Chris Purvis 08 Feb '99

08 Feb '99

APC-1511 uploaded as APC-1511b.doc (connectivity problems caused abortion of APC-1511.doc & APC-1511a.doc - sorry!) APC-1512 uploaded as APC-1512.doc -- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. ENGLAND Phone: +44 1753 661 359 email: cpurvis(a)madge.com

1 0

Re: Implementers Guide- pls review
by Chris Purvis 08 Feb '99

08 Feb '99

Jim (and all interested parties), > My comments below... (I'm cc' this sg16 list so that others > will understand the 'tweaks' from what had been posted > previously) Fine. >> 1. Your reworking of the UDP Port usage question appears to be >> self-inconsistent and talks round the fundamental problem >> rather than fixing >> it (it both sanctions and forbids the use of port 1718 for >> unicast LRQ). >> The essential problem is that the usage of port 1718 is NOT >> directly related to the discovery issue. I believe my solution >> is clearer as well as requiring less in the way of changes in >> H.225.0. > I thought the fundamental problem was that a receiving GK had > no reliable way to detect whether a message had arrived via > multicast or unicast. Mythinking was that the > multicastaddress:1718 VS the localaddress:1718, would > be enough of a differentiator. In any case port 1719 was > always relegated to unicast. The point that came up at interop was that many IP stacks do not communicate to the app above them the difference between receiving on multicastaddress:1718 and localaddress:1718 - they map to sockets entirely based on port number. Hence to gatekeepers running on these IP stacks, messages received on localaddress:1718 will look like multicast messages. > I see your point, but I believe we cannot arbitrarily make > unicast on port 1718 'illegal.' It is tighter ( and > therefor not backward compatible) with current v1 and v2 > specs. I also do not know the impact would be on existing > products. I guess I would be more comfortable with a > (strong) _should_ with respect to multi-cast only on port > 1718. This by the way is why there is _should_ statement > in the new existing text that I sent out. > I will make these changes and see if they are acceptable by others. How about a "shall" on transmitting on port 1718 for multicast, 1719 for unicast - but also require that gatekeepers will listen on both for unicast packets. The point is that with many IP stacks the gatekeeper can do no better than guess, but we might as well require future endpoints to give gatekeepers the best possible chance to guess right! I would also suggest that continuing to call port 1718 the "UDP Discovery Port" and then giving example of LRQs (which are NOT discovery messages as I understand the term) being sent there will be rather confusing to someone reading the standard for the first time! How about adding some text to my proposed solution, leaving it something like this (I quote the whole lot because not everyone's seen what I sent you before...): ---start soln--- Bring the standard into line with the most common usage by replacing the table from H.225.0 section 19.1.1.1 with the following: UDP Address for multicast communication with gatekeepers: 224.0.1.41 UDP port for multicast communication with gatekeepers: 1718 UDP port for unicast RAS communication where no other agreement exists: 1719 Note that "other agreement" may include registration of an endpoint with a gatekeeper. A gatekeeper should treat GRQ or LRQ messages unicast to port 1718 as if they had been received by multicast. ---end soln--- This asks gatekeeper to behave in the "best" way that is possible with many IP stacks. [Multiple aliases] > I am in favor of resloving this during the meeting. I take it from this that you'd like me to present this as part of my submission. Regards, Chris -- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. ENGLAND Phone: +44 1753 661 359 email: cpurvis(a)madge.com

1 0

Re: Implementers Guide- pls review
by Jim Toga 08 Feb '99

08 Feb '99

Frank Thanks for the text. I will use it instead of my poorer attempt.... Regards, jimt. At 11:40 AM 2/8/99 +0100, Derks, Frank wrote: >Hi Jim, > >I just had a quick look at the text that you included for the description of >TPKT. I would like to suggest the following text as a replacement: > >"A TPKT is a packet format as defined in IETF RFC1006. It is used to delimit >individual messages (PDUs) within the TCP stream, which itself provides a >continuous stream of octets without explicit boundaries. A TPKT consists of >a one octet version number field, followed by a one octet reserved field, >followed by a two octet length field, followed by the actual data. The >version number field shall contain the value "3", the reserved field shall >contain the value "0". The length field shall contain the length of the >entire packet including the version number, the reserved and the length >fields as a 16-bit big-endian word." > >Frank > > >----------------------------------------------------- >Frank Derks |Tel +31 35 6893238 | >Advanced Development |Fax +31 35 6891030 | >Philip Business Communications |P.O. Box 32 | > |1200 JD Hilversum | > |The Netherlands | >----------------------------------------------------| >E-mail: mailto:f.derks@pbc.be.philips.com | >WWW: http://www.business-comms.be.philips.com | >----------------------------------------------------- > > <<Frank Derks (E-mail).vcf>> > > >Attachment Converted: "c:\users\jtoga\mail\J-attach\Frank Derks (E-mail)3.vcf" > +1-503-264-8816(voice) Intel - Hillsboro, OR mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41

1 0

Re: Implementers Guide- pls review
by Jim Toga 08 Feb '99

08 Feb '99

Chris, My comments below... (I'm cc' this sg16 list so that others will understand the 'tweaks' from what had been posted previously) Best Regards, jimt. At 12:18 PM 2/8/99 -0000, you wrote: >Jim, > >I've drawn up a list of proposals for the implementer's guide, which I was >planning to put in as my own contribution. It can remain as a separate >contribution for the meeting, or some or all of it can be subsumed into >yours, as you see fit. I've attached it to this mail. Specific comments: > >1. Your reworking of the UDP Port usage question appears to be >self-inconsistent and talks round the fundamental problem rather than fixing >it (it both sanctions and forbids the use of port 1718 for unicast LRQ). >The essential problem is that the usage of port 1718 is NOT directly related >to the discovery issue. I believe my solution is clearer as well as >requiring less in the way of changes in H.225.0. I thought the fundamental problem was that a receiving GK had no reliable way to detect whether a message had arrived via multicast or unicast. My thinking was that the multicastaddress:1718 VS the localaddress:1718, would be enough of a differentiator. In any case port 1719 was always relegated to unicast. I see your point, but I believe we cannot arbitrarily make unicast on port 1718 'illegal.' It is tighter ( and therefor not backward compatible) with current v1 and v2 specs. I also do not know the the impact would be on existing products. I guess I would be more comfortable with a (strong) _should_ with respect to multi-cast only on port 1718. This by the way is why there is _should_ statement in the new existing text that I sent out. I will make these changes and see if they are acceptable by others. > >2. I've drawn something up on the multiple aliases question. I think >something ought to be agreed and put into the guide asap - and I think this >will only happen by being presented to a meeting and argued over. I'm happy >for this, as something a bit controversial, to be kept as my separate >contribution, but I'd like to think there was some chance of getting it into >the guide at this cut in some form or other. I am in favor of resloving this during the meeting. >I'll put in my contribution, containing whatever you leave me, first thing >in MY morning tomorrow (ie the middle of tonight your time). > >Regards, >Chris >-- >Dr Chris Purvis - Senior Development Engineer, WAVE CC Software >Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. ENGLAND >Phone: +44 1753 661 359 email: cpurvis(a)madge.com > +1-503-264-8816(voice) Intel - Hillsboro, OR mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41

1 0

Re: TPKT in H.225.0
by Drage, Keith 08 Feb '99

08 Feb '99

ITU-T is not "reluctant" to create the references to external organisations. It has made a set of rules for such references, and has then failed so far to get them to work. The rules are contained in Recommendation A.5 published in 1998. ITU-T SG9 recently tried to use these rules, and fell foul of the very precise nature of these rules. The recent ITU-T SG chairmen's meeting discussed this, and I believe identified that the rules were not meant to be this restrictive, and not meant to be applied on a per recommendation / reference basis, i.e. once IETF had been identified as a suitable organisation fulfilling all the rules, it did not repeatedly need to prove its suitability. I understand SG9 will be attempting more Recommendation references to external organisations in the near future, and in ITU-T SG11, we will also be attempting to do this. Keith Drage Siemens Communication Systems Limited Nottingham UK > -----Original Message----- > From: Jim Toga [SMTP:jim.toga@INTEL.COM] > Sent: Thursday, February 04, 1999 4:04 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: TPKT in H.225.0 > > I am working on some (initial) text for the Implementers Guide. I > will > welcome additions/modifications at the Rapportours meeting...... > > > jimt. > > At 02:03 PM 2/4/99 +0100, Derks, Frank wrote: > >Hi Tom, > > > >I couldn't find it either and I suspect that it couldn't be in > because the > >ITU is very reluctant to reference any non-ITU material. Furthermore, > >RFC1006 encompasses a lot more than just the bit(s) that are used for > >H.225.0, so even referring to this RFC does not clarify it all. I > think some > >work should be spent on this. > > > >Frank > > > >-----Original Message----- > >From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] > >Sent: 02 February 1999 22:12 > >To: ITU-SG16(a)MAILBAG.INTEL.COM > >Subject: Re: TPKT in H.225.0 > > > > > >I'd swear the reference to RFC1006 used to be in H.225.0 Appendix D, > but I > >can't find it there now. > > > >> -----Original Message----- > >> From: Derks, Frank [SMTP:F.Derks@PBC.BE.PHILIPS.COM] > >> Sent: Tuesday, February 02, 1999 4:05 AM > >> To: ITU-SG16(a)MAILBAG.INTEL.COM > >> Subject: Re: TPKT in H.225.0 > >> > >> Hi Paul, > >> > >> I received two responses to my question, one from you and one from > Tom > >> Taylor. The fact that there are at least two people that know about > it > >> (and > >> several dozens more that have actually implemented the protocol > stacks), > >> makes it hard to believe that this is an "oversight" in the > >> recommendation. > >> In fact, not knowing about this makes it impossible to implement an > >> interoperable protocol stack! Shouldn't action be taken to get this > into > >> the > >> recommendation ASAP (e.g. through the Implementor's Guide)? > >> > >> Regards, > >> > >> Frank > >> > >> -----Original Message----- > >> From: Paul Long [mailto:Plong@SMITHMICRO.COM] > >> Sent: 01 February 1999 18:50 > >> To: ITU-SG16(a)MAILBAG.INTEL.COM > >> Subject: Re: TPKT in H.225.0 > >> > >> > >> TPKT is defined in RFC 1006. Not identifying TPKT was an oversight > that > >> has > >> never been fixed in the Recommendation. > >> > >> Paul Long > >> Smith Micro Software, Inc. > > > +1-503-264-8816(voice) Intel - Hillsboro, OR > mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int > PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41

1 0

Monterey contributions uploaded
by Klaghofer Karl ICN IB NL IP 7 08 Feb '99

08 Feb '99

The following three contributions have been uploaded to the Incoming directory of the standard.pictel.com ftp site: APC-1505.zip APC-1506.zip APC-1535.zip Regards, Karl ------------------------------------------------ Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL IP7 Hofmannstr. 51, D-81359 Munich, Germany Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 e-mail: karl.klaghofer(a)vs.siemens.de

1 0

Uploaded APC-1514 and APC-1515
by Callaghan, Robert 08 Feb '99

08 Feb '99

Corrected version of APC-1514 and APC-1515 have been uploaded as APC-1514b.zip and APC-1515b.zip. APC-1514a.zip failed during upload and should be deleted. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Information & Communication Networks Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------

1 0