Paul,
Oh, maybe I misunderstood. Maybe you were just disagreeing with my proposal to add a field. You're right, we don't need to add a field to v4 so that an EP can indicate whether it will encode perCallInfo, thus continuing it being optional but removing the ambiguity of a missing entries. As of v4, we could change the text so that an EP shall always encode perCallInfo to accurate reflect the request, i.e., all calls or a specific call.
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.INTEL.COM Subject: 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