3

We are working on creating a diameter adapter for OCS. Currently our AVP dictionary is as supplied by go-diameter.

We are trying to Provide a configurable dictionary to support Following

  • Vendor Specific AVPs to support different network providers, like Nokia and Ericsson
  • Support for different Network traffic, like VoLTE, GGSN, Tango.

Following are the two approaches that we are currently thinking on.

  • Include a single dictionary with all supported AVPs and have a single release of diameter adapter. The intelligence to be build inside the code for identifying which AVPs are required for which node.
  • Have different releases for each dictionary that we want to support, and deploy which ever is required by the service provider.

I have search over the internet to see if something similar has been done as a proof of concept. Need help in identifying which is better solution for implementation.

Deepak Kumar
  • 426
  • 7
  • 20

1 Answers1

4

Im not familiar with go-diameter but My suggestion: Use one dictionary

This dictionary should be used by all vendors and providers.

Reasons:

  1. You dont know how many different releases you will end up with and you might need to support many dictionaries at the end.
  2. If you use few dictionaries most of the AVPs will be the same on all
  3. As bigger as your one dictionary will be you will support more AVPs everywhere and you never 100% sure which AVP might arrive from different clients
Oded Itzhaky
  • 445
  • 5
  • 16
  • 3
    Author of go-diameter here. Just seen this for the first time and the answer makes total sense: use one dictionary; mostly because of the AVP overlap. – fiorix Apr 30 '19 at 22:34
  • Reason why one-dictionary may not be realistic is because the proprietary Diameter AVPs are exactly that -- 'proprietary', and you cannot share or ship this information without NDA. – bdutta74 May 21 '21 at 13:11