CEA supported Applications

[SummaNetworks]

We have a case in which the Jdiameter is sending a CEA message for a CER message asking about support for 10415 applications, however, the CEA contains ALL supported features. Inside the CEA, by default the Cx states support for both 10415 and 13019. However the server that sent the CER complaints about the duplicity. We have been reading the RFCs, and the 6733 (https://tools.ietf.org/html/rfc6733#section-5.3) states the following:

The receiver of the Capabilities-Exchange-Request (CER) MUST determine common applications by computing the intersection of its own set of supported Application Ids against all of the Application-Id AVPs (Auth-Application-Id, Acct-Application-Id, and Vendor-Specific-Application-Id) present in the CER. The value of the Vendor-Id AVP in the Vendor-Specific-Application-Id MUST NOT be used during computation. The sender of the Capabilities-Exchange-Answer (CEA) SHOULD include all of its supported applications as a hint to the receiver regarding all of its application capabilities.

Could we have a way to limit the responses on the CEA to follow the first statement, and limit the supported applications to the ones that intersect? Could it be a configuration? What do you think? Is it worth checking?

[xphudin]

Hi @SummaNetworks , How could you reproduce that issues? I can see in source code that CEA is sent with intersection of apps-id

[SummaNetworks]

Hi,

Tested with the last version, we are sending this: Command Code: 257 Capabilities-Exchange ApplicationId: Diameter Common Messages (0) Hop-by-Hop Identifier: 0x5349e69c End-to-End Identifier: 0x01a00000 [Request In: 2896] [Response Time: 0.059181110 seconds] AVP: Origin-Host(264) l=25 f=-M- val=hss.open-ims.test AVP: Origin-Realm(296) l=32 f=-M- val=virtualbox.open-ims.test AVP: Host-IP-Address(257) l=14 f=-M- val=192.168.1.21 AVP: Vendor-Id(266) l=12 f=-M- val=10415 AVP: Supported-Vendor-Id(265) l=12 f=-M- val=10415 AVP: Vendor-Specific-Application-Id(260) l=32 f=-M- AVP: Auth-Application-Id(258) l=12 f=-M- val=3GPP S6a/S6d (16777251) AVP: Supported-Vendor-Id(265) l=12 f=-M- val=193 AVP: Vendor-Specific-Application-Id(260) l=32 f=-M- AVP: Acct-Application-Id(259) l=12 f=-M- val=Diameter Base Accounting (3) AVP: Vendor-Specific-Application-Id(260) l=32 f=-M- AVP: Vendor-Specific-Application-Id(260) l=32 f=-M- AVP: Supported-Vendor-Id(265) l=12 f=-M- val=13019 AVP: Vendor-Specific-Application-Id(260) l=32 f=-M- AVP: Vendor-Specific-Application-Id(260) l=32 f=-M- AVP: Product-Name(269) l=16 f=--- val=SummaHSS AVP: Result-Code(268) l=12 f=-M- val=DIAMETER_SUCCESS (2001) AVP: Firmware-Revision(267) l=12 f=--- val=1

To a CER with only 10415, so, its not working as expected.

[xphudin]

I just wonder why need to limit the supported apps? . The sender of the Capabilities-Exchange-Answer (CEA) SHOULD include all of its supported applications as a hint to the receiver regarding all of its application capabilities.

[SummaNetworks]

Yes, but prior to that it says:

The receiver of the Capabilities-Exchange-Request (CER) MUST determine common applications by computing the intersection of its own set of supported Application Ids against all of the Application-Id AVPs (Auth-Application-Id, Acct-Application-Id, and Vendor-Specific-Application-Id) present in the CER.

And doing tests with an EPC vendor, they said we included all supported, which was not expected, as reading the specs. So, we need to find a way to live with both options. We could add a parameter in the XML to define which option:

1. Send only the intersection
2. Send all supported apps.

[xphudin]

hi @SummaNetworks , I had added an parameter in "jdiameter-config.xml" to define which option is selected:

1. Send only the intersection
2. Send all supported apps.

[brainslog]

Hi,

I think the specification clearly says that what we are doing is the correct way:

The sender of the Capabilities-Exchange-Answer (CEA) SHOULD include all of its supported applications as a hint to the receiver regarding all of its application capabilities.

Regarding, the prior text:

The receiver of the Capabilities-Exchange-Request (CER) MUST determine common applications by computing the intersection of its own set of supported Application Ids against all of the Application-Id AVPs (Auth-Application-Id, Acct-Application-Id, and Vendor-Specific-Application-Id) present in the CER.

What this means is that the receiver of the CER will intersect the applications received in the CER with it's own to know which ones are actually being provided, but that doesn't mean anything regarding what Applications go in the CEA, it's mostly to know wether to answer with the Result-Code set to DIAMETER_NO_COMMON_APPLICATION or not, as per:

A receiver of a Capabilities-Exchange-Request (CER) message that does not have any applications in common with the sender MUST return a Capabilities-Exchange-Answer (CEA) with the Result-Code AVP set to DIAMETER_NO_COMMON_APPLICATION and SHOULD disconnect the transport layer connection.

I am not totally against the inclusion of such configuration (as long as it's not a required parameter and it's omission results in acting as we are doing currently) but I don't think we should be covering these for vendors which don't comply with the specification.

@SummaNetworks can you disclose which vendor isn't working with this ? Maybe there's a chance they fix it on their side..

[xphudin]

@brainslog @SummaNetworks Is there any final decision ?

[SummaNetworks]

Sent private email about the vendor, waiting on a reply.

[SummaNetworks]

Hi @brainslog, What shall be the resolution then? Do you think you can talk to @xphudin and explain what is the expected solution? Best regards

[brainslog]

Hi @SummaNetworks,

As far as I remember, it was seen that the issue was actually that the CEA (or the CER) might contain the "same" AVP more than once, and thus be rejected with Result-Code 5009 (DIAMETER_AVP_OCCURS_TOO_MANY_TIMES).

In the case, it was for Cx/Dx.. In our Cx/Dx RA, we do support Cx/Dx with both 3GPP (10415) and ETSI (13019) Vendor-Id, by having separate Vendor-Specific-Application-Id AVP for each. I don't see it as an issue, as it advertises support for AVPs coming from each vendor, and seems to be the proper way to do it, according to this DIME mailing list thread:

The SCE and PD-PE shall advertise the support of AVPs specified in
3GPP, ETSI, and ITU-T documents by including the values 10415
(3GPP), 13019 (ETSI) and 11502 (ITU-T) in three different
instances of the Supported-Vendor-Id AVP in the CER and CEA
commands respectively.

Anyway, if causing issues, it can always be changed by removing one of them from the Cx/Dx RA configuration.

Thoughts ?