Paul,
Section 11.2 does not in any way require that an EP encode a perCallInfo entry for each active call. Read it again. It only talks about the _contents_ of a perCallInfo entry. So there are three problems with this passage. One, it has nothing to do with the topic at hand; two, it is editorial, not normative (see 5/H.323v3); and three, it only refers to _terminals_ and not _endpoints_, so even if it were normative it would not apply to gateways, which are not terminals. Hey, I don't make the rules, I just enforce 'em. :-)
We have a problem that clarification text will not fix. EPs are not now required to encode perCallInfo. Indeed, many vendors have chosen to not encode anything for this field. Therefore, GKs have no unambiguous way to interpret missing entries. Is there no call, or is the EP merely not reporting the call? I proposed one solution.
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Paul E. Jones [mailto:paul.jones@ties.itu.ch] Sent: Sunday, April 02, 2000 4:37 PM To: ITU-SG16@mailbag.cps.intel.com; Paul Long Subject: Re: Re: Use of IRR by Gateways
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