1

In all Diameter implementations I saw, the messages originating from the server is always sent towards the DNS resolved IP address of whats in the Destination-Host AVP. But, in commercial servers, we see an option to configure a DRA or a DEA which takes in all the messages and routes them.

Thus, when it comes to the mobicents diameter stack, this approach is sometimes hard to do. I can anyway re-configure the hosts file so that the message ends up in a DRA/DEA, yet, its a pain. I see no option to send these messages to a central diameter agent which will take care of all the dirty work for me.

The next issue is, if I plan to create such a DRA/DEA, the stack does not accept messages to a different host. Where, the message's Destination-Host parameter might contain a different hostname than ours. (which would be the ultimate destination it needs to go)

Is there a hack to achieve this without meddling with the internals of the jdiameter code and RA code?

Tharaka Devinda
  • 1,952
  • 21
  • 23
  • Which diameter interfaces are you using? Versions? – delephin Jan 04 '16 at 17:26
  • jdiameter latest from github and Credit Control RA 2.8.0. If it can do that, I'll run any version :) – Tharaka Devinda Jan 04 '16 at 18:20
  • Who is creating the CCRs? Do you hava an sbb creating them? – delephin Jan 04 '16 at 20:11
  • Yes. I want to direct my message to a different IP address when I do; CreditControlClientSession.sendCreditControlRequest(CreditControlRequest r) – Tharaka Devinda Jan 05 '16 at 04:49
  • 1
    We don't have a DRA, so I'm a bit out of my depth, but maybe you could try and change jdiameter's configuration? Add a network realm and peer to identify your DRA, then it's a matter of changing your CCR and set that realm as destination. Destination host is not need. – delephin Jan 05 '16 at 15:27
  • Wow. That's something to try. I'll try that and tell you. We don't have an operational one too. But there are applications where I need to send the message like this. – Tharaka Devinda Jan 06 '16 at 17:06

2 Answers2

1

If you change jdiameter's config to something like this:

<Network>
    <Peers>
      <Peer name="aaa://127.0.0.1:21812" attempt_connect="false" rating="1" />
      <Peer name="aaa://CUSTOM_HOST:4545" attempt_connect="false" rating="1" />
    </Peers>
    <Realms>
      <Realm name="custom.realm" peers="CUSTOM_HOST" local_action="LOCAL" dynamic="false" exp_time="1">
        <ApplicationID>
           ...
        </ApplicationID>
      </Realm>
     </Realms>
 </Network>

In your sbb, then you'll need to create a client session providing your custom realm using this method:

DiameterCCAResourceAdaptor.CreditControlProviderImpl.createClientSession(DiameterIdentity destinationHost, DiameterIdentity destinationRealm)

Example:

ccaRaSbb.createClientSession(null, "custom.realm")

where ccaRaSbb is a CreditControlProvider instance (resource adaptor interface)

finally, when creating your CCR, the method CreditControlClientSession.createCreditControlRequest() will use the session' realm to find an available peer previously configured.

Let me know if this makes sense to you

Liju Thomas
  • 1,054
  • 5
  • 18
  • 25
delephin
  • 1,085
  • 1
  • 8
  • 10
  • This is not possible for my situation. See the solution I posted. It has how I tackled the problem. In your answer you have assumed I have direct connection with the destination. The case is not that. – Tharaka Devinda Aug 21 '20 at 07:38
0

Posting the method I used to solve this problem.

As it turns out its not possible out of the box to send a diameter message towards a peer which is not configured in the stack's jdiameter-config.xml file.

For me, the option to alter the stack in this case was also not feasible. So I devised a workaround for the problem by co-operating with the DRA we have. (most DRA's should be able to handle this method)

  1. I added two custom AVPs to the outgoing request, namely Ultimate-Destination-Host and Ultimate-Destination-Realm.
  2. In the DRA, I asked the admin to delete my Destination-Host and Destination-Realm AVPs and replace them with the ones created in step 1.

Now, whenever I send a packet destined to other diameter peers outside the configured peer, I target them towards the DRA and set these 'Ultimate' destination AVPs.

Ours is an Oracle DSR which is capable of doing this AVP manipulation. Most commercial ones should be able to handle it. Hope someone who wanted an answer for this question found this useful.

Tharaka Devinda
  • 1,952
  • 21
  • 23