[erlang-questions] erlang diameter dictionary

S X erlangprogram@REDACTED
Fri Mar 22 19:46:54 CET 2013


Hi Anders,

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};").

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.

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
> >> >>
> >> >>
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130322/db3e6a90/attachment.htm>


More information about the erlang-questions mailing list