Rich,
You're right, I probably should not have made that recommendation. EPs definitely _should_ encode accurate perCallInfo. As I said, Smith Micro's EPs do. The problem is that a GK cannot read anything into the _lack_ of perCallInfo, e.g., does the lack indicate that that GW has no calls in progress or that it simply isn't _reporting_ its 10,000 calls to the GK? Given that, I can't imagine what use this field is to a GK, unless it knows out-of-band that all of its EPs encode perCallInfo to accurately reflect established calls. Maybe the fix is to add a field to RRQ in v4 so that an EP can indicate whether it is accurately encoding perCallInfo.
Do you think it is currently possible for a GK to make use of perCallInfo given the semantic ambiguity of its absence? If so, how?
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Rich Bowen [mailto:rkbowen@CISCO.COM] Sent: Thursday, March 30, 2000 5:04 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Use of IRR by Gateways
Paul (Long),
I think the issue is your recommendation to implementors:
Paul Long wrote:
Reports from the field indicate that many (most?) EPs don't ever
encode
perCallInfo (Smith Micro does) and conversely most (all?) GKs don't
ever
look at the field anyway. IMO, this field is therefore useless. My recommendation to you is to simply ignore that field. Apparently IRR
is
_only_ used as a heartbeat indication.
The IRR may be used only as a heartbeat for terminals, but it is a useful audit tool for gateways. My recommendation to implementors would be to *include* the perCallInfo, and leave it up to the GK to decide whether or not it's important. When the standard is not clear, it's better for implementors to align with the intention of the standard, if they can determine that intention. I think the intention is pretty clear in this case.
Rich