[erlang-questions] erlang diameter dictionary
Anders Svensson
anders.otp@REDACTED
Mon Jan 27 10:52:48 CET 2014
Hi Samuel.
> How are you?
Still kicking, thanks. :)
> I have a question about modifying diameter dictionary. For example, for
> diameter CCR message, if I want to change "Service-Context-Id" from
> mandatory to non mandatory property so I don't have to fill this property in
> the CCR message, I changed the file rfc4006_cc.dia as following:
>
> 1. Service-Context-Id 461 UTF8String -
> 2. Change from {Service-Context-id} to [Service-Context-Id] and move it
> below {CC-Request-Number} in CCR message definition
Easy enough to do but if you send a CCR without Service-Context-Id to
a node expecting an RFC 4006 CCR then the request is likely to be
rejected. 1.3.3 of RFC 6733 requires a new Command Code when making
this specific modification.
> Then I used diameterc to generate new erlang files accordingly. The files
> look good and I was able to compile. By the way, I include the diameter
> library source code from OTP release R16B03 into the project, just in order
> to debug the diameter easily.
>
> I filled the CCR message as below:
Just a couple of pointers before getting to the actual issue ...
> CCR = #diameter_rfc4006_cc_CCR{
It's not a good idea to use diameter as a prefix here in case diameter
itself ships with a this dictionary one day.
> 'Session-Id' = diameter:session_id(?L(who)),
> 'Auth-Application-Id' = 16777238,
> 'CC-Request-Type' =
> ?'DIAMETER_RFC4006_CC_CC-REQUEST-TYPE_INITIAL_REQUEST',
These long macro names are truly hideous, at least if you like to be
able to maintain readable line lengths. (78 characters in my book.) At
best I'd redefine those I want to use.
Eg. -define(INITIAL, ?'DIAMETER_RFC4006_CC_CC-REQUEST-TYPE_INITIAL_REQUEST').
> 'CC-Request-Number' = 0
> },
> diameter:call(Name, ?APP_CCR_ALIAS, CCR, []).
>
> When I run from the erlang shell R16B03, I got the encoding error like this:
>
> why: {diameter_codec,encode,
> {{mandatory_avp_missing,'CC-Request-Type','CCR'},
I suspect you haven't recompiled your source file after modifying the
dictionary. Records are just tuples, and fields in the record notation
are mapped to tuple indices using the record definition known to the
source in question. If the source creating the record above has the
"old" definition then the fields set as CC-Request-Type and
CC-Request-Number will be in the positions in which the "new"
dictionary module expects to find CC-Request-Number and
Service-Context-Id, leading to the "missing" CC-Request-Type error.
That is, you need to recompile any source that includes a generated
hrl, in addition to loading the new dictionary module.
> [{diameter_gen_rfc4006_cc,encode_avps,2,
> [{file,
>
> "/usr/lib/erlang/lib/diameter-1.5/include/diameter_gen.hrl"},
> {line,59}]},
> {diameter_codec,e,2,
> [{file,"src/diameter_codec.erl"},{line,120}]},
> {diameter_codec,encode,2,
> [{file,"src/diameter_codec.erl"},{line,71}]},
> {diameter_traffic,encode,3,
> [{file,"src/diameter_traffic.erl"},{line,1481}]},
> {diameter_traffic,send_R,6,
> [{file,"src/diameter_traffic.erl"},{line,1320}]},
> {diameter_traffic,'-send_request/4-fun-0-',6,
> [{file,"src/diameter_traffic.erl"},{line,1094}]}]}}
> who: <0.62.0>
> what: {diameter_codec,encode,
> [diameter_gen_rfc4006_cc,
> {diameter_packet,
> {diameter_header,1,undefined,undefined,undefined,
> 398339147,398339147,undefined,undefined,undefined,
> undefined},
> undefined,
> {diameter_rfc4006_cc_CCR,
> ["who",";","1452024187",";","1",";","nonode@REDACTED"],
> "centos","example.com","example.com",16777238,
> undefined,1,0,
> ["centos"],
>
>
> [],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],
> []},
> undefined,[],undefined}]}
> {error,encode}
>
> I don't really understand why getting this error or the error information is
> a little bit confusing me.
> Am I doing right to modify the dictionary file? What is the proper way to do
> that?
Nothing wrong with the modification, aside from the fact that you're
straying from RFC 4006 Credit-Control as I mentioned above.
> What is best way of debugging the diameter library? Can you give me some
> hints?
In this case it's just confusion over record definitions I think, and
these are always confusing until you realize that different code might
have different record definitions. You can see the record being
encoded by tracing on diameter_codec:encode/2 for example, which would
show the unexpected positions of CC-Request-Type and CC-Request-Number
relative to your dictionary definition.
/Anders, Erlang/OTP
>
> Thanks a lot!
>
> Samuel
>
>
> On Sat, Mar 23, 2013 at 7:11 AM, Anders Svensson <anders.otp@REDACTED>
> wrote:
>>
>> On Fri, Mar 22, 2013 at 7:52 PM, S X <erlangprogram@REDACTED> wrote:
>> > Hi Anders,
>> >
>> > Sorry, I think I understand now. You told me the solution. Just use '[
>> > ]'.
>> >
>> > Anyhow, many thanks!
>> >
>> > By the way, since 3588 is obsolete, can I use 6733 while compile other
>> > dictionaries?
>>
>> Yes. /Anders
>>
>>
>> >
>> > Thanks!
>> >
>> > Samuel
>> >
>> >
>> > On Fri, Mar 22, 2013 at 2:46 PM, S X <erlangprogram@REDACTED> wrote:
>> >>
>> >> 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
>> >>> >> >>
>> >>> >> >>
>> >>> >> >
>> >>> >
>> >>> >
>> >>
>> >>
>> >
>
>
More information about the erlang-questions
mailing list