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 …
[View More]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
[View Less]
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 …
[View More]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
[View Less]
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. …
[View More]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
[View Less]
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 …
[View More]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
[View Less]
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
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
------------------------------------------------------------------
I have uploaded APC-1491.doc "GSM AUDIO PACKETIZATION IN H.323" into the
incoming directory of avc-site.
--
Henri Mäenpää, Nokia Wireless Business Communications
henri.maenpaa(a)nokia.com
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, …
[View More]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>>
[View Less]
Dear Mr. Okubo,
Please find attached contribution:
APC-1534 - Generic Mechanism for SS7 Transport in H323 based
networks (APC-1534.doc)
Regards, Christian Groves
Dear Q.12-14/16 experts,
Attached please find the current list of input documents for the next week
Rapporteur meeting in Monterey. This is very close to final unless I have
lost your requests.
Best regards,
Sakae OKUBO (Mr.)
***********************************************************
Waseda Research Center
Telecommunications Advancement Organization of Japan (TAO)
5th Floor, Nishi-Waseda Bldg.
1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo
169-0051 Japan
Tel: +81 3 5286 3830
Fax: +81 3 …
[View More]5287 7287
e-mail: okubo(a)giti.or.jp
***********************************************************
Documents for the Q.12-14/16 Monterey meeting (15-18 February 1999)
----------------------------------------------------------------------
APC- Source Title
----------------------------------------------------------------------
1486 SG11 Q.20/11 DSS2 protocol provision of adaptive timing
recovery used for transmitting clock
1487 SG9 Q.31/9 Progress report on Webcasting
1488 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG
16/Q 11, 12, 13 and 14 on MPEG-4 Systems on H.32X
1489 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG
16/Q11, 12, 13, and 14 on MPEG-4 Audio on H.32X
1490 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG
16/Q12 on Common Text Recommendations
1491 Nokia GSM in H.323
1492 AT&T H.323 Differentiated Services and Their Protocol
Architectures
1493 AT&T Viewgraphs presentation for "H.323 Differentiated
Services and Their Protocol Architectures"
1494 AT&T TIA/EIA IS-641 Enhanced Full-Rate Speech Codec
for H.323
1495 Editor (G Kajos)
Changes to H.341 Annexes
1496 Editors (D Gurle, G Kimchi)
Editorial changes to H.323 Annex E text
1497 TIPHON Requirements for a Protocol at Reference Point N:
Media Gateway Controller to Media Gateway
1498 VTEL H.323 QoS (Quality of Service) in the Policy
Based Network
1499 VTEL Slides Presentation for H.323 QoS (Quality of
Service) in the Policy Based Network
1500 Editor (B Hill) Gateway Control Protocol H.GCP
1501 Editor (J Ott) H.323 Annex F White Paper (for a final review)
1502 Teles OpenLogicalChannel structures for Annex F
1503 PTS Sweden H.323 Annex "Text", Text Conversation Capable SUD
1504 PTS Sweden Text conversation in H.323
1505 Editor (M Korpi)
Draft H.450.8 - Conference out of Consultation
Supplementary Service for H.323
1506 Siemens CallIdentifier and ConferenceIdentifier value
setting in H.450.2and H.450.3
1507 PictureTel Fixing inconsistency between Annex E and H.283
and Annex G
1508 Chairman WP2/13 Status report on AAL2 signalling and switching
1509 Q12 Rapporteur Draft H.321 Implementors Guide
1510 Madge Networks cryptoTokens in H.225.0 Annex G
1511 Madge Networks Master/slave determination for inter-zone calls
in H.323 environments where gatekeepers are
routing H.245 signalling
1512 Madge Networks Submissions for the H.323 implementer's guide
1513 Ascend Extension Proposals for Gateway MIB of H.341
revison 2
1514 Siemens Comparison of Tunneling and Interworking
1515 Siemens H.450.x - Tunneling of External protocols
1516 ATMF "H.323 Over ATM Media Transport" specification
1517 ATMF H.245 codepoint for transport of compressed RTP
over AAL5
1518 ATMF GIT for the transporting the portNumber
1519 Korea Telecom Dynamic Multicast Tree Building Procedure
1520 Nortel Networks Corrections to H.323 and H.245 regarding fast
start procedures
1521 Bosch, Ericsson, NTT DoCoMo
Request to support full MPEG-4 functionality in
H.324 terminals
1522 Mitel Additions to the H.323 Implementors Guide
1523 Mitel Comments on H.323 Annex F
1524 BT, Mitel H.245 Pre-Opened Channels
1525 Editor (G Fruendlich)
H.225.0 Annex G white draft from the editor
1526 Editor (G Fruendlich)
H.225.0 Annex G Clarifications and Improvements
1527 Lucent Caller ID Support
1528 Lucent Name Identification Features
1529 Lucent Media Device Control Protocol (MDCP)
1530 Lucent Support for Wireless Coders in H.323
1531 Lucent ISUP-Based Signaling for H.225 Control
1532 TAO Consideration of MPEG-2 stream packetization
1533 Editor (J Toga) Proposed text for H.323 Implementers Guide
1534 LM Ericsson Generic Mechanism for SS7 Transport in H323 based
networks
1535 Siemens Need for Services and Procedures for Charging,
Accounting and Advice of Charge in H.323
1536 NEC Layered coding and bitrate/bandwidth scalability
for speech/audio coding
1537 Nortel Networks Requirements Across the B, C, and D Interfaces of
a Decomposed Gateway
1538 Nortel Networks Requirements For Tunneling of ISUP and Other
Protocols
1539 for reuse
1540 LM Ericsson Adding pricing information to terminals in call
1541 LM Ericsson Use of GRQ for inter-gatekeeper discovery
1542 LM Ericsson Extending the pregranted ARQ
1543 LM Ericsson Indication of H.323 Annex E capabilities to
gatekeeper
1544 Editor (G Freundlich)
Draft H.225.0 V3
1545 Lucent Internal Connection Model for Generic Media
Gateways
1546 Ascend, ITXC, Lucent, OzEmail Interline, Siemens, VocalTec
Comments on H.225.0 Annex G
1547 Chairman, IETF Megaco Working Group
Media Gateway Control Protocol Architecture and
Requirements
1548 PictureTel Suggested changes to H.341(H.MediaMIB)
1549 PictureTel, VideoServer
Correction of problems related to MCV in H.230
and H.243
1550 Bellcore Media Gateway Control Protocol (MGCP)
1551 Nokia Comments to Annex G
1552 VocalTec Token OID for Crypto Tokens
----------------------------------------------------------------------
[View Less]
