2

I'm working on a python implementation of the Diameter protocol. I wonder what's the expected behaviour if a Diameter peer in this scenario:

  1. Peer1 sends CER to Peer2
  2. Peer2 sends CEA to Peer1 (with a result code DIAMETER_SUCCESS: 2001)
  3. The diameter connection is ready.
  4. some Diameter Traffic
  5. Peer1 resend another CER to Peer2
  6. What's the expected behaviour of Peer2 ?

does peer2 closed the connection ? or does Peer2 must resend a CEA ?

I know that this scenario shouldn't happen, but ... if peer2 has a buggy implementation.

I see nothing about that in the rfc6733.

Thanks

delanne
  • 420
  • 1
  • 4
  • 12
  • I am having the same issue I am using ericsson charging sdk 1.0 but I think this is not due to buggy peer2, if a CER is sent again it is a problem of peer1 – shabby May 13 '13 at 19:29
  • Yes indeed, I wanted to write peer1 instead of peer2. Thanks for the correction. – delanne Sep 11 '14 at 14:40

4 Answers4

1

You could keep first connection or start a new one, as you can see in rfc6733

A CER message is always sent on the initiating connection immediately after the connection request is successfully completed. In the case of an election, one of the two connections will shut down.

Community
  • 1
  • 1
saf
  • 171
  • 1
  • 5
0

CER and CEA should happen only once for any given live connection between Diameter Peers. Expecting it or having to handle it within the context of any existing session [dmtr] doesn't seem right. Ideally the transport connection should be broken prior to this happening. Also the use of SCTP / TLS would ensure the entire 3- Way handshake would happen before you reach the point. Maybe you need to carfully handle the State transitions of the transport layer to better define the handling.

Rajesh
  • 660
  • 4
  • 12
0

Peer 2 should discard the second CER.

It should accept second CER only after if a transport shutdown or diameter close (DPR/DPA) happens

Nithin
  • 61
  • 1
  • 1
  • 3
0

Actually RFC is quite specific on that:

   A CER message is always sent on the initiating connection immediately
   after the connection request is successfully completed.  In the case
   of an election, one of the two connections will shut down.  The
   responder connection will survive if the Origin-Host of the local
   Diameter entity is higher than that of the peer; the initiator
   connection will survive if the peer's Origin-Host is higher.  All
   subsequent messages are sent on the surviving connection.  Note that
   the results of an election on one peer are guaranteed to be the
   inverse of the results on the other.

So, to sum it up: Only one connection should survive (newest one), UNLESS you use different Origin-Host in request.

This situation is not-so-uncommon if you are using TCP and peer1 restarted without notifying peer2. So peer2 MUST allow peer1 to reconnect and use latest (newest) connection. Otherwise you are blocking messages to/from peer1 untill watchdog tears it down.

Sergej Srepfler
  • 184
  • 1
  • 11