TGREP is here: http://tools.ietf.org/html/draft-ietf-iptel-tgrep-09 parts of this sound very similar to what you want to do...maybe...but I'm note sure about the requirements you have in mind.
RAI (Resource Availability Indicator) is basically the interaction between a H323 gateway and its gatekeeper. It uses RAS to keep tract of port resources in the GW, so the gatekeeper knows at all times the GW's availability to receive calls or even the overall GW's availability . There are a number of timers involved as well as configurable port resource thresholds. Below are the relevant sections from H225 RAS that explains it: 7.18 Gateway Resource Availability messages The Resource Availability Indication (RAI) is a notification from a gateway to a gatekeeper of its current call capacity for each H-series protocol and data rate for that protocol. The gatekeeper responds with a Resource Availability Confirmation (RAC) upon receiving a RAI to acknowledge its reception. 7.18.1 ResourcesAvailableIndicate (RAI) The RAI message includes the following: requestSeqNum - This is a monotonically increasing number unique to the sender. It shall be returned by the receiver in any response associated with this specific message. protocolIdentifier - Identifies the vintage of the sending endpoint. nonStandardData - Carries information not defined in this Recommendation (for example, proprietary data). endpointIdentifier - A gatekeeper assigned endpoint identity string. protocols - Indicates the current data rates for each protocol which can be supported given the current state of the device. almostOutOfResources - When set to TRUE, the device is nearing or at capacity. Any action based on this field is at the manufacturer's discretion. If the device is not near or at capacity this field should be set to FALSE. tokens - This is some data which may be required to allow the operation. The data shall be inserted into the message if available. cryptoTokens - Encrypted tokens. integrityCheckValue - Provides improved message integrity/message authentication of the RAS messages. The cryptographically based integrity check value is computed by the sender applying a negotiated integrity algorithm and the secret key upon the entire message. Prior to integrityCheckValue computation, this field shall be ignored and shall be empty. After computation, the sender puts the computed integrity check value in the integrityCheckValue field and transmits the message. 7.18.2 ResourcesAvailableConfirm (RAC) The RAC message includes the following: requestSeqNum - This shall be the same value that was passed in the RAI. protocolIdentifier - Identifies the vintage of the accepting gatekeeper. nonStandardData - Carries information not defined in this Recommendation (for example, proprietary data). tokens - This is some data which may be required to allow the operation. The data shall be inserted into the message if available. cryptoTokens - Encrypted tokens. integrityCheckValue - Provides improved message integrity/message authentication of the RAS messages. The cryptographically based integrity check value is computed by the sender applying a negotiated integrity algorithm and the secret key upon the entire message. Prior to integrityCheckValue computation this field shall be ignored and shall be empty. After computation, the sender puts the computed integrity check value in the integrityCheckValue field and transmits the message. We have been looking for a SIP solution to this. We have a large set of gateways out there that could really use this specially when migrating from H323 to SIP. -fernando -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 12, 2008 1:14 PM To: Fernando Lombardo Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Fallback between gateways? From: "Fernando Lombardo" <[EMAIL PROTECTED]> Isn't it this something that part of TGREP attempts to solve? Are you trying to specify something similar to the RAI feature in H323? I'm not familiar with either of those. Can you explain further? Dale _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
