Hi All, H.323 requires all endpoints to transmit an IRR message in response to an IRQ message from a Gatekeeper (or some other entity), and also to send unsolicited IRR messages to the Gatekeeper's RAS address at specific intervals if requested by the Gatekeeper in the ACF or RCF messages. As I understand it, an endpoint must provide the details of all active calls in a single IRR response if the callReferenceValue field in the IRQ is set to 0. This is clearly not possible if the endpoint supports thousands (or even hundreds!) of simultaneous calls. Can anyone provide any guidance on what to do in such a situation? Also, in the case of unsolicited IRR messages, I can't find anything which states that an endpoint must provide details of all active calls in each unsolicited IRR message. Therefore, an endpoint can either send a separate IRR message for each call, or it combine details of a number of calls (but not necessarily all) into each IRR message. Is my interpretation correct? Thanks, Mohamed
Mohamed Mustafa wrote:
Hi All,
H.323 requires all endpoints to transmit an IRR message in response to an IRQ message from a Gatekeeper (or some other entity), and also to send unsolicited IRR messages to the Gatekeeper's RAS address at specific intervals if requested by the Gatekeeper in the ACF or RCF messages.
As I understand it, an endpoint must provide the details of all active calls in a single IRR response if the callReferenceValue field in the IRQ is set to 0. This is clearly not possible if the endpoint supports thousands (or even hundreds!) of simultaneous calls. Can anyone provide any guidance on what to do in such a situation?
H.323 v4 will contain a feature that will allow segmenting the response into a series of IRRs. This was approved at the February meeting. In the meantime, the standard does not specify how to handle this situation. I would be interested in guidance in this case as well.
Also, in the case of unsolicited IRR messages, I can't find anything which states that an endpoint must provide details of all active calls in each unsolicited IRR message. Therefore, an endpoint can either send a separate IRR message for each call, or it combine details of a number of calls (but not necessarily all) into each IRR message. Is my interpretation correct?
Since unsolicited IRRs are requested per-call via the irrFrequency, my interpretation is that an IRR should report only the information about the call for which it was requested. That said, I think it would be a useful enhancement to find a standard way to combine IRRs. Regards, Rich --
Thanks, Mohamed
-- -------------------------------------------------------------------- Richard K. Bowen Cisco Systems, Inc. rkbowen@cisco.com Research Triangle Park, NC --------------------------------------------------------------------
Mohamed, Neither H.323 or H.225.0 actually require that an EP ever provide perCallInfo. For example, notice the passive tense and lack of "shall" in this passage, the closest we have to normative text on the subject: 7.15.1/H.323v3: "callReferenceValue ... If zero, this message is interpreted as a request for an IRR for each call the terminal is active on." Reports from the field indicate that many (most?) EPs don't ever encode perCallInfo (Smith Micro does) and conversely most (all?) GKs don't ever look at the field anyway. IMO, this field is therefore useless. My recommendation to you is to simply ignore that field. Apparently IRR is _only_ used as a heartbeat indication. BTW, this is an example of why it is important for contributors and editors to avoid using the passive tense in Recommendations. They should also be conscious of the verbs they use, e.g., "shall" is the ITU's only normative verb, "is" is not. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Mohamed Mustafa [mailto:M.Mustafa@SDXPLC.COM] Sent: Wednesday, March 29, 2000 7:18 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Use of IRR by Gateways Hi All, H.323 requires all endpoints to transmit an IRR message in response to an IRQ message from a Gatekeeper (or some other entity), and also to send unsolicited IRR messages to the Gatekeeper's RAS address at specific intervals if requested by the Gatekeeper in the ACF or RCF messages. As I understand it, an endpoint must provide the details of all active calls in a single IRR response if the callReferenceValue field in the IRQ is set to 0. This is clearly not possible if the endpoint supports thousands (or even hundreds!) of simultaneous calls. Can anyone provide any guidance on what to do in such a situation? Also, in the case of unsolicited IRR messages, I can't find anything which states that an endpoint must provide details of all active calls in each unsolicited IRR message. Therefore, an endpoint can either send a separate IRR message for each call, or it combine details of a number of calls (but not necessarily all) into each IRR message. Is my interpretation correct? Thanks, Mohamed
Paul, I have to disagree. If I have a GK that sends an IRQ with a specific CRV, it means that it wants call details about the call. Why else would it send it? With a CRV=0, it wants all call details. This included the perCallInfo, as well, and is important for the alternate Gatekeeper procedure (among other things). So, why is the field OPTIONAL in the ASN.1? Because if the GK queries for a call that does not know about, it returns an IRR to the IRQ without any perCallInfo. Paul ----- Original Message ----- From: "Paul Long" <plong@SMITHMICRO.COM> To: <ITU-SG16@mailbag.cps.intel.com> Sent: Wednesday, March 29, 2000 10:48 AM Subject: Re: Use of IRR by Gateways
Mohamed,
Neither H.323 or H.225.0 actually require that an EP ever provide perCallInfo. For example, notice the passive tense and lack of "shall" in this passage, the closest we have to normative text on the subject:
7.15.1/H.323v3: "callReferenceValue - ... If zero, this message is interpreted as a request for an IRR for each call the terminal is active on."
Reports from the field indicate that many (most?) EPs don't ever encode perCallInfo (Smith Micro does) and conversely most (all?) GKs don't ever look at the field anyway. IMO, this field is therefore useless. My recommendation to you is to simply ignore that field. Apparently IRR is _only_ used as a heartbeat indication.
BTW, this is an example of why it is important for contributors and editors to avoid using the passive tense in Recommendations. They should also be conscious of the verbs they use, e.g., "shall" is the ITU's only normative verb, "is" is not.
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Mohamed Mustafa [mailto:M.Mustafa@SDXPLC.COM] Sent: Wednesday, March 29, 2000 7:18 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Use of IRR by Gateways
Hi All,
H.323 requires all endpoints to transmit an IRR message in response to an IRQ message from a Gatekeeper (or some other entity), and also to send unsolicited IRR messages to the Gatekeeper's RAS address at specific intervals if requested by the Gatekeeper in the ACF or RCF messages.
As I understand it, an endpoint must provide the details of all active calls in a single IRR response if the callReferenceValue field in the IRQ is set to 0. This is clearly not possible if the endpoint supports thousands (or even hundreds!) of simultaneous calls. Can anyone provide any guidance on what to do in such a situation?
Also, in the case of unsolicited IRR messages, I can't find anything which states that an endpoint must provide details of all active calls in each unsolicited IRR message. Therefore, an endpoint can either send a separate IRR message for each call, or it combine details of a number of calls (but not necessarily all) into each IRR message. Is my interpretation correct?
Thanks, Mohamed
Paul, I was explaining what the Recommendation actually requires and what vendors have implemented, not what "makes sense" or what the Recommendation should have said. While it may be a violation of the spirit of H.323 for an EP to never encode perCallInfo, it is clearly not a violation of the letter of H.323, and implementations have bore this out. If you think otherwise, please cite normative text. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Paul E. Jones [mailto:paulej@cisco.com] Sent: Wednesday, March 29, 2000 3:17 PM To: Mailing list for parties associated with ITU-T Study Group 16; Paul Long Subject: Re: Re: Use of IRR by Gateways Paul, I have to disagree. If I have a GK that sends an IRQ with a specific CRV, it means that it wants call details about the call. Why else would it send it? With a CRV=0, it wants all call details. This included the perCallInfo, as well, and is important for the alternate Gatekeeper procedure (among other things). So, why is the field OPTIONAL in the ASN.1? Because if the GK queries for a call that does not know about, it returns an IRR to the IRQ without any perCallInfo. Paul
Paul (Long), I think the issue is your recommendation to implementors: Paul Long wrote:
Reports from the field indicate that many (most?) EPs don't ever encode perCallInfo (Smith Micro does) and conversely most (all?) GKs don't ever look at the field anyway. IMO, this field is therefore useless. My recommendation to you is to simply ignore that field. Apparently IRR is _only_ used as a heartbeat indication.
The IRR may be used only as a heartbeat for terminals, but it is a useful audit tool for gateways. My recommendation to implementors would be to *include* the perCallInfo, and leave it up to the GK to decide whether or not it's important. When the standard is not clear, it's better for implementors to align with the intention of the standard, if they can determine that intention. I think the intention is pretty clear in this case. Rich -- Paul Long wrote:
Paul,
I was explaining what the Recommendation actually requires and what vendors have implemented, not what "makes sense" or what the Recommendation should have said. While it may be a violation of the spirit of H.323 for an EP to never encode perCallInfo, it is clearly not a violation of the letter of H.323, and implementations have bore this out. If you think otherwise, please cite normative text.
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Paul E. Jones [mailto:paulej@cisco.com] Sent: Wednesday, March 29, 2000 3:17 PM To: Mailing list for parties associated with ITU-T Study Group 16; Paul Long Subject: Re: Re: Use of IRR by Gateways
Paul,
I have to disagree. If I have a GK that sends an IRQ with a specific CRV, it means that it wants call details about the call. Why else would it send it?
With a CRV=0, it wants all call details. This included the perCallInfo, as well, and is important for the alternate Gatekeeper procedure (among other things).
So, why is the field OPTIONAL in the ASN.1? Because if the GK queries for a call that does not know about, it returns an IRR to the IRQ without any perCallInfo.
Paul
-- -------------------------------------------------------------------- Richard K. Bowen Cisco Systems, Inc. rkbowen@cisco.com Research Triangle Park, NC --------------------------------------------------------------------
Rich, You're right, I probably should not have made that recommendation. EPs definitely _should_ encode accurate perCallInfo. As I said, Smith Micro's EPs do. The problem is that a GK cannot read anything into the _lack_ of perCallInfo, e.g., does the lack indicate that that GW has no calls in progress or that it simply isn't _reporting_ its 10,000 calls to the GK? Given that, I can't imagine what use this field is to a GK, unless it knows out-of-band that all of its EPs encode perCallInfo to accurately reflect established calls. Maybe the fix is to add a field to RRQ in v4 so that an EP can indicate whether it is accurately encoding perCallInfo. Do you think it is currently possible for a GK to make use of perCallInfo given the semantic ambiguity of its absence? If so, how? Paul Long Smith Micro Software, Inc. -----Original Message----- From: Rich Bowen [mailto:rkbowen@CISCO.COM] Sent: Thursday, March 30, 2000 5:04 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Use of IRR by Gateways Paul (Long), I think the issue is your recommendation to implementors: Paul Long wrote:
Reports from the field indicate that many (most?) EPs don't ever encode perCallInfo (Smith Micro does) and conversely most (all?) GKs don't ever look at the field anyway. IMO, this field is therefore useless. My recommendation to you is to simply ignore that field. Apparently IRR is _only_ used as a heartbeat indication.
The IRR may be used only as a heartbeat for terminals, but it is a useful audit tool for gateways. My recommendation to implementors would be to *include* the perCallInfo, and leave it up to the GK to decide whether or not it's important. When the standard is not clear, it's better for implementors to align with the intention of the standard, if they can determine that intention. I think the intention is pretty clear in this case. Rich
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 ----- Original Message ----- From: "Paul Long" <plong@SMITHMICRO.COM> To: <ITU-SG16@mailbag.cps.intel.com> Sent: Wednesday, March 29, 2000 5:59 PM Subject: Re: Use of IRR by Gateways
Paul,
I was explaining what the Recommendation actually requires and what vendors have implemented, not what "makes sense" or what the Recommendation should have said. While it may be a violation of the spirit of H.323 for an EP to never encode perCallInfo, it is clearly not a violation of the letter of H.323, and implementations have bore this out. If you think otherwise, please cite normative text.
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Paul E. Jones [mailto:paulej@cisco.com] Sent: Wednesday, March 29, 2000 3:17 PM To: Mailing list for parties associated with ITU-T Study Group 16; Paul Long Subject: Re: Re: Use of IRR by Gateways
Paul,
I have to disagree. If I have a GK that sends an IRQ with a specific CRV, it means that it wants call details about the call. Why else would it send it?
With a CRV=0, it wants all call details. This included the perCallInfo, as well, and is important for the alternate Gatekeeper procedure (among other things).
So, why is the field OPTIONAL in the ASN.1? Because if the GK queries for a call that does not know about, it returns an IRR to the IRQ without any perCallInfo.
Paul
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@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
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@SMITHMICRO.COM> To: <ITU-SG16@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@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
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@ties.itu.ch] Sent: Sunday, April 02, 2000 4:37 PM To: ITU-SG16@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
Paul, Oh, maybe I misunderstood. Maybe you were just disagreeing with my proposal to add a field. You're right, we don't need to add a field to v4 so that an EP can indicate whether it will encode perCallInfo, thus continuing it being optional but removing the ambiguity of a missing entries. As of v4, we could change the text so that an EP shall always encode perCallInfo to accurate reflect the request, i.e., all calls or a specific call. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Paul E. Jones [mailto:paul.jones@TIES.ITU.CH] Sent: Sunday, April 02, 2000 4:37 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: 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
participants (5)
-
Mohamed Mustafa -
Paul E. Jones -
Paul E. Jones -
Paul Long -
Rich Bowen