[erlang-questions] erlang diameter dictionary
Anders Svensson
anders.otp@REDACTED
Sat Mar 23 11:36:57 CET 2013
Hi Samuel.
> Thanks for your quick response. But I still don't get why the DH is being
> interpreted as a list of Destination-Host values ( Is it because the define
> "avp_arity('CCR', 'Destination-Host') -> {0, 1};").
It's because Destination-Host is defined as optional in CCR:
CCR ::= < Diameter Header: 272, REQ, PXY >
...
[ Destination-Host ]
...
This results in the avp_arity/2 clause you noted in the corresponding
dictionary module.
> And if it is treated as a list, how come it has a length greater than 1, I
> just set it once in prepare_request.
The CCR definition above causes the encode of a CCR record to expect
the 'Destination-Host' field to be a *list* of AVP values. So, for
example,
'Destination-Host' = "foo.bar.com", %% = [$f,$o,$o,$.,$b,$a,$r,$.,$c,$o,$m]
is a list of 11 integer-valued Destination-Host AVP's (resulting in an
encode error), whereas
'Destination-Host' = ["foo.bar.com"],
is a list of 1 string-valued Destination-Host AVP.
/Anders, Erlang/OTP
> What should I do to correct it? Or which document should I read more
> carefully to understand this properly?
>
> Thanks a lot!
>
> Samuel
>
>
> On Fri, Mar 22, 2013 at 1:27 PM, Anders Svensson <anders.otp@REDACTED>
> wrote:
>>
>> Hi Samuel
>>
>> On Fri, Mar 22, 2013 at 5:55 PM, S X <erlangprogram@REDACTED> wrote:
>> > Thanks a lot, Anders,
>> >
>> > I think I overlooked what the meaning of the configurable ID tag (4) in
>> > the
>> > dia file is , which is supposed to be the important application ID to be
>> > used in the configuration. Your suggestion about the prefix is also
>> > right.
>> > But now I am just learning erlang diameter library.
>> >
>> > I just try to follow the sample RAR message style, and am still having
>> > issue
>> > with sending CCR message. The client configuration now is:
>> >
>> > -define(SERVICE(Name), [{'Origin-Host', ?L(Name) ++ ".example.com"},
>> > {'Origin-Realm', "example.com"},
>> > {'Vendor-Id', 193},
>> > {'Product-Name', "Client"},
>> > {'Auth-Application-Id',
>> > [?DIAMETER_APP_ID_CCRA]},
>> > {application, [{alias, ?APP_CCR_ALIAS},
>> > {dictionary,
>> > ?DIAMETER_DICT_CCRA},
>> > {module, client_cb_ccra}]}]).
>> >
>> > Try to send CCR message:
>> >
>> > call(Name) ->
>> > SId = diameter:session_id(?L(Name)),
>> > CCR = #diameter_base_rfc4006_cc_CCR{
>> > 'Session-Id' = SId,
>> > 'Service-Context-Id' = "Test",
>> > 'CC-Request-Type' =
>> > ?'DIAMETER_BASE_RFC4006_CC_CC-REQUEST-TYPE_INITIAL_REQUEST',
>> > 'CC-Request-Number' = 0,
>> > 'Auth-Application-Id' = ?DIAMETER_APP_ID_CCRA,
>> > 'User-Name' = "Me"},
>> > diameter:call(Name, ?APP_CCR_ALIAS, CCR, []).
>> >
>> >
>> > In the client callback module:
>> >
>> > prepare_request(#diameter_packet{msg = Rec}, _, {_, Caps}) ->
>> > #diameter_caps{origin_host = {OH, DH},
>> > origin_realm = {OR, DR}}
>> > = Caps,
>> >
>> > {send, Rec#diameter_base_rfc4006_cc_CCR{'Origin-Host' = OH,
>> > 'Origin-Realm' = OR,
>> > 'Destination-Host' = DH,
>> > 'Destination-Realm' = DR}}.
>> >
>> > I got the error about AVP property:
>> >
>> > =ERROR REPORT==== 22-Mar-2013::00:17:31 ===
>> > why: {diameter_codec,encode,
>> > {{repeated_avp_excessive_arity,'Destination-Host',1,
>> > "server.example.com",'CCR'},
>>
>> This is because Destination-Host is optional in CCR and AVP's are
>> encoded differently in a message record depending on whether or not
>> there can be exactly one occurrence: if so then the field value should
>> be the AVP value, if not then a list of AVP values. That is, your CCR
>> record should have
>>
>> 'Destination-Host' = [DH],
>>
>> in this case.
>>
>> > [{diameter_gen_base_rfc4006_cc,encode_avps,2,
>> >
>> > [{file,"diameter_gen_base_rfc4006_cc.erl"},{line,47}]},
>> >
>> > {diameter_codec,e,2,[{file,"diameter_codec.erl"},{line,112}]},
>> > {diameter_codec,encode,2,
>> > [{file,"diameter_codec.erl"},{line,63}]},
>> > {diameter_traffic,encode,3,
>> > [{file,"diameter_traffic.erl"},{line,1437}]},
>> > {diameter_traffic,send_R,6,
>> > [{file,"diameter_traffic.erl"},{line,1276}]},
>> > {diameter_traffic,'-send_request/4-fun-0-',4,
>> > [{file,"diameter_traffic.erl"},{line,1050}]}]}}
>> > who: <0.180.0>
>> > what: {diameter_codec,encode,
>> > [diameter_gen_base_rfc4006_cc,
>> > {diameter_packet,
>> > {diameter_header,1,undefined,undefined,undefined,
>> >
>> > 1330492780,1330492780,undefined,undefined,undefined,
>> > undefined},
>> > undefined,
>> > {diameter_base_rfc4006_cc_CCR,
>> >
>> > ["client",";","1425429748",";","2",";","nonode@REDACTED"],
>> >
>> > "client.example.com","example.com","example.com",4,
>> >
>> > "Test",1,0,"server.example.com","Me",[],[],[],[],[],[],
>> > [],[],[],[],[],[],[],[],[],[],[],[]},
>> > undefined,[],undefined}]}
>> >
>> > My understanding is that the client callback prepare_request sets the
>> > "Destination-Host" (retrievd via the CER/A done at earilier stage) in
>> > the
>> > CCR message. So I should set it right. But seems I still misunderstand
>> > something. Does the error information "repeated_avp_excessive_arity"
>> > mean "
>> > 0-1 Zero or one instance of the AVP MAY be present in the message. It is
>>
>> Yes, exactly. In your case your DH is being interpreted as list of
>> Destination-Host values, and "excessive arity" is a result of that
>> list having length greater than 1.
>>
>> /Anders, Erlang/OTP
>>
>>
>> > considered an error if there is more than one instance of the AVP"
>> > according
>> > to rfc4006 spec? The erlang error message is not that straightforward,
>> > really confusing newbies:).
>> >
>> > Do you have any hints? (I hope I could provide some ramp up steps for
>> > other
>> > people to learn with erlang diameter library after making it work^_^)
>> >
>> > Many thanks,
>> >
>> > Samuel
>> >
>> >
>> >
>> > On Thu, Mar 21, 2013 at 8:59 AM, Anders Svensson <anders.otp@REDACTED>
>> > wrote:
>> >>
>> >> On Thu, Mar 21, 2013 at 2:55 AM, S X <erlangprogram@REDACTED> wrote:
>> >> > Hello,
>> >> >
>> >> > Sorry, I still have some problems with sending CCR/CCA messages. I
>> >> > didn't
>> >> > quite get how to configure multiple diameter applications though it
>> >> > seems
>> >> > clear when I read the diameter protocol.
>> >> >
>> >> > Based on the sample diameter code, I made the following changes,
>> >> > diameter_gen_base_rfc4006_cc is the dictionary generated with
>> >> > rfc4006_cc.dia:
>> >> > $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ Client
>> >> > $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
>> >> >
>> >> > -define(SVC_NAME, ?MODULE).
>> >> > -define(APP_ALIAS, ?MODULE).
>> >> > -define(CALLBACK_MOD, client_cb).
>> >> > -define(DIAMETER_DICT_CCRA, diameter_gen_base_rfc4006_cc).
>> >> >
>> >> > -define(L, atom_to_list).
>> >> >
>> >> > -define(SERVICE(Name), [{'Origin-Host', ?L(Name) ++ ".example.com"},
>> >> > {'Origin-Realm', "example.com"},
>> >> > {'Vendor-Id', 0},
>> >> > {'Product-Name', "Client"},
>> >> > {'Auth-Application-Id',
>> >> > [?DIAMETER_APP_ID_COMMON]},
>> >> > {application, [{alias, ?APP_ALIAS},
>> >> > {dictionary,
>> >> > ?DIAMETER_DICT_CCRA},
>> >> > {module, ?CALLBACK_MOD}]}]).
>> >> >
>> >> >
>> >> >
>> >> > $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ Server
>> >> > $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
>> >> >
>> >> > -define(DIAMETER_DICT_CCRA, diameter_gen_base_rfc4006_cc).
>> >> >
>> >> > init(State) ->
>> >> > SvcName = ?MODULE,
>> >> > SvcOpts = [{'Origin-Host', atom_to_list(SvcName) ++
>> >> > ".example.com"},
>> >> > {'Origin-Realm', "example.com"},
>> >> > {'Vendor-Id', 193},
>> >> > {'Product-Name', "Server"},
>> >> > {'Auth-Application-Id', [?DIAMETER_APP_ID_COMMON]},
>> >> > {application, [{alias, ?MODULE},
>> >> > {dictionary, ?DIAMETER_DICT_CCRA},
>> >> > {module, server_cb}]}],
>> >> > TransportOpts = [{transport_module, diameter_tcp},
>> >> > {transport_config, [{reuseaddr, true},
>> >> > {ip, {127,0,0,1}}, {port, 3868}]}],
>> >> > diameter:start(),
>> >> > diameter:start_service(SvcName, SvcOpts),
>> >> > diameter:add_transport(SvcName, {listen, TransportOpts}),
>> >> > erlang:display("Set up diameter server completed!"),
>> >> > {ok, State}.
>> >> >
>> >> >
>> >> >
>> >> > I changed the callbacks client_cb and server_cb to handle CCR/CCA
>> >> > messages.
>> >> >
>> >> >
>> >> > However, I got the following errors "app_not_configured". It seems
>> >> > the
>> >> > configuration for applications is incorrect. How should I configure
>> >> > the
>> >> > service properly? My understanding is I want to reuse CER/CEA as
>> >> > default
>> >> > authorization application, but the erlang diameter doesn't explain
>> >> > how
>> >> > to do
>> >> > it. Or my understanding is incorrect at all.
>> >>
>> >> The problem is a mismatch between the application and capabilities
>> >> configuration in your SvcOpts: the 'Auth-Application-Id' tuple
>> >> specifies the Application Id's that are advertised in the outgoing
>> >> CER/CEA (that diameter itself sends) while 'applications' specifies
>> >> corresponding dictionary modules. In your case, advertising the common
>> >> application (0) during capabilities exchange but backing it up with a
>> >> dictionary that implement CC (4) is what causes things to go south.
>> >>
>> >> What you want is something like this:
>> >>
>> >> {'Auth-Application-Id', [0,4]},
>> >> {application, [{alias, cc},
>> >> {dictionary, diameter_gen_base_rfc4006},
>> >> {module, [server_cb, cc]}],
>> >> {application, [{alias, base},
>> >> {dictionary, diameter_gen_base_rfc6733},
>> >> {module, [server_cb, base]}]}
>> >>
>> >> That is, advertise both application with the Auth-Application-Id
>> >> config and configure corresponding dictionaries with 'application'
>> >> config. You might prefer two different callback modules (instead of an
>> >> extra argument) but the point is to match your advertised capabilities
>> >> with your configured dictionaries.
>> >>
>> >> On a side note, you shouldn't use a diameter prefix on your own
>> >> dictionaries, so as not to collide with something diameter does in the
>> >> future.
>> >>
>> >> /Anders, Erlang/OTP
>> >>
>> >> >
>> >> > =ERROR REPORT==== 20-Mar-2013::21:40:50 ===
>> >> > ** Generic server <0.3841.0> terminating
>> >> > ** Last message in was {diameter,
>> >> > {recv,
>> >> >
>> >> > <<1,0,0,124,128,0,1,1,0,0,0,0,101,222,1,72,
>> >> >
>> >> > 101,222,1,72,0,0,1,8,64,0,0,26,99,108,105,
>> >> >
>> >> > 101,110,116,46,101,120,97,109,112,108,101,
>> >> >
>> >> > 46,99,111,109,0,0,0,0,1,40,64,0,0,19,101,
>> >> >
>> >> > 120,97,109,112,108,101,46,99,111,109,0,0,0,
>> >> >
>> >> > 1,1,64,0,0,14,0,1,127,0,0,1,0,0,0,0,1,10,64,
>> >> >
>> >> > 0,0,12,0,0,0,193,0,0,1,13,0,0,0,14,67,108,
>> >> >
>> >> > 105,101,110,116,0,0,0,0,1,2,64,0,0,12,0,0,0,
>> >> > 0>>}}
>> >> > ** When Server state == {state,recv_CER,accept,<0.3840.0>,<0.3842.0>,
>> >> > diameter_gen_base_rfc3588,
>> >> > {diameter_service,<0.50.0>,
>> >> > {diameter_caps,"server.example.com",
>> >> > "example.com",
>> >> > [{127,0,0,1}],
>> >> > 193,"Server",[],[],
>> >> > [0],
>> >> > [],[],[],[],[]},
>> >> > [{diameter_app,server,
>> >> > diameter_gen_base_rfc4006_cc,
>> >> > [server_cb],
>> >> > server,4,false,
>> >> > [{answer_errors,report},
>> >> >
>> >> > {request_errors,answer_3xxx}]}]},
>> >> > false,exit}
>> >> > ** Reason for termination ==
>> >> > ** {{badmatch,{error,{app_not_configured,0}}},
>> >> > [{diameter_peer_fsm,recv_CER,2,
>> >> >
>> >> > [{file,"src/diameter_peer_fsm.erl"},{line,849}]},
>> >> > {diameter_peer_fsm,build_answer,3,
>> >> >
>> >> > [{file,"src/diameter_peer_fsm.erl"},{line,680}]},
>> >> > {diameter_peer_fsm,send_answer,3,
>> >> >
>> >> > [{file,"src/diameter_peer_fsm.erl"},{line,647}]},
>> >> > {diameter_peer_fsm,handle_info,2,
>> >> >
>> >> > [{file,"src/diameter_peer_fsm.erl"},{line,292}]},
>> >> > {gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,607}]},
>> >> >
>> >> > {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]}
>> >> >
>> >> >
>> >> > Could you give me some hints on this issue? The erlang debugger is
>> >> > not
>> >> > easy
>> >> > to use and call stack information is hard to read (when I show the
>> >> > trace
>> >> > window, all the buttons for step/next/continue become invisible). The
>> >> > diameter guidance explains the concept but no clear steps about
>> >> > configuration.
>> >> >
>> >> >
>> >> > Many thanks!
>> >> >
>> >> > Samuel
>> >> >
>> >> >
>> >> >
>> >> > On Tue, Mar 12, 2013 at 12:10 PM, S X <erlangprogram@REDACTED>
>> >> > wrote:
>> >> >>
>> >> >> Hello, Anders & Andre,
>> >> >>
>> >> >> Thanks a lot for your quick responses and suggestions, which help me
>> >> >> start
>> >> >> to exploring Erlang world ^_^
>> >> >>
>> >> >> I was able to generate based on the file rfc4006_cc.dia under the
>> >> >> diameter/examples/dict folders. And understand a bit why and how
>> >> >> Erlang
>> >> >> diameter protocol dictionaries are organized and maintained.
>> >> >>
>> >> >> Many thanks and talk to you later!
>> >> >>
>> >> >> Samuel
>> >> >>
>> >> >>
>> >> >> On Tue, Mar 12, 2013 at 7:44 AM, Anders Svensson
>> >> >> <anders.otp@REDACTED>
>> >> >> wrote:
>> >> >>>
>> >> >>> Btw, there's an RFC 4006 dictionary (and a few more) under
>> >> >>> diameter/examples/dict in the repo.
>> >> >>>
>> >> >>> /Anders, Erlang/OTP
>> >> >>>
>> >> >>> On Tue, Mar 12, 2013 at 10:32 AM, André Graf <andre.graf@REDACTED>
>> >> >>> wrote:
>> >> >>> > Hello S(?)
>> >> >>> >
>> >> >>> > You have to come up with your own .dia file if the message types
>> >> >>> > are
>> >> >>> > not covered in the .dia files provided by Erlang. Your own .dia
>> >> >>> > file
>> >> >>> > will typically include the '@inherits diameter_gen_base_rfc3588'
>> >> >>> > clause which imports the basic avp's from rfc3588. You then have
>> >> >>> > to
>> >> >>> > provide the missing avp's for your CCR/CCA message types, and
>> >> >>> > also
>> >> >>> > define these messages. Thanks to the format of a .dia file it is
>> >> >>> > pretty much copy-pasting from the rfc4006. Once your .dia file is
>> >> >>> > ready, you use diameterc to generate the .erl and .hrl file.
>> >> >>> >
>> >> >>> > Hope that helped!
>> >> >>> >
>> >> >>> > BR/André
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> > On 12 March 2013 04:58, S X <erlangprogram@REDACTED> wrote:
>> >> >>> >> Hello,
>> >> >>> >>
>> >> >>> >> I am new to Erlang and Diameter protocol. Wish someone could
>> >> >>> >> provide
>> >> >>> >> some
>> >> >>> >> suggestions on how to utilize the diameter library properly in
>> >> >>> >> Erlang.
>> >> >>> >>
>> >> >>> >> For example, I want to send/receive some Gx messages, like CCR
>> >> >>> >> (Credit
>> >> >>> >> Control Request), CCA(Credit Control Answer messages. But I
>> >> >>> >> notice
>> >> >>> >> that
>> >> >>> >> there are some predefined messages in erlang diameter library.
>> >> >>> >> As
>> >> >>> >> my
>> >> >>> >> understanding, should use the utility diameterc to generate
>> >> >>> >> erlang
>> >> >>> >> header/source files based on dia files. There are few dia files
>> >> >>> >> under
>> >> >>> >> otp/lib/diameter/src/dict folder, like acct_rfc6733.dia,
>> >> >>> >> base_rfc3588.dia,
>> >> >>> >> relay.dia, base_accounting.dia, base_rfc6733.dia. Those files
>> >> >>> >> don't
>> >> >>> >> have
>> >> >>> >> the definitions for Gx.
>> >> >>> >>
>> >> >>> >> How should I generate or where can I obtain dia files which have
>> >> >>> >> support for
>> >> >>> >> CCR/CCA message format? Are the dia files proprietary or
>> >> >>> >> manufacturer
>> >> >>> >> specific? Can I generate with the 3GPP spec? What are the proper
>> >> >>> >> steps?
>> >> >>> >>
>> >> >>> >> Thanks a lot!
>> >> >>> >>
>> >> >>> >> S
>> >> >>> >>
>> >> >>> >>
>> >> >>> >> _______________________________________________
>> >> >>> >> erlang-questions mailing list
>> >> >>> >> erlang-questions@REDACTED
>> >> >>> >> http://erlang.org/mailman/listinfo/erlang-questions
>> >> >>> >>
>> >> >>> > _______________________________________________
>> >> >>> > erlang-questions mailing list
>> >> >>> > erlang-questions@REDACTED
>> >> >>> > http://erlang.org/mailman/listinfo/erlang-questions
>> >> >>
>> >> >>
>> >> >
>> >
>> >
>
>
More information about the erlang-questions
mailing list