Programming a DWR/DWA thread in a lightweight DIAMETER client

[Danny Saro]

Hi,

(I tried to post a similar question yesterday but ... upfront apologies if it shows up twice all of a sudden)

We are building a lightweight DIAMETER client to be used in Test Automation and Service Virtualization platform. This client only uses jDiameter API (no JAIN SLEE, ...), objective is to run mainly CCA sessions.

Must be overlooking something simple but I can't seem to get a DWR/DWA thread started from a running diameter stack. The messages all seem to have session-related AVPs.

Can someone share some high-level (pseudo)code how that would be done?

Tia,
Danny

[Alexandre Mendonça]

Hi Danny,

Both messages were received. Can you explain a bit more your requirements ? If all you want is the stack to send DWR, all you have to do is.. not do anything ;)

The stack should send a DWR by itself when there's no activity in the connection for a while, to query if the other peer is still alive.

Hope it helps.

Regards,

Alexandre Mendonça
http://ammendonca.blogspot.com/

--
You received this message because you are subscribed to the Google Groups "mobicents-public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mobicents-publ...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Danny Saro]

Hi Alexandre,

Thank you very much for this answer, it means a lot to me because this was my assumption all along, I was always assuming that the stack would take care of it.

So, what are my requirements then? From our platform we set up a diameter connection to a rating and charging platform. It's a CCA application, our diameter client is used for test automation, so we start sending CCR messages straight away (at a rate of 2 per second). The vendor insist that the first thing they expect from our client is a DWR message, without it the TCPIP connection will just be ended from their side after x amount of seconds.

So, thanks for confirming that our client - thanks to your implementation - is behaving according to the diameter specification. I am not an expert in the diameter protocol, does the specification define the amount of time?

I will certainly discuss with the vendor about their interpretation of the specification. But theirs is an existing system within a comms-company, other apps seem to adhere to their interpretation, so the solution will probably still have to come from our side.

 

Is there any way to configure the jDiameter stack to send the DWR sooner, to influence the interval?

Do you see any other way to fullfill the requirement? 

Thanks,

Danny

[Alexandre Mendonça]

Hi Danny,

Unfortunately there's this tendency of customising the standards :\ then others must hack a standard implementation to make it work..

If you can clarify on why they need such behavior, it may help to understand if it's something we may consider. The interval we use is based on the IAC Timeout.. it's a "random" value in the range IAC_TIMEOUT±2. By default IAC_TIMEOUT is 30 seconds, so that means [28,32] seconds. If you set the IAC_TIMEOUT to a lower value, it will send it sooner.. see if that works for your use case. You can set it on jdiameter-config.xml parameters.

​Hope it helps,

Alexandre Mendonça
http://ammendonca.blogspot.com/

[Danny Saro]

Alexandre,

Thanks, indeed, setting the IAC_TIMEOUT to 5 seconds and doing nothing for a while then the jDiameter client starts to send DWR messages.

And the targeted DIAMETER server still disconnects after about 15 seconds (after 3 DWR/DWA cycles) but now the issue is clearly with them.

Even if they insist to receive a DWR at least every 30 seconds then now I can have a work-around, from out Test Automation platform we completely drive the conversation, so I can have cycles of "do nothing for 10 seconds (the stack will send a DWR)" then "send bursts of messages for 20 seconds" then "go nothing for 10 seconds", etc...

Again, thank you very much for your help, I expect to be good now on this issue, you can direct your knowledge to other people's problems :-)

Cheers,

Danny