Hi,
Presently, when a GK needs to resolve some aliasaddress, it sends LRQ to another GK which has a co-located Border Element (BE). This BE may need to generate an Access Request (according to H.225 Annex G), to another BE. It might be mandatory for the requesting BE to include callInformation (callId/ConfId) in this Access Request (depending on the address template it holds). But LRQ message does not have a callId field in it. How can the requesting BE then derive callInformation for Access Request message? Any help will be appreciated.
regards Manoj.
Manoj,
The short answer is that it does *not* work!
Annex G section 1.9 states:
"In many of the examples below, RAS LRQ/LCF messages are shown to be exchanged between a gatekeeper and a border element within the same administrative domain. This is for pure illustrative purpose, since the protocol for reference point B has not been determined (see 1.1)"
It was also accepted in Monterey that the examples do *not* work, for exactly the reasons you give. The figure added at that meeting (Figure 21) had the GK and the BE co-located so as not to show the LRQ being used for a purpose for which it is obviously not suited.
Regards,
Douglas
At 12:12 1999-08-16 -0700, Manoj Paul wrote:
Hi,
Presently, when a GK needs to resolve some aliasaddress, it sends LRQ to another GK which has a co-located Border Element (BE). This BE may need to generate an Access Request (according to H.225 Annex G), to another BE. It might be mandatory for the requesting BE to include callInformation (callId/ConfId) in this Access Request (depending on the address template it holds). But LRQ message does not have a callId field in it. How can the requesting BE then derive callInformation for Access Request message? Any help will be appreciated.
regards Manoj.
participants (2)
-
Douglas Clowes
-
Manoj Paul