...
It is possible to use multiple Diameter Stack agents in a workflow if that is required in the business logic. However, for the best possible performance, it is recommended to use one Diameter Stack agent per workflow.
...
A Diameter Stack workflow
Note | |
---|---|
title | Note!
|
Anchor | ||||
---|---|---|---|---|
|
...
You view the UDR types that are created by default in the Diameter agents (based on RFC 6733), in the UDR the UDR Internal Format Browser, in the Diameter folderthe Diameter folder. To open the browser, open an APL an APL Editor. In the editing area right-click and select UDR select UDR Assistance.
...
The UDR Internal Format Browser
Each Command or AVP that is defined in the Diameter application profile configuration will result in a UDR type after it has been saved. Note that Note that the base commands and AVPs in RFC 6733 are predefined and included automatically.
Note |
---|
Note!The BaseUDR and BaseCommand UDR types are internal and shall not be used in APL code. |
...
The following fields are included in the RequestCycleUDR:
Field | Description | |
---|---|---|
| This field is populated with an "answer message UDR", before routed back by the workflow to the Diameter Stack agent. For the Diameter Request agent it will work the reversed way: after the answer field has been populated by the agent, the RequestCycleUDR is routed to the workflow.
|
| ||
| A timestamp indicating when the client receives the answer in nanoseconds. | |
| A timestamp indicating when the server sends the answer in nanoseconds. | |
| This is an internal working field that can be used in the workflow configuration to keep track of and use internal workflow information related to the request, when processing the answer. An example for a proxy workflow including TCP/IP and Diameter agents: When sending the RequestCycleUDR to the Diameter Request agent, the input TCPIPUDR is saved in the Context field. When the response is received from the Diameter agent, the TCPIPUDR can be read from the Context field and this TCPIPUDR can be used to send back the response to the TCP/IP agent. | |
| You can populate this field with a list a list of peers, identified by their hostnames. When Round Robin is selected as the Realm Routing Strategy, these peers will be excluded from lookups in the Realm Routing Table. You can use ExcludePeers to act on errors in the answers from a Diameter server. For instance, if a peer answers with the Result-Code AVP set to | |
| This field is populated with the Diameter identity of the sending peer.
|
| ||
| The Diameter Stack agent populates the Request field with the "request message UDR" before routing the RequestCycleUDR to the workflow. For the Diameter Request agent it will work the reversed way and request messages will be transmitted from the workflow to the Diameter Stack agent by using this field.
|
| ||
| A operating system uptime indicating when the server receives the request in nanoseconds. | |
| A operating system uptime indicating when the client sends the request in nanoseconds. | |
| A Diameter Session-Id value that will be read from the Request field in the Diameter message. This is a read-only field. | |
| This fl ag indicates whether the UDR has been throttled or not. Default is
|
|
WrappedMZObject
The WrappedMZObject UDR does not map to a Diameter message but can be used to send data between workflows. WrappedMZObject is added as a field in the RequestCycleUDR (request or answer).
Note |
---|
Note!Since this is not a normal Diameter message, the receiver has to be another workflow. |
The following fields are included in the WrappedMZObject UDR:
Field | Description |
---|---|
| The data to send to another workflow. |
| The server host, the destination of the message. |
| The realm where to route the message. |
| Used to indicate if the message is a request or not. |
| To be used if when no reply is expected. |
DiameterErrorUDR
When any of the following errors occurs, the Diameter Stack agent creates a DiameterErrorUDR
:
Decoding and validation errors for known requests and answers (e g unknown or missing AVP)
Unknown request or answer (unknown command ID)
Failure in CER/CEA handshake (e g no common applications)
Request or answer sent before CER/CEA handshake
A DiameterErrorUDR is not created unless the erroneous incoming data is formatted as a Diameter command. It must contain a header followed by a payload.
The following fields are included in the DiameterErrorUDR
UDR:
Field | Description |
---|---|
| This field contains the error message. |
| This field is populated with the incoming message if it can be decoded. |
| This field contains the name of the source peer, as specified in the Diameter routing profile configuration. If the peer is unknown, this field contains the content of the Origin-Host AVP, provided that the incoming message can be decoded. |
| This field contains the original Diameter message. |
| This fields contains the Diameter result code. |
| This field is populated with the answer message, if any. |
| This field is always empty. |
You can configure the Diameter Stack agent to route UDRs of this type to the workflow. For more information, see Advanced Tab in Diameter Stack Agent Configuration.
...
The ConnectionLost UDR is sent whenever a connection to a peer is lost, regardless of the reason for the connection going down, i e, whether it is a controlled shutdown or, for example, a network failure.
Field | Description |
---|---|
| This field contains the connection related message indicating the reason for the lost connection. |
| This field contains the name of the peer to which the connection is lost. |
You can configure the Diameter Stack agent to route UDRs of this type to the workflow. For more information, see Advanced Tab in Diameter Stack Agent Configuration.
Anchor | ||||
---|---|---|---|---|
|
The Diameter Stack agent produces three error answers with internal result codes.
No suitable route
When there is no peer or realm in the Diameter Routing profile that matches the content of the AVPs that are used for routing, a message with the error code 4997 is returned.
The following AVPs are used for routing:
Destination-Host
Destination-Realm
Acct-Application-Id
Auth-Application-Id
Vendor-Specific-Application-Id
This error may also occur when all the peers of a realm are specified in the ExcludePeers field of a RequestCycle UDR and Round Robin is the selected Realm Routing Strategy.
...
The diagram below illustrates a failover scenario where a CCR (Credit Control Request) message is routed from a workflow.
...
Handling of Outstanding Request at Peer Failover
A CCR message is routed from a workflow to a Diameter Stack agent.
The Diameter Stack agent routes the CCR message to Peer 1. The peer connection status of Peer 1 is OKAY.
Peer 1 does not respond within the timeout period that is configured in the Diameter Stack agent and an Error Answer Message is routed back to the workflow.
The workflow is configured to act on the Error Answer Message and resends the CCR message.
Since the Diameter Stack agent does not receive an answer after the first CCR message, it sends a DWR (Diameter Watchdog Request) message to Peer 1.
The watchdog timer interval TWINIT expires without a response from Peer.
The Diameter Stack agent sends a second DWR message to Peer 1.
The workflow makes a third attempt at sending the CCR message.
In the meantime, TWINIT has expired twice and the connection state for Peer 1 has changed to SUSPECT. This triggers the Diameter Stack agent to resend the CCR message to a different peer.
Diameter requests are only routed to peers with status REOPEN and SUSPECT as a last resort, i e when there are no peers with status INITIAL or OKAY. For this reason the Diameter agent now immediately routes the CCR message to another available peer (Peer 2 in this example).
TWINIT has now expired three times and the peer connection status has changed to DOWN. This means that messages are no longer routed to this peer.
Peer 2 responds with a Credit Control Answer (CCA) message to the Diameter Request agent, which then routes the message back to the workflow.
For simplicity of the example above, TWINIT appears longer than the Diameter answer timeout. In a production configuration this is typically not the case.
For information about how to configure the Diameter answer timeout and TWINIT, see Diameter Stack Agent. For For information about how to configure Diameter peers, see Diameter Routing Profile.