Mob ad hoc group progress

Guram Paul-LPG019 lpg019 at EMAIL.MOT.COM
Sun Apr 2 15:51:49 EDT 2000


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