[erlang-questions] erlang diameter dictionary
Samuel X
erlangprogram@REDACTED
Thu Feb 6 05:16:51 CET 2014
Hi Anders,
I found the answer in the diameter documentation. Now I feel I should know
how to use the library after debugging it. The main reason for those naive
questions is because I am not familiar with the diameter protocol.
Thanks a lot for your help and time!
Samuel
On Wed, Feb 5, 2014 at 9:56 PM, Samuel X <erlangprogram@REDACTED> wrote:
> Hi Anders,
>
> I found the reason why the diameter library won't parse the avp with code
> 1023.
> Since the message pattern is avp_name(Code, Vid),
> After I manually modified the generated dictionary erlang source file by
> setting the Vid then it can match the pattern and parse.
>
> However, I don't get why the diameterc utility doesn't fill this Vid field
> while compiling a dictionary.
> In the dictionary, I define @vendor 10415 IETF.
>
> But why the Vid set as undefined like this in the generated erl file:
>
> avp_name(1023, undefined) ->
>
> Can you give me some suggestions how to set this properly in a dictionary
> file to get the proper avp pattern? Or the diameter library document has
> the steps.
>
> Thanks a lot!
>
> Samuel
>
>
>
> On Tue, Feb 4, 2014 at 12:15 PM, Samuel X <erlangprogram@REDACTED> wrote:
>
>> Hi Anders,
>>
>> Thanks for your reply, Your suggestions are valuable. I am still playing
>> with some trial code. So need to worry about name space convention for now.
>>
>> I think I did recompile everything with rebar (clean then compile). But I
>> didn't continue with the rfc4006 dictionary.
>>
>> I redefined my CCR/CCA messages and received something back from peer
>> with success code 2001. However I got decoding error. I debugged the
>> decoding process. Something makes me confused.
>>
>> After splitting all AVPS, other AVPs are parsed ok, except two. One is
>> like this, simple enum data:
>>
>> < Avps = [ {diameter_avp,1023,10415,true,false,
>> <<0,0,0,0>>,
>> undefined,undefined,undefined,7},
>>
>> I think I defined the dictionary properly. For instance, the generated
>> dictionary erlang file has the 1023 definition:
>>
>> avp_name(1023, undefined) ->
>> {'Bearer-Control-Mode', 'Enumerated'};
>>
>> avp_header('Bearer-Control-Mode') ->
>> {1023, 64, undefined};
>>
>> {avp_types,
>> [{"Bearer-Control-Mode", 1023, "Enumerated",
>> "M"},
>>
>>
>> But when I debug the Mod:decode_avps step by step, I don't see it try to
>> step into the proper avp_name mapping and throw the error
>> {5001,
>> {diameter_avp,1023,10415,true,false,
>> <<0,0,0,0>>,
>> undefined,undefined,undefined,7}},
>>
>> I saw it tried to parse with avp_name(443, undefined) ->
>> {'Subscription-Id', 'Grouped'};
>>
>>
>> Do I misunderstand anything in diameter library? What I did wrong to
>> cause this? How should I better understand the encode/decode process in
>> diameter library?
>>
>> Could you please give me some suggestions?
>>
>> Thanks a lot!
>>
>> Samuel
>>
>>
>>
>> On Mon, Jan 27, 2014 at 4:52 AM, Anders Svensson <anders.otp@REDACTED>wrote:
>>
>>> 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
>>> >> >>> >> >>
>>> >> >>> >> >>
>>> >> >>> >> >
>>> >> >>> >
>>> >> >>> >
>>> >> >>
>>> >> >>
>>> >> >
>>> >
>>> >
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140205/8ef753a0/attachment.htm>
More information about the erlang-questions
mailing list