[OTP 19.3] [Diameter 1.12.2] Handle_request with error: reply not taken into account

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[OTP 19.3] [Diameter 1.12.2] Handle_request with error: reply not taken into account

René Veyland Mobile

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
    •  if yes how to avoid/bypass it ? (how to send a valid answer even if request is seen in error)
    • If not : on which criteria a predefined answer is sent back to the transport layer instead of the application’s callback one ?
  • 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 » ?

 

Thx a lot by advance for your support.

 

BR

 

René Veyland

 

Provenance : Courrier pour Windows 10

 


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: [OTP 19.3] [Diameter 1.12.2] Handle_request with error: reply not taken into account

Chandru-4
Hi René,

On 21 June 2018 at 15:31, René Veyland Mobile <[hidden email]> 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
    •  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.

    • 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

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: [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 : [hidden email]
Envoyé le :jeudi 21 juin 2018 18:32
À : [hidden email]
Cc : [hidden email]
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 <[hidden email]> 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
    •  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.

 

    • 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

 


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions