David, Herman:

Unfortunately, we received your liaison near the end of the day Thursday,

which is the last day of the meeting. Although the document was quickly

repproduced, it was determined that given the late hour (after 6 PM) that it was

too complex to respond to completely.

It was decided to send an official liaison that had been previously prepared, with a few minor modifications, to SG8. You should have received this already. It discusses some but not all of your concerns.

I also announced my intention to send one or more informal messages to you concerning the questions raised. You can also expect a formal liaison to be generated by the SG16 meeting in September.

Keep in mind that I wrote this at 3 AM, so I have probably blundered at least once.

Dale Skran

Rapporteur, Q13 SG16 WP2

For those who attended the Cannes meeting, these comments refer to TD-29.

<bold>Sec 2: Changes needed in Annex D

</bold>

a)It is not 100% clear exactly what changes are referred to in para 1, but Vineet and I will undertake to look over Annex D for anything that needs to be changed.

b)With regard to the two data rate management questions, it is not completely clear why Mgt method 2 is not allowed with TCP. Wouldn't it work in a well managed, high QoS network?

c)The liaison from Q13 you have received covers TCP vs UDP in considerable depth. I would like to add some thoughts Mr. Ott and I had since then. We are under the impression that Q3 believes that by using UDP without a back-off mechanism, delay-intolerant fax relay implementations that do not locally generate TCF can be used, while with TCP they cannot be used. Our thought is that if the network is bad enough that the delay caused by the back-off exists, it is probbly a sufficiently bad network that fax relay will not work in any case.

d)I believe the sufficient time exists to standardize or adopt a UDP back-off mechanism before decision, so this option should be given serious consideration.

<bold>Sec. 3.1 - RAS

</bold>

a)RAS is the easiest part of H.323 to implement, and has the simplist definition (with the other parts being H.255.0 call signaling, H.245, and RTP/RTCP media processing.) Mandatory elements are clearly identified and are not so numerious. Once you've taken the leap to using ASN.1, the value of RAS easily justifies implementing it.

b)The major impact of not supporting RAS is as follows:

i)The terminal must use the well known port or support an alternate protocol for getting a dynamic address.

ii)The terminal cannot make use of the H.323 E.164 to IP address translation network element, the Gatekeeper. As large H.323 networks are established, this will require establishing a seperate address server for the fax terminals using some other means to achieve the same feature operation.

iii)Since network operators and MIS managers use the Gatekeeper to manage bandwidth, they may (and probably will) ban non-RAS compliant terminals and devices. This could limit the market for non-RAS devices.

iv)It sharply limits the meaning of H.323 interoperability for the Annex B terminal.

v)RAS is the basis for call accounting in H.323 systems. Customers are not likely to purchase equipment that cannot be billed for.

There are probably more agruments, but the direction is clear. Keep in mind that the *use* of RAS is always optional, i.e. the user can always enter a full IP address, or maintain a local directory of IP addresses. However, as noted in (v) this prevents call accounting, and thus will not meet the needs of many customers.

<bold>Sec. 3.2 Ports & Firewalls:

</bold>

I invite Mr. Toga at intel to address the subject of H.323 and firewalls in general. Intel has a paper on this topic; also in the H.323 V2 implementors guide we have just added a section dealing with NAT and with some other firewall related topics. As soon as Mr. Toga incorporates this material, I invite him to send you both a copy.

With regard to the use of 1 port for both call setup and T.38 messages, the main issues are:

a)Distinguishing between the H.225.0 messages and the T.38 messages is difficult since there is no common system of headers

b)If a header is added, this is overhead

c)For systems that may wish to use a TCP link for call setup, and UDP for T.38, having a single port seems problematic [maybe I'm confused on this one]

d)Switching from fax to voice is more complex as a new port needs to be opened for voice; mixing voice and call signaling does not seem like a good idea.

There are more agruments that we have presented in past liaisons, perhaps Mr. Kumar could supply them.

<bold>Section 3.3 - Facility message

</bold>

This is mandatory. Suggest adding language pointing to table in H.225.0 of required messages - Table 4/H.225.0 is the reference.

<bold>Sec. 3.4 - Flow Control when using UDP

</bold>

The formal liaison comments on maxBitRate. This represents the maximum (peak) fax bit rate that the unit can absorb, and should not be exceeded over a period of time. It is interesting that you are concerned about UDP flow control as this is a major issue with UDP. TCP can be relied on to throttle a high-speed internet fax device to match a 4.8 kbps G3 device, but with UDP it is unclear how this will happen.

maxBitRate can be changed by using H.245 negotation. It is mainly a signal to the sender to not exceed this rate. In the example above, a complient 1 Mbps terminal would note that it is sending to a 4800 bps terminal, and only send 4800 bps. Of course, there are no "standards police" to enforce this. Compliant terminals should not need a UDP throttle.

<bold>Sec. 3.5 - ASN.1

</bold>

We'll look at it by September.

<bold>

Sec 4 - Editorial

</bold>

Seems Ok; Kumar will look at in detail.

<bold>Sec 5 Annex D change</bold>s

Covered in formal liaison.

<bold>Sec 6 - other issues

</bold>

1)PIP/PIN and voice switch - I need to think about this more

2)The way fast connect works, you offer the modes you can receive(in this case, TCP and UDP). The receiver of the call picks a mode and this is the mode used.

3)Order indicates preference (it's late, but I think this is true), so a well-behaved terminal should use the cap in the first OLC, thus allowing the transmitter to pick the mode. However, I don't believe this is binding, so in effect the receive picks the mode. [Toby, others, keep me honest here]

4)H.323 call termination - usually calls are terminated with RELEASE COMPLETE, which includes either the Q.931 CAUSE value or <bold>the releaseCompleteReason</bold>.

5)Optional features can be included in OLCs in the Setup message.

6)Issues related to large GWs and using seperate ports - we don't see any.

7)The formal liaison discusses the issue of voice vs fax BW. Plese comment on it, and then we can proceed.