Versions Compared

Old Version 2

changes.mady.by.user Kevin Wu

Saved on

compared with

New Version Current

changes.mady.by.user Former user

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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.Image Removed

...

A Diameter Stack workflow

Note
title

Note!

  • Diameter Base Protocol commands such as Capability-Exchange-Request and Capability-Exchange-Answer, are handled internally by the Diameter Stack agent. You see an indication of execution of these commands on the Workflow Monitor in the debug mode. The Diameter Stack agent also publish MIM values that contain counters for the various commands.

  • AVPs (Attribute-Value pairs) from the Diameter Base Protocol are static, unchangeable, and always available to the system.

Anchor
DiameterRequest
DiameterRequest
Diameter Request

...

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.Image Removed

...

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.

title
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

Answer (BaseCommand (Diameter))

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.

Note
title

Note!

In the answer message UDR, the fields Origin_Host and Origin_Realm will be automatically populated by the Diameter stack in case they are unconfigured, i e set to null. Otherwise, your configured values will be used.

The field EndToEndIdientifier is available as a read-only field and will always have the same value as in the "request message UDR".

AnswerReceivedTime (long)

A timestamp indicating when the client receives the answer in nanoseconds.

AnswerSentTime (long)

A timestamp indicating when the server sends the answer in nanoseconds.

Context (any)

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.

ExcludePeers (list<string>)

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 DIAMETER_TOO_BUSY 3004, you may want to exclude this peer in consecutive requests for some time.

IncomingRemotePeer (string)

This field is populated with the Diameter identity of the sending peer.

Note
title

Note!

The field is read-only and will be automatically populated by the Diameter stack.

Request (BaseCommand (Diameter))

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.

Note
title

Note!

In the request message UDR, the fields Origin_Host and Origin_Realm will be automatically populated by the Diameter stack in case they are unconfigured, i e set to null. Otherwise, your configured values will be used.

The value of the field EndToEndIdientifier can be configured by using APL. If it is not configured, the value will be set by the stack sending out the request.

RequestReceivedTime (long)

A operating system uptime indicating when the server receives the request in nanoseconds.

RequestSentTime (long)

A operating system uptime indicating when the client sends the request in nanoseconds.

Session_Id(string)

A Diameter Session-Id value that will be read from the Request field in the Diameter message. This is a read-only field.

Throttled(boolean)

This fl ag indicates whether the UDR has been throttled or not. Default is false , and if the UDR has been throttled, it will be set to true . 

Note
title

Note!

If Throttled is true , the Answer field of the RequestCycleUDR will be set to null.

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).

title
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

Data (any)

The data to send to another workflow.

Destination_Host (string)

The server host, the destination of the message.

Destination_Realm (string)

The realm where to route the message.

Is_Request (boolean)

Used to indicate if the message is a request or not.

Is_Unidirectional (boolean)

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

ErrorMessage (string)

This field contains the error message.

IncomingMessage (BaseCommand(Diameter))

This field is populated with the incoming message if it can be decoded.

IncomingRemotePeer (string)

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.

RawIncomingMessage (bytearray)

This field contains the original Diameter message.

ResultCode (int)

This fields contains the Diameter result code.

SentAnswer (BaseCommand(Diameter))

This field is populated with the answer message, if any.

OriginalData (bytearray)

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

Message (string)

This field contains the connection related message indicating the reason for the lost connection.

PeerName (string)

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
SpecialErrorHandling
SpecialErrorHandling
Special Error Handling

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.Image Removed

...

Handling of Outstanding Request at Peer Failover

  1. A CCR message is routed from a workflow to a Diameter Stack agent.

  2. The Diameter Stack agent routes the CCR message to Peer 1. The peer connection status of Peer 1 is OKAY.

  3. 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.

  4. The workflow is configured to act on the Error Answer Message and resends the CCR message. 

  5. 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.

  6. The watchdog timer interval TWINIT expires without a response from Peer.

  7. The Diameter Stack agent sends a second DWR message to Peer 1.

  8. The workflow makes a third attempt at sending the CCR message.

  9. 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.

  10. 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).

  11. 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.

  12. 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.