Paul,
Well, that's at least the strongest _clue_ yet. :-) I must have missed it. However, it still does not _require_ that an EP encode a perCallInfo entry for each active call. Since very few vendors encode perCallInfo, that must be the consensus, too.
It's too late now to _require_ that perCallInfo represent all active calls without breaking existing compliant implementations; however, what do you think about my suggestion to add a field to RRQ in v4 so that an EP can indicate whether it is accurately encoding perCallInfo? I think that would solve the problem that a GK currently has of not knowing what the absence of perCallInfo info means. The field might then actually be useful. :-)
willSupplyPerCallInfo BOOLEAN
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Paul E. Jones [mailto:paul.jones@ties.itu.ch] Sent: Saturday, April 01, 2000 11:45 PM To: Mailing list for parties associated with ITU-T Study Group 16; Paul Long; Rich K. Bowen Subject: Re: Re: Use of IRR by Gateways
Paul,
Section 11.2 of H.323 states:
``All terminals shall support the Information Request/Information Request Response (IRQ/IRR) message of Recommendation H.225.0. The Information Request Response message contains the TSAP Identifier of all channels currently active on the call, including T.120 and H.245 control, as well as audio and video. This information can be used by third party maintenance devices to monitor H.323 conferences to verify system operation.''
The second sentence is the "clue", I suppose. It was definitely intended that perCallInfo shall be included in the IRR. However, I agree that this could be clearer. In addition, the spec should be clearer about what to do when an IRQ is received for a call that does not exist. However, I believe the answer is to respond without perCallInfo.
Paul