22 Jul
2015
22 Jul
'15
10:23 a.m.
Dear all,
With this mail i would like to explain better my modifications to CDP module for Rx
diameter message routing. (pull request #238).
As you know, the ims_qos module create AAR Diameter message sent from P-CSCF to PCRF on
REGISTER or on the first response received by the P-CSCF with a valid SDP during INVITE
and STR message on BYE
After the creation of AAR message, the routing decision is made in the cdp module.
On get_routing_peer function (routing.c file), fist of all,
AVP_Vendor_Specific_Application_Id is checked. If this AVP is present, AVP_Vendor_Id and
AVP_Auth_Application_Id is checked together.
If they are present on the message, vendor_id and app_id are assigned with the respective
values retrieved from the message.
After that, AVP_Auth_Application_Id is checked.
If this AVP is present, AVP_Vendor_Id is checked. If this is not present, vendord_id is
assigned to zero.
The same behavior is implemented for AVP_Acct_Application_Id.
This way, if Auth_Application_Id is present but not AVP_Vendor_Id is not, vendor_id
variable is zero and peer_handles_application function will return always zero and the
module will not be able to route correctly the request (unless you by-pass the routing
forcing explicitely the peer on the script).
Taking a look to the specs (TS 29.214) AVP_Auth_Application_id is mandatory, meanwhile
AVP_Vendor_Id and AVP_Acct_Application_Id is not present. For this reason, IMHO vendor_id
variable cannot be forced to zero if one of them is not present.
In my patch, vendor_id variable is updated if only both AVP are present
(Auth_Application_Id and Vendor_Id or
AVP_Acct_Application_Id and Vendor_Id).
In my tests, everything is working with my patch and also the other Diameter messages
(e.g. from I-CSCF or S-CSCF to HSS and vice-versa). However, i would like to have your
point of view on the matter.
Best regards,
Federico Favaro
R&D Department
Athonet s.r.l.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/238#issuecomment-123653011