Megaco Meeting Summary

Tom-PT Taylor taylor at NORTELNETWORKS.COM
Thu Mar 30 19:37:17 EST 2000


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 at CISCO.COM]
Sent: Thursday, March 30, 2000 5:04 PM
To: ITU-SG16 at 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



More information about the sg16-avd mailing list