[erlang-questions] [OTP 19.3] [Diameter 1.12.2] Handle_requestwith error: reply not taken into account

[René Veyland Mobile]

Hi Chandru

Thx for answer. I will crosscheck my sw again even if very similar. The issue is only visible if recevied diameter packet as an error raised.

For debuging, i will try your method too.

Br

René

Provenance : Courrier pour Windows 10

De : Chandru
Envoyé le :jeudi 21 juin 2018 18:32
À : René Veyland Mobile
Cc : erlang-questions@REDACTED
Objet :Re: [erlang-questions] [OTP 19.3] [Diameter 1.12.2] Handle_requestwith error: reply not taken into account

Hi René,

On 21 June 2018 at 15:31, René Veyland Mobile <rveyland2@REDACTED> wrote:
Dear Erlang Community,
 
I’m a beginner in Erlang, and i have a question on diameter stack behavior.
 
I ‘m working on a sw acting as diameter peer server with a S6A app.
 
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}.
 
If the initial diameter request is valid verus dict, then the answer provided by callback is sent back to client peer as expected.
 
I would like to confirm that it is due to a bug from my sw (most probably ☹ ) 
 
So I have some questions :
• Is it a normal of diameter stack behavior 
o  if yes how to avoid/bypass it ? (how to send a valid answer even if request is seen in error)

This code works for me in the handle_request/3 callback:

handle_request(#diameter_packet{msg = Req, transport_data = TD}, _SvcName, {_, Caps})
  when is_record(Req, 'diameter_gx_CCR') ->

    #diameter_caps{origin_host = {OH,_},
                   origin_realm = {OR,_}}                = Caps,

    #'diameter_gx_CCR'{'Session-Id'          = Id,
                       'Auth-Application-Id' = AuthAppId,
                       'CC-Request-Type'     = ReqType,
                       'CC-Request-Number'   = ReqNum}  = Req,

    PolicyMap = get_policy(Req),

    CCA   = #'diameter_gx_CCA'{'Result-Code'                      = 2001,
                               'Auth-Application-Id'              = AuthAppId,
                               'Origin-Host'                      = OH,
                               'Origin-Realm'                     = OR,
                               'Session-Id'                       = Id,
                               'CC-Request-Type'                  = ReqType,
                               'CC-Request-Number'                = ReqNum,
                               'Supported-Features'               = get_supported_features(),
                               'QoS-Information'                  = get_qos(PolicyMap),
                               'Charging-Rule-Install'            = get_crbn(PolicyMap)
                              },
    ReplyPacket = #diameter_packet{msg = CCA,
                                   header = #diameter_header{},
                                   errors = false,
                                   transport_data = TD},
    {reply, ReplyPacket};

Also, when initialising the service, I tend to use the {strict_mbit, false} option this is a frequent annoyance.

o 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 » ?
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.

regards,
Chandru

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180622/b822731e/attachment.htm>