How do I send a Diameter message to an IP other than Destination-Host's value in mobicents

Question

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?

Answer 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

Answer 2

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.