Paul,
Supplying this information is far too important to leave as an option for the endpoint. Section 11.2 is meant to convey those semantics, but if it is not clear, perhaps it should be clarified-- in any case, it is not optional.
I mentioned before that this information is vital for alternate GKs and it is also important for keeping track of active calls by a GK. Suppose, for example, that an endpoint starts 1000 calls and sends ARQs to the GK. Now, support the endpoint crashes and then reregisters with the GK when it comes back up. The GK may just think that it's a full registration for the purposes of changing aliases or some other data-- no big deal. However, the truth is that those 1000 calls are gone and the GK needs to know that. The IRQ/IRR exchange will keep these two synchronized.
Paul
----- Original Message ----- From: "Paul Long" plong@SMITHMICRO.COM To: ITU-SG16@mailbag.cps.intel.com Sent: Sunday, April 02, 2000 11:56 AM Subject: Re: Use of IRR by Gateways
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 BOOLEANPaul 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