Telecom Authentication Process

Transport Failure Detection

Here today i try to explain in more general fassion, Transport failure detection depends on the deployment of the Network. I will explain this with the help of an Example.


Suppose their are two nodes Node-1 and Node-2 , Peer connection is already  established between them and they are exchanging messages on that connection. Now Node-1 sends a message MESSAGE-X to Node-2 and doesnot receive the response for the MESSAGE-X. So how long Node-1 should WAIT for the Respose (say 10ms) or should Node-1  retry (say YES) or How many time NOde-1 should retry (say 2-Times) all these things are deployment specific.

After satisfying all the deployment specific conditions Node-1 would check whether there is break in network connection or not. So for this Node-1 send DWR message to Node-2 and does not receive the DWA in specific period of time then it will retry the DWR for 3 time (include in the first DWR). If DWA is not received for any the DWR then it will take this situation as the Connection Failure. and Send the Other Messages to the Secondary Peer.

If Node-1 will receive the DWA with the Error does not mean that Connection Failure, because Node-1 has received the DWA on that Network for which Node-1 was checking whether the Transport-connection was there or not. DWA with error may contain Diameter_too_Busy or any other Error message is just  to inform the Node-1 the status of Node-2.


The process of detecting the Transport connection failure with its peer and forwarding the all pending messages to the Secondary Peer Node (Alternate Node) is known as failover.

Avp Structure of DWR and DWA
<DWR> ::= < Diameter Header: 280, REQ >
                { Origin-Host }
                { Origin-Realm }
                [ Origin-State-Id ]

<DWA> ::= < Diameter Header: 280 >
                { Result-Code }
                { Origin-Host }
                { Origin-Realm }
                [ Error-Message ]
                * [ Failed-AVP ]
                [ Original-State-Id ] =
[ Origin-State-Id ]
Avp Description

Failed-AVP:- is a grouped avp provide the Debugging information in case of reject or Error during the processing such as AVP not supported etc.

Error-Message:- provides the Error in human readable form.

Original-State-Id:- is misprinted in RFC. It is basically  Origin-State-Id.

Origin-State-Id :- Origin-State-Id is used to infer the session/connection between two nodes. Whenever there is  change is state due break/disconnection in session or transport because of reboot for instance, Then rebooted node will increase the value so that other node become aware of the fact that state of peer is changed and all previous session are no more valid. Origin-State-Id is stored on non-volatile memory on all nodes.

Every time the session fails or the node is rebooted this Origin-State-Id is monotonically increased. Both nodes that are communicating stores or maps this id for mapping the Answer-Message with proper Request-Message.

Your Comments /Suggestions and Questions are always welcome.I would try to clarify doubts with best of my knowledge. So feel free to put Questions.  


  1. Hi Vinay,

    Thanks for this article. I've a query though.

    Please let me know when no Origin-State-Id is sent in the DWR, then what Origin-State-Id value should we expect in the DWA message?

    I'm facing an issue, where invalid AVP bits of Origin-State-Id is received in DWA when NO Origin-State-Id is sent in the DWR. Error is shown below:-

    #### <> <> <> <1322126427209>


    1. Hi Rishi,

      Thanks for putting your, I request you to send the Wireshark trace of above mentioned scenario.

    2. Hi Rishi,

      If there is no Origin-State-Id in DWR then there should not be any Origin-State-Id in DWA.

  2. Hi Vinay,
    Thank you for the article.
    Let's take peer 1 configured to send a DWR every 30 seconds if no traffic is detected.
    Peer 2 is configured the same way.
    I'd like to verify something:

    At t0 peer 1 sends DWR
    at t0+30 peer2 sends DWR
    at T0+60 peer1 sends DWR

    Do you think the DWR is considered as a traffic and in this case peer1 when receiveing the DWR at T0+30 would wait another 3à to send the second DWR, that is at T0+60?

    Thank you

    1. Hi Nicolas

      DWR message exchange happens when there is no traffic between two nodes for a given period of time (i.e suppose we have configured 30 secs as DWR time then if there no message is exchange between considered nodes for 30 secs then DWR will be triggered.)

      Hence in Load condition there will not be any case where message is not exchanged for such a long time (i.e. TIME configured for DWR generally 2-5 secs) Therefore DWR is not part of LOAD.

      Under Load condition system will be busted with the message there fore DWR will not occur.

      Thanks for your query. Feel free to throw some more.

      Vinay Parashar

  3. Hello Vinay,

    Thanks for the nice article. lets there is a x-request message and waiting for y-answer message. How long the device will wait for the answer, is it application specific or session specific(depends on particular session say IP-CAN session for Gx)?

    1. Hi Moumita Barman,

      It should wait till it timed-out.

      Operator shall mention a time (generally in milliseconds)at client node, that how long client should wait for reply from Server. If Client receives answer/reply from Server after a given time frame then it shall discard the answer because as soon as it timedout session id corresponding to Request message is no more valid.

      Thanks for your query. Feel free to correct me and throw some more questions.

      Vinay Parashar

  4. This comment has been removed by the author.

  5. Hi i am kavin, its my first time to commenting anyplace, when i read this
    post i thought i could also create comment due to this sensible paragraph.
    My web page ... piano lessons

  6. Hi Vinay,

    Watchdog timer need to enable separately or DWR/DWA are triggered by default?

    1. Hi Kamal,

      It is Diameter Stack dependent thing. It totally depends on stack vendor, how they provide it. Generally there is a provision to change default time-span value of DWR/DWA message.

      Standard says two Nodes shall check whether Link is UP or Not.

  7. Hi,

    For First DWR got DWA MESSAGE and after immediately getting DWA message client sending 2nd DWR again after that getting error as SCTP : ABORT : User Initiated Abort. issue will be at DWR timer vlaue or Association ?

    1. Hi Bharath

      DWR/DWA messages are used to check whether SCTP/TCP Link is UP or not Between two nodes (Specifically TCP Link because TCP has no mechanism of health check of link)

      There is no association of DWR time and with SCTP Abort. If for a certain period of time (DWR Time) no message is exchanged then node shall send DWR to check whether LINK and Other node is up or not

  8. Hi,

    What if the node-1 do not send de DWR?? it only send CER and recive CEA and that all.

  9. I have a problem, the node-1 does not send the DWR, someone know what happen? Node-1 send de CER and recive de CEA, but thats all, the conections does not establish.

    1. Hi Cruz,

      This issue happens because of the one of the following reasons.

      1) CEA doesn't come with DIAMETER_SUCCESS or No Common Application.

      Kindly check CEA, or post the trace using tshark, following link shall help you.

      2)Any two peer node of NODE-1 or NODE-2 shall have same DIAMETER Identity.
      In this case it shall toggle; basically it drops the earlier connection, now earlier connection retries then it drops new connection.

      Kindly check DIAMETER Identity of each Node.

      3) (Un-usual case) Receives any other message before the CEA; then some times goes in unknown state.

      If you could share some more details then it would be better for whole world to solve it. Some times these issues are implementation specific.


  10. question on transport failure detection in Diameter.
    Say I have a Diameter peer connection established and my watchdog timer is 30seconds.
    Now if I do a ifconfig down on that IP interface over which the peer connection is established.
    How long will it take my local Diameter layer to detect that the IP interface has gone down? Will this be immediate or will it have to do the watchdog procedure


    1. Hi VV,

      I consider following cases

      1) LOAD Condition: Under the Load condition, Watchdog request does not come into the picture, As state in article Watchdog happens only when there is no message exchange between Peers for 30 seconds(Watchdog Time). But system is heavily loaded there-fore; In this case Transport connection would be immediate.

      2) LEAN Hour Condition: If there is no message exchange between nodes for 30 seconds then failure would only be detected with DWR message. i.e. either DWR won't be initiated by STACK or DWR would timeout, Bcz DWA won't be received in expected time. SO then detection time would be 30secs + timeout sec.


  11. If Origin-State-Id is sent in CER with value 0, is it mandatory to send the Origin-State-Id set to value 0 in the CEA message?

    1. Hi Vijay,

      Origin-State-Id set to Zero shall be inferred as Origin-State-Id not present in request.

  12. Hi Vinay, I've a couple of questions re: transport failure

    Lets say as per your example we have Node 1 and Node 2 connected and exchanging messages.

    If I understand the RF3539 correctly the Tw timer is reset (with Jitter) for every Answer message. So as you say in the busy hour the DWR is never sent.

    So lets say Node 1 has sent a CCR request to Node 2 and response-timeout (10ms in your example expires) Node 1 looks to see if it should retry ('Yes' & twice as per your example) so we would see two more attempts completed before Node 1 stops retrying, the request. Each retry would reset the Tw timer.

    Couple of things I need some help with
    - I'm not sure I understand why after 3 failures (as per local config) the DWR would be initiated? Assume this is because Tw is reset on Answers and not requests so although there may be more requests sent the lack of answers means that Tw will expire
    - How does the Credit Control Tx timer overlay onto the base response-timeout i.e. if Tx was 5ms and we set the Credit Control application to Terminate no further attempts are made, does this override the base config?
    - Lean hour vs Busy hour RFC 3539 suggests that in a busy hour it may take 2Tw to fail over I assume this is because only a DWR/DWA failure can be used to infeer the peer is down?

    Kind regards Jim

    1. Hi Jim

      We hope, that we are not deviating you from your point and correctly understood your point of view.

      If DWA is not received of a DWR in given time (TIME-OUT time), then it is implies that there is a transport layer failure between two adjacent node called as PEERs.

      In strict Implementation of RFC-6733
      If CCA is not received doesn't imply the transport failure between peer. because there can be a case in which there is an intermediate node is present between CCR client and CCR server. For CCR client peer is Intermediate node.

      following link can help you.

      Our team has also inserted an IMAGE on this blog explaining DWR

      Thanks for your query.

      Happy to help you again.

    2. Many thanks much appreciated
      Kind regards

  13. I want to understand how the DWR exchange is different from the SCTP HEARTBEAT mechanism? A diameter protocol using SCTP as transport layer will any how detect the transport failures using the HEARTBEAT messages exchanged between the two SCTP nodes, then why there is a need to exchage DWR/DWA messages still to detect transport failures?

    1. Yes Vijay

      You are right.
      If we are using TCP then there no heartbeat mechanism on TCP. DIAMETER Node can use any transport. that is why DWR is there in DIAMETER implementation.

    2. Thank you Ethan for the clarification. Does this mean that a Diameter node using SCTP as transport layer need/should not use DWR/DWA messages? May I know if this is documented anywhere in the RFC?

    3. @ Ethan

      Your clarification is correct.

      @ Vijay

      DWR is proactive solution to detect transport failure. No Reference document telling SCTP should not implement it.

      Being a server a NODE MUST support TCP and SCTP connection. Client can be TCP or SCTP.

  14. I have a query regarding the Failed-AVP AVP content to be encoded whenever a diameter node returns DIAMETER_MISSING_AVP error. RFC describes the following:
    7.1.5. Permanent Failures
    The request did not contain an AVP that is required by the Command
    Code definition. If this value is sent in the Result-Code AVP, a
    Failed-AVP AVP SHOULD be included in the message. The Failed-AVP
    AVP MUST contain an example of the missing AVP complete with the
    Vendor-Id if applicable. The value field of the missing AVP
    should be of correct minimum length and contain zeroes.

    7.5. Failed-AVP AVP
    A Diameter message SHOULD contain one Failed-AVP AVP, containing the
    entire AVP that could not be processed successfully. If the failure
    reason is omission of a required AVP, an AVP with the missing AVP
    code, the missing Vendor-Id, and a zero-filled payload of the minimum
    required length for the omitted AVP will be added.

    I am confused about the value to be encoded as defined in the above two sections(one section says as it should be filled with zeros and other section says it should be a zero-filled payload??).
    May I know what is the expected result? Is it that the Value field be left empty or encode the value field with the value "00" which is one byte and append the padding bytes?

    1. Failed-AVP is a group AVP.
      It is implied that Data field of Missing AVP shall be filled with ZERO up-to minimum length.
      ::= < AVP Header: 279 >
      1* {Missing-AVP Header: - - - [Data]} Data shall be filled be ZERO

      Thanks for your query.

      Happy to help you again.

    2. Ok, can you confirm if the following encoding is correct, for example for "Origin-Realm" AVP this would look like as below:
      + Failed-AVP
      ::= < AVP Header: 279 >
      ::= Origin-Realm
      AVP Code: 296
      AVP Flags: 0x40
      AVP Length: 8

      ---> Data field is empty

    3. Wireshark/tshark is the tool to check format.

      Thanks for your query.

      Happy to help you again.

  15. Hello,

    In the example above, if there is an underlying transport link failure between Node-1 and Node-2, but Node-2 has not been seen as suspect Diameter peer by Node-1 because Tw has not expired between Node-1 and Node-2; also DWR/DWA process has not taken place to conclude that Node-2 is suspect and there is a transport link failure.


    1) I believe in Node-1 Tx timer keeps expiring and it will keep sending CCR to Node-2 setting T-bit at re-transmission each time, until the number of configurable re-transmission times is reached by Node-1?

    2) If during this time window, Tw expires and Node-1 starts to send DWR towards Node-2; and Node-1 has not exhausted the number of its configurable re-transmission times for CCR; can CCR and DWR be sent by Node-1 towards Node-2 simultaneously?



  16. This comment has been removed by the author.

  17. Hi all ,
    can any one help on this

    1)have you ever used seagull tool as a client for pumping Sy call flow
    when i am using seagull as a client ,as per my requirement i need to put timeout .In that time DWR message is receiving from server to seagull client and seagull response back with DWA,after that subsequent DWR message is sending from server but seagull never sends DWA

    is any one faced this problem .kindly provide the solution for this

    2)actually when no traffic exchanged in between two nodes with in 30 min DWR and DWA will be initiated is this time configurable in both server and client ?

    point 2 is applicable to 3GPP standards ,can we configure time for DWR and DWA both client and server side ?

    plese correct me if i am wrong

    Thanks in advance

  18. Hi Team-Diameter,

    I have two questions.

    1. If already a connection is established to diameter server. and if we try to open second connection to diameter server using same client identity. How will server react?

    2. If 'new Origin-State-Id > older Origin-State-Id' in CER, will the server clear any old socket with same diameter client (if any, and where server is using watchdog mechanism to figure out the connection state, but watchdog timer still has not expired).

    1. Hi Devesh,

      Implementation of our suggestion could be vary in different vendor's DIAMETER stack, here we would explain what RFC-6733 say,

      1) If a DIAMETER server receives CER message again on established connection with same DIAMETER identity, then server would respond to second CER with CEA and establish the diameter connection on the basis of second CER, It shall disconnect First connection created by first CER. Because in this scenario Server would assume that client might have been rebooted and sending a fresh request to create DIAMETER connection with same DIAMETER IDENTITY. As we know CER is the first message exchanged to establish a DIAMETER connection.

      Following things we have observed with different vendor stacks in context with above explanation, do share if any thing new you people have observed.

      a) Stack would not allow to connect another node with same DIAMETER IDENTITY.
      b) Diameter connection fluctuates between two clients, because second client breaks the connection of first by sending CER with same identity and first client retries for its broken connection shall break the connection created by second client.

      2) working on it.

      we hope our suggestions would help you,

      Thanks for your query.
      Happy to help you again.