[erlang-questions] A (hopefully simple) diameter relay question

[Tim Watson]

In fact, according to RFC 3588:

Relay and redirect agents MUST advertise the Relay Application
Identifier, while all other Diameter nodes MUST advertise locally
supported applications.  The receiver of a Capabilities Exchange
message advertising Relay service MUST assume that the sender
supports all current and future applications.

So I would've expected just supplying ?DIAMETER_APP_ID_RELAY and ?DIAMETER_DICT_RELAY to be enough.

On 15 Oct 2013, at 16:32, Tim Watson wrote:

> Putting the list back on cc...
> 
> So actually, having read through someone else's adventure - http://erlang.org/pipermail/erlang-questions/2013-March/072918.html - I see that if you have multiple 'Auth-Application-Id' entries, you seem to need and {application, Config} tuple for each entry with the relevant dictionary. That's not at all what I want. I wish to 'snoop' on the AVPs and relay all traffic to the real diameter server. I had hoped that by just setting up
> 
> {'Auth-Application-Id', [?DIAMETER_APP_ID_RELAY]}, {application, [...., {dictionary, ?DIAMETER_DICT_RELAY}]}
> 
> that I could avoid all of that.
> 
> But unless I set the same list of values in 'Auth-Application-Id' on the erlang relay as I do on the server, the capabilities exchange seems to fail. Is it in fact possible to be a transparent relay/proxy in this fashion? I've spent the best part of 24 hours fiddling around with auth-app-ids in the test client / server and that's fair enough - but now the test client and server will happily talk directly to each other, but once the erlang relay gets in the middle it all falls apart. There must be some rules about how to configure a relay agent that I'm missing.
> 
> Cheers,
> Tim
> 
> On 15 Oct 2013, at 10:32, Ferenc Holzhauser wrote:
> 
>> Hi Tim,
>> 
>> AFAIK the restrict_connections and use_shared_peers options are internal to the diameter app for the case it is distributed when connections may be handled on different erlang nodes.
>> 
>> Typically if pick peer doesn't give you anything to pick from (assuming that peers are connected) then the remote end didn't announce support for the app id you're trying to send to (and/or tell that he is a jolly joker relay accepting anything). You being relay is not doing a lot when sending IMO.
>> What did your seagull announce when connecting?
>> 
>> BR,
>> Ferenc
>> 
>> 
>> 
>> 
>> On 14 October 2013 17:43, QDev <watson.timothy@REDACTED> wrote:
>> Hi folks,
>> 
>> Hopefully I'm being a bit dense and missing some obvious configuration here, but how do I get the OTP application to relay diameter messages to another (externally hosted) diameter server? I start my service with {'Auth-Application-Id', [?DIAMETER_APP_ID_RELAY]}, {restrict_connections, false} and {use_shared_peers, true}, and then start a listener and a relay to the upstream using the example peer module:
>> 
>> peer:connect(?MODULE, {tcp, loopback, 13868}),
>> peer:listen(?MODULE, tcp),
>> 
>> However whilst my callback module's handle_request gets called fine, when it returns {relay, [{extra, [relayed]}]}, in the corresponding pick_peer/5 callback there are no remote (or local) peers to select from! Do I need to add additional service configuration in order to relay to another diameter server? The server I am trying to "forward" traffic to is *not* an Erlang/OTP server btw, but some other diameter server (or as it happens in this particular case, a diameter test bed server running on seagull).
>> 
>> Cheers,
>> Tim
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20131015/c5f1b10b/attachment.htm>