Ouch! Another example of something being added to the standard without anyone noticing something it's going to break...
The first thing to say is that a gatekeeper would be ill-advised to use both pregrantedARQ and the direct call model. At least in the routed model the gatekeeper can kill the call (with endSessions and ReleaseCompletes!) - and have the effect of DRQ. IRQ & BRQ, though... My suggestion would be to clarify (!) the position in such a way that IF a call has been made using pregrantedARQ THEN the CRV field shall be ignored in these messages. I believe this picks up all cases because pregrantedARQ arrived after CallID, so CallID is always available for tallying things up... As for what the CRV field should be set to, is it fair to leave that as an exercise for the reader?
Regards, Chris
Sasha Ruditsky wrote:
Hi
My understanding of preGrantedARQ call leg is that unsolicited IRR is the ONLY RAS message that may be sent on such call leg.
To be honest this understanding based more on memory and intuition than on something written in the standard. The only written thing that I was able to find and that somehow "clarifies" the issue is the following paragraph from H.225.0 (explanation of irrFrequencyInCall subfield of preGrantedARQ field in RCF:
irrFrequencyInCall - This indicates the frequency, in seconds, of IRR messages sent to the gatekeeper when the endpoint is in one or more calls. If it is not present, the gatekeeper does not want unsolicited IRR messages. When the endpoint is sending these IRR messages, the call reference value shall be made unique for the terminal, as it would have been generated in an Admission Request. However, this is not a "normal" CRV, and cannot be reused for further communication (DRQ, IRQ or BRQ). The call identifier shall be the same as used in the call signaling channel messages for the related call.
So, does this mean (DRQ, IRQ or BRQ) cannot be sent or they should be sent with "normal" CRV?
Sasha
-----Original Message----- From: Horvath Ernst [mailto:ernst.horvath@SIEMENS.AT] Sent: Tuesday, July 17, 2001 5:07 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: AW: CRV Blues
Manoj,
the call-ID is the real means to tie together all messages related to the same call.
Regarding your specific questions:
For a GK routed call, the GK "knows" about the call even in the case of pre-granted admission, and can of course send BRQ/IRQ. The CRV used for these RAS messages can be the same as in SETUP.
For a directly routed call with pre-granted admission, the GK is not immediately aware of the call (periodic IRQs for all calls is one way to obtain this knowledge eventually). However, the endpoint can always send RAS messages, e.g. BRQ or IRR. For these RAS messages it will use an arbitrary locally unique CRV and, more important, the same globally unique call-ID.
Ernst Horvath Siemens AG
-----Ursprüngliche Nachricht----- Von: Paul, Manoj [mailto:mpaul@TRILLIUM.COM] Gesendet am: Dienstag, 17. Juli 2001 01:39 An: ITU-SG16@mailbag.cps.INTEL.COM Betreff: CRV Blues
Hi All,
I have a couple of question related to the use of RAS CRV. Consider an endpoint EP1 has pre-granted admission and sends SETUP with 225CRV1 to GK. If GK subsequently sends a BRQ/IRQ for this call, what RASCRV is uses in these messages. Would RASCRV be same as 225CRV1 ? Secondly, is it expected that GK can potentially send BRQ/IRQ for a call for which it gave pre-granted admission to an endpoint? Any pointers are appreciated.
regards Manoj Paul.
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.comFor help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.comFor help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
-- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com