Use of IRR by Gateways

[Paul Long]

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 at ties.itu.ch]
Sent: Sunday, April 02, 2000 4:37 PM
To: ITU-SG16 at 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