aboutsummaryrefslogtreecommitdiffstats
path: root/lib/diameter/doc
diff options
context:
space:
mode:
authorAnders Svensson <[email protected]>2017-04-12 11:23:23 +0200
committerAnders Svensson <[email protected]>2017-06-13 14:03:58 +0200
commit2013b1c55e2c199e59610cf9bb7e0cb60424f276 (patch)
tree80f6caff80a91efca386f10661ebdaaf9e9a9248 /lib/diameter/doc
parent1e5be430c70d95bfde51aa785398127bbb72089d (diff)
downloadotp-2013b1c55e2c199e59610cf9bb7e0cb60424f276.tar.gz
otp-2013b1c55e2c199e59610cf9bb7e0cb60424f276.tar.bz2
otp-2013b1c55e2c199e59610cf9bb7e0cb60424f276.zip
Comment on RFC ambiguity regarding application identifiers
It is tempting to regard remote support for the common application as implicit, but that leads to the problems noted, and a node could never then expect non-intersecting application support to result in 5010. It probably can't anyway given the different ways the RFC's intent can be interpreted, but it's not unreasonable that a node should be able to advertise a single Diameter application and get 5010 if the peer doesn't support it. The problem we have currently is that peer selection is based on the support advertised by the peer. The application id of an outgoing request is used to lookup peers that have advertised support, so if the peer hasn't advertised support for Diameter common messages then the user won't be able to send DPR and more: diameter:call/4 will just return {error, no_connection}. This commit doesn't solve the problem.
Diffstat (limited to 'lib/diameter/doc')
0 files changed, 0 insertions, 0 deletions