Connecting jdiameter to a DRA
Opened this issue · 8 comments
I need to connect the stack to a DRA. So the messages I send will be routed through a DRA (Diameter Routing Agent)
So far, I see no possibility to do that in the config. I have to statically configure Peer nodes and jdiameter sends the packet to the resolved IP for the DestinationHost AVP.
My DestinationHost values are in other networks and could be anything. (cannot be pre-configured)
This is the basic idea ( Key host(realm) )
app.me.com(me.com) --> dra.me.com(me.com) : XXR sends the request to other.them.org
dra.me.com(me.com) --> other.them.org(them.org) : XXR
Although the destination host AVP contains other.them.org, the packet has to be sent to dra.me.com. The DRA will take care of the rest.
Is this possible with jdiameter? How can I achieve this?
If this is not possible with jdiameter which part of the code do I need to modify to make this happen. I can do a PR if it goes right. I think this will be useful to many people since most telco based diameter applications are behind DRAs.
Hi,
I think you are looking for SRV entries in DNS records and not related to Diameter
Thats a good idea to try out. But I doubt if I can send messages out which are not specified in the peer configuration. I will try it anyway.
I think for instance F5 DRAs has realm based routing and even you could do some magic with regex patterns to send it to realm or even to some particular hosts
btw you two options:
- specify the final destination in the request
- put the DRA realm there and if the DRA is clever enough it can do the manipulation or origins and destinations - it acts like a proxy and hides the topology, but like I wrote.. we had to develop a groovy script for the F5 DRA
We were able to get this working by specifying the OCS's realm as the destination realm in the request, and not manually specifying a destination host.
By adding the DRAs (which have their own realm) to the OCS's realm, jdiameter then routes requests to one of the peers in the OCS realm (i.e. one of the DRAs). Because the destination realm in the request is the OCS's realm, the DRA then forwards the request accordingly (that's outside our control, but we've had confirmation that the messages are successfully routed).
Our client's jdiameter config's Network section looks like this:
<Network>
<Peers>
<Peer name="DRA1" rating="1" ip="fill in later"/>
<Peer name="DRA2" rating="1" ip="fill in later"/>
</Peers>
<Realms>
<!-- DRAs -->
<Realm name="dra.realm" peers="DRA1,DRA2" local_action="LOCAL" dynamic="false" exp_time="1">
<ApplicationID>
<VendorId value="0"/>
<AuthApplId value="0"/>
<AcctApplId value="0"/>
</ApplicationID>
</Realm>
<!-- Ro -->
<Realm name="ocs.realm" peers="DRA1,DRA2" local_action="LOCAL" dynamic="false" exp_time="1">
<ApplicationID>
<VendorId value="10415"/>
<AuthApplId value="4"/>
<AcctApplId value="0"/>
</ApplicationID>
</Realm>
</Realms>
</Network>
Note that the DRA's realm supports VendorId 0, AuthApplId 0, AcctApplId 0, so it can connect and send/receive CER/CEA, DPR/DPA and DWR/DWA requests. The OCS's realm supports 3GPP Ro requests, which are then forwarded to the OCS.
We were able to get this working by specifying the OCS's realm as the destination realm in the request, and not manually specifying a destination host.
By adding the DRAs (which have their own realm) to the OCS's realm, jdiameter then routes requests to one of the peers in the OCS realm (i.e. one of the DRAs). Because the destination realm in the request is the OCS's realm, the DRA then forwards the request accordingly (that's outside our control, but we've had confirmation that the messages are successfully routed).
Our client's jdiameter config's Network section looks like this:
<Network> <Peers> <Peer name="DRA1" rating="1" ip="fill in later"/> <Peer name="DRA2" rating="1" ip="fill in later"/> </Peers> <Realms> <!-- DRAs --> <Realm name="dra.realm" peers="DRA1,DRA2" local_action="LOCAL" dynamic="false" exp_time="1"> <ApplicationID> <VendorId value="0"/> <AuthApplId value="0"/> <AcctApplId value="0"/> </ApplicationID> </Realm> <!-- Ro --> <Realm name="ocs.realm" peers="DRA1,DRA2" local_action="LOCAL" dynamic="false" exp_time="1"> <ApplicationID> <VendorId value="10415"/> <AuthApplId value="4"/> <AcctApplId value="0"/> </ApplicationID> </Realm> </Realms> </Network>Note that the DRA's realm supports VendorId 0, AuthApplId 0, AcctApplId 0, so it can connect and send/receive CER/CEA, DPR/DPA and DWR/DWA requests. The OCS's realm supports 3GPP Ro requests, which are then forwarded to the OCS.
Thanks a lot for this. I will look into this option as well. As of this moment we're sending the actual destination which the packet needs to go, in a custom AVP and then trying to replace those from the DRA.
Yes this is possible.
Modifications in the config file : Add the Other Diameter node's realm(not DRA's realm) in the Realms.
and IP Port of the DRA in the Peers.
Example:
<Network>
<Peers>
<Peer name="<DRA ip:port>" attempt_connect="false" rating="1" />
</Peers>
<Realms>
<Realm name="<Other node's Realm>" peers="<DRA IP>" local_action="LOCAL" dynamic="false" exp_time="1">
<ApplicationID>...</ApplicationID>
</Realm>
</Realms>
</Network>
Modifications in the JDiameter Request - Add Destination Host(optional) and Destination Realm of Other node
This would not work. Peers are statically configured. In my case, I was sending the messages to any telco operator in the world. But thanks for this. I think Stephen's and your answers are worthwhile trying out when I dive into diameter again. We closed this project using the DRA only.