<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p><font face="monospace">Hi all,<br>
<br>
One of the first items on the list of expanding the IMS
capabilities of OpenSIPS is to add support for <b>processing</b>
<b>Diameter requests</b>, not just originating them. Such
requests could be a requirement in a variety of scenarios,
including but not limited to:<br>
<br>
* Diameter request (event) when a device loses connection<br>
* Service profile updates sent by the HSS in the form of a
Diameter request -- <a moz-do-not-send="true"
href="https://www.rfc-editor.org/rfc/rfc4740.html#page-41">Push
Profile Request (PPR)</a> command, especially useful when
REGISTER'ing over very long durations (typical in IMS)<br>
* Diameter request for terminating a registration -- <a
moz-do-not-send="true"
href="https://www.rfc-editor.org/rfc/rfc4740.html#page-39">Registration
Termination Request (RTR)</a> command<br>
* several others<br>
<br>
Regarding the implementation, we have already brainstormed the <i>opensips.cfg</i>
interaction, which will be as follows:<br>
<br>
* config: since we're going to be using the freeDiameter
library, any Diameter commands supported by the OpenSIPS server
and their respective AVPs are to be extensively defined in the
freeDiameter configuration file, pre-startup<br>
* runtime: an event route named "<b>E_DM_<command></b>",
if any, shall be triggered on each Diameter request. Available
parameters:<br>
- <b>$param(sess_id)</b> -- containing the session's unique
ID (think of it as a transaction ID), which will be needed when
building the reply. Ideally, this variable is only for
informational/logging purposes, with the reply being naturally
constructed to include the correct Session ID by OpenSIPS<br>
- <b>$param(app_id)</b> -- the Diameter Application ID<br>
- <b>$param(cmd_code)</b> -- the Diameter Command Code<br>
- <b>$param(avps_json)</b> -- all AVPs in the request<br>
* </font><font face="monospace"><font face="monospace">runtime:</font>
script writers will process the request data, then build a <b>JSON
with the AVPs</b> to be included in the reply<br>
* </font><font face="monospace"><font face="monospace">runtime:
</font>finally, the JSON is passed to a new <b>dm_send_reply()</b>
function, similar to the existing <a moz-do-not-send="true"
href="https://opensips.org/docs/modules/3.4.x/aaa_diameter.html#func_dm_send_request">dm_send_request()</a>.<br>
<br>
Both receival and sending of Diameter messages will be done by
the existing freeDiameter process, forked by <a
moz-do-not-send="true"
href="https://opensips.org/docs/modules/3.4.x/aaa_diameter.html">aaa_diameter</a>.
OpenSIPS workers will interact with this process asynchronously
both when receiving requests from the Server Thread (to be
serialized & passed over via a SHM pointer), as well as when
directing replies to be originated by the freeDiameter Client
Thread (similar interaction, via a SHM'ized JSON string).<br>
<br>
While the development is ongoing, do let us know if there is any
special request in terms of the above that may have been missed,
or maybe w.r.t. your interactions with the freeDiameter library
in general: are you happy with it? What are some goods/bads
around it?<br>
<br>
Best regards,</font><br>
</p>
<pre class="moz-signature" cols="72">--
Liviu Chircu
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/liviuchircu">www.twitter.com/liviuchircu</a> | <a class="moz-txt-link-abbreviated" href="http://www.opensips-solutions.com">www.opensips-solutions.com</a>
OpenSIPS Summit 2024 May 14-17 Valencia | <a class="moz-txt-link-abbreviated" href="http://www.opensips.org/events">www.opensips.org/events</a></pre>
</body>
</html>