<div dir="ltr"><div><div><div><div>Hi Anders,<br><br></div>I found the reason why the diameter library won't parse the avp with code 1023.<br></div>Since the message pattern is avp_name(Code, Vid),<br></div>After I manually modified the generated dictionary erlang source file by setting the Vid then it can match the pattern and parse.<br>
<br>However, I don't get why the diameterc utility doesn't fill this Vid field while compiling a dictionary.<br></div><div>In the dictionary, I define @vendor 10415 IETF.<br><br></div><div>But why the Vid set as undefined like this in the generated erl file:<br>
</div><div><br>avp_name(1023, undefined) -><br><br></div><div>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.<br>
<br></div><div>Thanks a lot!<br><br></div><div>Samuel<br></div><div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 4, 2014 at 12:15 PM, Samuel X <span dir="ltr"><<a href="mailto:erlangprogram@gmail.com" target="_blank">erlangprogram@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>Hi Anders,<br><br></div>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.<br><br></div>I think I did recompile everything with rebar (clean then compile). But I didn't continue with the rfc4006 dictionary.<br>

<br></div>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.<br><br></div>After splitting all AVPS, other AVPs are parsed ok, except two. One is like this, simple enum data:<br><br>< Avps = [ {diameter_avp,1023,10415,true,false,<br>                        <<0,0,0,0>>,<br>

                        undefined,undefined,undefined,7},<br><br></div><div>I think I defined the dictionary properly. For instance, the generated dictionary erlang file has the 1023 definition:<br><br>avp_name(1023, undefined) -><br>

    {'Bearer-Control-Mode', 'Enumerated'};<br><br>avp_header('Bearer-Control-Mode') -><br>    {1023, 64, undefined};<br><br>{avp_types,<br>      [{"Bearer-Control-Mode", 1023, "Enumerated",<br>

    "M"},<br><br><br></div><div>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<br>{5001,<br>            {diameter_avp,1023,10415,true,false,<br>

                          <<0,0,0,0>>,<br>                          undefined,undefined,undefined,7}},<br><br></div><div>I saw it tried to parse with avp_name(443, undefined) -><br>    {'Subscription-Id', 'Grouped'};<br>

</div><div> <br></div><div><br></div><div>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?<br><br></div><div>Could you please give me some suggestions?<br><br>Thanks a lot!<br><br></div>Samuel<br><br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">
On Mon, Jan 27, 2014 at 4:52 AM, Anders Svensson <span dir="ltr"><<a href="mailto:anders.otp@gmail.com" target="_blank">anders.otp@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Samuel.<br>
<br>
> How are you?<br>
<br>
Still kicking, thanks. :)<br>
<div><br>
> I have a question about modifying diameter dictionary. For example, for<br>
> diameter CCR message, if I want to change "Service-Context-Id" from<br>
> mandatory to non mandatory property so I don't have to fill this property in<br>
> the CCR message, I changed the file rfc4006_cc.dia as following:<br>
><br>
> 1. Service-Context-Id                461    UTF8String    -<br>
> 2. Change from {Service-Context-id} to [Service-Context-Id] and move it<br>
> below {CC-Request-Number} in CCR message definition<br>
<br>
</div>Easy enough to do but if you send a CCR without Service-Context-Id to<br>
a node expecting an RFC 4006 CCR then the request is likely to be<br>
rejected. 1.3.3 of RFC 6733 requires a new Command Code when making<br>
this specific modification.<br>
<div><br>
> Then I used diameterc to generate new erlang files accordingly. The files<br>
> look good and I was able to compile. By the way, I include the diameter<br>
> library source code from OTP release R16B03 into the project, just in order<br>
> to debug the diameter easily.<br>
><br>
> I filled the CCR message as below:<br>
<br>
</div>Just a couple of pointers before getting to the actual issue ...<br>
<br>
>     CCR = #diameter_rfc4006_cc_CCR{<br>
<br>
It's not a good idea to use diameter as a prefix here in case diameter<br>
itself ships with a this dictionary one day.<br>
<div><br>
>         'Session-Id' = diameter:session_id(?L(who)),<br>
>         'Auth-Application-Id' = 16777238,<br>
>         'CC-Request-Type' =<br>
> ?'DIAMETER_RFC4006_CC_CC-REQUEST-TYPE_INITIAL_REQUEST',<br>
<br>
</div>These long macro names are truly hideous, at least if you like to be<br>
able to maintain readable line lengths. (78 characters in my book.) At<br>
best I'd redefine those I want to use.<br>
<br>
Eg.  -define(INITIAL, ?'DIAMETER_RFC4006_CC_CC-REQUEST-TYPE_INITIAL_REQUEST').<br>
<div><br>
>         'CC-Request-Number' = 0<br>
>         },<br>
>     diameter:call(Name, ?APP_CCR_ALIAS, CCR, []).<br>
><br>
> When I run from the erlang shell R16B03, I got the encoding error like this:<br>
><br>
>     why: {diameter_codec,encode,<br>
>              {{mandatory_avp_missing,'CC-Request-Type','CCR'},<br>
<br>
</div>I suspect you haven't recompiled your source file after modifying the<br>
dictionary. Records are just tuples, and fields in the record notation<br>
are mapped to tuple indices using the record definition known to the<br>
source in question. If the source creating the record above has the<br>
"old" definition then the fields set as CC-Request-Type and<br>
CC-Request-Number will be in the positions in which the "new"<br>
dictionary module expects to find CC-Request-Number and<br>
Service-Context-Id, leading to the "missing" CC-Request-Type error.<br>
<br>
That is, you need to recompile any source that includes a generated<br>
hrl, in addition to loading the new dictionary module.<br>
<div><div><br>
>               [{diameter_gen_rfc4006_cc,encode_avps,2,<br>
>                    [{file,<br>
><br>
> "/usr/lib/erlang/lib/diameter-1.5/include/diameter_gen.hrl"},<br>
>                     {line,59}]},<br>
>                {diameter_codec,e,2,<br>
>                    [{file,"src/diameter_codec.erl"},{line,120}]},<br>
>                {diameter_codec,encode,2,<br>
>                    [{file,"src/diameter_codec.erl"},{line,71}]},<br>
>                {diameter_traffic,encode,3,<br>
>                    [{file,"src/diameter_traffic.erl"},{line,1481}]},<br>
>                {diameter_traffic,send_R,6,<br>
>                    [{file,"src/diameter_traffic.erl"},{line,1320}]},<br>
>                {diameter_traffic,'-send_request/4-fun-0-',6,<br>
>                    [{file,"src/diameter_traffic.erl"},{line,1094}]}]}}<br>
>     who: <0.62.0><br>
>     what: {diameter_codec,encode,<br>
>               [diameter_gen_rfc4006_cc,<br>
>                {diameter_packet,<br>
>                    {diameter_header,1,undefined,undefined,undefined,<br>
>                        398339147,398339147,undefined,undefined,undefined,<br>
>                        undefined},<br>
>                    undefined,<br>
>                    {diameter_rfc4006_cc_CCR,<br>
>                        ["who",";","1452024187",";","1",";","nonode@nohost"],<br>
>                        "centos","<a href="http://example.com" target="_blank">example.com</a>","<a href="http://example.com" target="_blank">example.com</a>",16777238,<br>
>                        undefined,1,0,<br>
>                        ["centos"],<br>
><br>
><br>
> [],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],<br>
>                        []},<br>
>                    undefined,[],undefined}]}<br>
> {error,encode}<br>
><br>
> I don't really understand why getting this error or the error information is<br>
> a little bit confusing me.<br>
> Am I doing right to modify the dictionary file? What is the proper way to do<br>
> that?<br>
<br>
</div></div>Nothing wrong with the modification, aside from the fact that you're<br>
straying from RFC 4006 Credit-Control as I mentioned above.<br>
<div><br>
> What is best way of debugging the diameter library? Can you give me some<br>
> hints?<br>
<br>
</div>In this case it's just confusion over record definitions I think, and<br>
these are always confusing until you realize that different code might<br>
have different record definitions. You can see the record being<br>
encoded by tracing on diameter_codec:encode/2 for example, which would<br>
show the unexpected positions of CC-Request-Type and CC-Request-Number<br>
relative to your dictionary definition.<br>
<br>
/Anders, Erlang/OTP<br>
<div><div><br>
<br>
<br>
><br>
> Thanks a lot!<br>
><br>
> Samuel<br>
><br>
><br>
> On Sat, Mar 23, 2013 at 7:11 AM, Anders Svensson <<a href="mailto:anders.otp@gmail.com" target="_blank">anders.otp@gmail.com</a>><br>
> wrote:<br>
>><br>
>> On Fri, Mar 22, 2013 at 7:52 PM, S X <<a href="mailto:erlangprogram@gmail.com" target="_blank">erlangprogram@gmail.com</a>> wrote:<br>
>> > Hi Anders,<br>
>> ><br>
>> > Sorry, I think I understand now. You told me the solution. Just use '[<br>
>> > ]'.<br>
>> ><br>
>> > Anyhow, many thanks!<br>
>> ><br>
>> > By the way, since 3588 is obsolete, can I use 6733 while compile other<br>
>> > dictionaries?<br>
>><br>
>> Yes. /Anders<br>
>><br>
>><br>
>> ><br>
>> > Thanks!<br>
>> ><br>
>> > Samuel<br>
>> ><br>
>> ><br>
>> > On Fri, Mar 22, 2013 at 2:46 PM, S X <<a href="mailto:erlangprogram@gmail.com" target="_blank">erlangprogram@gmail.com</a>> wrote:<br>
>> >><br>
>> >> Hi Anders,<br>
>> >><br>
>> >> Thanks for your quick response. But I still don't get why the DH is<br>
>> >> being<br>
>> >> interpreted as a list of Destination-Host values ( Is it because the<br>
>> >> define<br>
>> >> "avp_arity('CCR', 'Destination-Host') -> {0, 1};").<br>
>> >><br>
>> >> And if it is treated as a list, how come it has a length greater than<br>
>> >> 1, I<br>
>> >> just set it once in prepare_request.<br>
>> >><br>
>> >> What should I do to correct it? Or which document should I read more<br>
>> >> carefully to understand this properly?<br>
>> >><br>
>> >> Thanks a lot!<br>
>> >><br>
>> >> Samuel<br>
>> >><br>
>> >><br>
>> >> On Fri, Mar 22, 2013 at 1:27 PM, Anders Svensson <<a href="mailto:anders.otp@gmail.com" target="_blank">anders.otp@gmail.com</a>><br>
>> >> wrote:<br>
>> >>><br>
>> >>> Hi Samuel<br>
>> >>><br>
>> >>> On Fri, Mar 22, 2013 at 5:55 PM, S X <<a href="mailto:erlangprogram@gmail.com" target="_blank">erlangprogram@gmail.com</a>> wrote:<br>
>> >>> > Thanks a lot, Anders,<br>
>> >>> ><br>
>> >>> > I think I overlooked what the meaning of the configurable ID tag (4)<br>
>> >>> > in<br>
>> >>> > the<br>
>> >>> > dia file is , which is supposed to be the important application ID<br>
>> >>> > to<br>
>> >>> > be<br>
>> >>> > used in the configuration. Your suggestion about the prefix is also<br>
>> >>> > right.<br>
>> >>> > But now I am just learning erlang diameter library.<br>
>> >>> ><br>
>> >>> > I just try to follow the sample RAR message style, and am still<br>
>> >>> > having<br>
>> >>> > issue<br>
>> >>> > with sending CCR message. The client configuration now is:<br>
>> >>> ><br>
>> >>> > -define(SERVICE(Name), [{'Origin-Host', ?L(Name) ++ ".<a href="http://example.com" target="_blank">example.com</a>"},<br>
>> >>> >                         {'Origin-Realm', "<a href="http://example.com" target="_blank">example.com</a>"},<br>
>> >>> >                         {'Vendor-Id', 193},<br>
>> >>> >                         {'Product-Name', "Client"},<br>
>> >>> >                         {'Auth-Application-Id',<br>
>> >>> > [?DIAMETER_APP_ID_CCRA]},<br>
>> >>> >                         {application, [{alias, ?APP_CCR_ALIAS},<br>
>> >>> >                                        {dictionary,<br>
>> >>> > ?DIAMETER_DICT_CCRA},<br>
>> >>> >                                        {module, client_cb_ccra}]}]).<br>
>> >>> ><br>
>> >>> > Try to send CCR message:<br>
>> >>> ><br>
>> >>> > call(Name) -><br>
>> >>> >     SId = diameter:session_id(?L(Name)),<br>
>> >>> >     CCR = #diameter_base_rfc4006_cc_CCR{<br>
>> >>> >         'Session-Id' = SId,<br>
>> >>> >         'Service-Context-Id' = "Test",<br>
>> >>> >         'CC-Request-Type' =<br>
>> >>> > ?'DIAMETER_BASE_RFC4006_CC_CC-REQUEST-TYPE_INITIAL_REQUEST',<br>
>> >>> >         'CC-Request-Number' = 0,<br>
>> >>> >         'Auth-Application-Id' = ?DIAMETER_APP_ID_CCRA,<br>
>> >>> >         'User-Name' = "Me"},<br>
>> >>> >     diameter:call(Name, ?APP_CCR_ALIAS, CCR, []).<br>
>> >>> ><br>
>> >>> ><br>
>> >>> > In the client callback module:<br>
>> >>> ><br>
>> >>> > prepare_request(#diameter_packet{msg = Rec}, _, {_, Caps}) -><br>
>> >>> >     #diameter_caps{origin_host = {OH, DH},<br>
>> >>> >                    origin_realm = {OR, DR}}<br>
>> >>> >         = Caps,<br>
>> >>> ><br>
>> >>> >     {send, Rec#diameter_base_rfc4006_cc_CCR{'Origin-Host' = OH,<br>
>> >>> >                                  'Origin-Realm' = OR,<br>
>> >>> >                                  'Destination-Host' = DH,<br>
>> >>> >                                  'Destination-Realm' = DR}}.<br>
>> >>> ><br>
>> >>> > I got the error about AVP property:<br>
>> >>> ><br>
>> >>> > =ERROR REPORT==== 22-Mar-2013::00:17:31 ===<br>
>> >>> >     why: {diameter_codec,encode,<br>
>> >>> >              {{repeated_avp_excessive_arity,'Destination-Host',1,<br>
>> >>> >                   "<a href="http://server.example.com" target="_blank">server.example.com</a>",'CCR'},<br>
>> >>><br>
>> >>> This is because Destination-Host is optional in CCR and AVP's are<br>
>> >>> encoded differently in a message record depending on whether or not<br>
>> >>> there can be exactly one occurrence: if so then the field value should<br>
>> >>> be the AVP value, if not then a list of AVP values. That is, your CCR<br>
>> >>> record should have<br>
>> >>><br>
>> >>>    'Destination-Host' = [DH],<br>
>> >>><br>
>> >>> in this case.<br>
>> >>><br>
>> >>> >               [{diameter_gen_base_rfc4006_cc,encode_avps,2,<br>
>> >>> ><br>
>> >>> > [{file,"diameter_gen_base_rfc4006_cc.erl"},{line,47}]},<br>
>> >>> ><br>
>> >>> > {diameter_codec,e,2,[{file,"diameter_codec.erl"},{line,112}]},<br>
>> >>> >                {diameter_codec,encode,2,<br>
>> >>> >                    [{file,"diameter_codec.erl"},{line,63}]},<br>
>> >>> >                {diameter_traffic,encode,3,<br>
>> >>> >                    [{file,"diameter_traffic.erl"},{line,1437}]},<br>
>> >>> >                {diameter_traffic,send_R,6,<br>
>> >>> >                    [{file,"diameter_traffic.erl"},{line,1276}]},<br>
>> >>> >                {diameter_traffic,'-send_request/4-fun-0-',4,<br>
>> >>> >                    [{file,"diameter_traffic.erl"},{line,1050}]}]}}<br>
>> >>> >     who: <0.180.0><br>
>> >>> >     what: {diameter_codec,encode,<br>
>> >>> >               [diameter_gen_base_rfc4006_cc,<br>
>> >>> >                {diameter_packet,<br>
>> >>> >                    {diameter_header,1,undefined,undefined,undefined,<br>
>> >>> ><br>
>> >>> > 1330492780,1330492780,undefined,undefined,undefined,<br>
>> >>> >                        undefined},<br>
>> >>> >                    undefined,<br>
>> >>> >                    {diameter_base_rfc4006_cc_CCR,<br>
>> >>> ><br>
>> >>> > ["client",";","1425429748",";","2",";","nonode@nohost"],<br>
>> >>> ><br>
>> >>> > "<a href="http://client.example.com" target="_blank">client.example.com</a>","<a href="http://example.com" target="_blank">example.com</a>","<a href="http://example.com" target="_blank">example.com</a>",4,<br>


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