Use of IRR by Gateways

Paul E. Jones paul.jones at ties.itu.ch
Sun Apr 2 17:36:38 EDT 2000


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

----- Original Message -----
From: "Paul Long" <plong at SMITHMICRO.COM>
To: <ITU-SG16 at mailbag.cps.intel.com>
Sent: Sunday, April 02, 2000 11:56 AM
Subject: Re: Use of IRR by Gateways


> Paul,
>
> Well, that's at least the strongest _clue_ yet. :-) I must have missed it.
> However, it still does not _require_ that an EP encode a perCallInfo entry
> for each active call. Since very few vendors encode perCallInfo, that must
> be the consensus, too.
>
> It's too late now to _require_ that perCallInfo represent all active calls
> without breaking existing compliant implementations; however, what do you
> think about my suggestion to add a field to RRQ in v4 so that an EP can
> indicate whether it is accurately encoding perCallInfo? I think that would
> solve the problem that a GK currently has of not knowing what the absence
of
> perCallInfo info means. The field might then actually be useful. :-)
>
>          willSupplyPerCallInfo         BOOLEAN
>
> Paul Long
> Smith Micro Software, Inc.
>
> -----Original Message-----
> From: Paul E. Jones [mailto:paul.jones at ties.itu.ch]
> Sent: Saturday, April 01, 2000 11:45 PM
> To: Mailing list for parties associated with ITU-T Study Group 16; Paul
> Long; Rich K. Bowen
> Subject: Re: Re: Use of IRR by Gateways
>
>
> Paul,
>
> Section 11.2 of H.323 states:
>
> ``All terminals shall support the Information Request/Information Request
> Response (IRQ/IRR) message of Recommendation H.225.0. The Information
> Request Response message contains the TSAP Identifier of all channels
> currently active on the call, including T.120 and H.245 control, as well
as
> audio and video. This information can be used by third party maintenance
> devices to monitor H.323 conferences to verify system operation.''
>
> The second sentence is the "clue", I suppose.  It was definitely intended
> that perCallInfo shall be included in the IRR.  However, I agree that this
> could be clearer.  In addition, the spec should be clearer about what to
do
> when an IRQ is received for a call that does not exist.  However, I
believe
> the answer is to respond without perCallInfo.
>
> Paul
>



More information about the sg16-avd mailing list