<div dir="ltr">Hi René,<div><br></div><div>On 21 June 2018 at 15:31, René Veyland Mobile <span dir="ltr"><<a href="mailto:rveyland2@gmail.com" target="_blank">rveyland2@gmail.com</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div lang="FR"><div class="gmail-m_-1781236801656516039WordSection1"><p class="MsoNormal">Dear Erlang Community,</p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">I’m a beginner in Erlang, and i have a question on diameter stack behavior.</p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">I ‘m working on a sw acting as diameter peer server with a S6A app.</p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">I have noticed that when an diameter request is received with an error (for example an additional AVP not supported by dict), even if the packet provided in return value of the handle_request call back contains a valid answer with an AVP result-code=Success and header with errors=[] and is_error=false, the diameter stack return to client peer a diameter packet with an error 5001 (unsupported_avp) which is corresponding to the initial error found on request decoding (and not the answer sent in {reply, Reply}.</p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">If the initial diameter request is valid verus dict, then the answer provided by callback is sent back to client peer as expected.</p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">I would like to confirm that it is due to a bug from my sw (most probably <span style="font-family:"Segoe UI Emoji",sans-serif">☹</span> ) </p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">So I have some questions :</p><ul style="margin-top:0cm" type="disc"><li class="MsoNormal">Is it a normal of diameter stack behavior </li><ul style="margin-top:0cm" type="circle"><li class="MsoNormal"> if yes how to avoid/bypass it ? (how to send a valid answer even if request is seen in error)</li></ul></ul></div></div></blockquote><div><br></div><div>This code works for me in the handle_request/3 callback:</div><div><br></div><div><div><font face="monospace, monospace">handle_request(#diameter_packet{msg = Req, transport_data = TD}, _SvcName, {_, Caps})</font></div><div><font face="monospace, monospace">  when is_record(Req, 'diameter_gx_CCR') -></font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">    #diameter_caps{origin_host = {OH,_},</font></div><div><font face="monospace, monospace">                   origin_realm = {OR,_}}                = Caps,</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">    #'diameter_gx_CCR'{'Session-Id'          = Id,</font></div><div><font face="monospace, monospace">                       'Auth-Application-Id' = AuthAppId,</font></div><div><font face="monospace, monospace">                       'CC-Request-Type'     = ReqType,</font></div><div><font face="monospace, monospace">                       'CC-Request-Number'   = ReqNum}  = Req,</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">    PolicyMap = get_policy(Req),</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">    CCA   = #'diameter_gx_CCA'{'Result-Code'                      = 2001,</font></div><div><font face="monospace, monospace">                               'Auth-Application-Id'              = AuthAppId,</font></div><div><font face="monospace, monospace">                               'Origin-Host'                      = OH,</font></div><div><font face="monospace, monospace">                               'Origin-Realm'                     = OR,</font></div><div><font face="monospace, monospace">                               'Session-Id'                       = Id,</font></div><div><font face="monospace, monospace">                               'CC-Request-Type'                  = ReqType,</font></div><div><font face="monospace, monospace">                               'CC-Request-Number'                = ReqNum,</font></div><div><font face="monospace, monospace">                               'Supported-Features'               = get_supported_features(),</font></div><div><font face="monospace, monospace">                               'QoS-Information'                  = get_qos(PolicyMap),</font></div><div><font face="monospace, monospace">                               'Charging-Rule-Install'            = get_crbn(PolicyMap)</font></div><div><font face="monospace, monospace">                              },</font></div><div><font face="monospace, monospace">    ReplyPacket = #diameter_packet{msg = CCA,</font></div><div><font face="monospace, monospace">                                   header = #diameter_header{},</font></div><div><font face="monospace, monospace">                                   errors = false,</font></div><div><font face="monospace, monospace">                                   transport_data = TD},</font></div><div><font face="monospace, monospace">    {reply, ReplyPacket};</font></div></div><div><br></div><div>Also, when initialising the service, I tend to use the {strict_mbit, false} option this is a frequent annoyance.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div lang="FR"><div class="gmail-m_-1781236801656516039WordSection1"><ul style="margin-top:0cm" type="disc"><ul style="margin-top:0cm" type="circle"><li class="MsoNormal">More globally: What is the simplest way to debug diameter stack in order to verify that data sent back by callback handler are « as expected » ?<br></li></ul></ul></div></div></blockquote><div>I've also found debugging diameter applications to be quite hard. I've had to resort to using dbg to trace calls in the diameter_codec module to figure out what was going wrong.</div><div><br></div><div>regards,</div><div>Chandru</div></div></div></div>