issue with using irules to send snmp trap

Dear experts, we met a issue when use irules to send snmp trap by check the sip response. anyone have the same experience before ? [Background] We configured iRule setting as below in order to raise SNMP trap alarm.

Purpose of the iRule: Check SIP response code and if the code is greater than 300,

SNMP trap is invoked, except for code:487.

++++++++++++iRules+++++++++++ when SIP_RESPONSE { Look for the current date of when the irule was processed set current_year [clock format [clock seconds] -format {%Y} ] set current_mon [clock format [clock seconds] -format {%b} ] set current_day [clock format [clock seconds] -format {%d} ] set current_time [clock format [clock seconds] -format {%T} ]

if { ([SIP::response code] != 487) && ([SIP::response code] >= 300) }{ log local0. " Detected SIP Error Response, $current_year $current_mon $current_day $current_time, [SIP::response code], [SIP::response phrase], [SIP::from] " } } +++++++++++++++++++++++++++++ +++++++user_alert.conf+++++++ alert BIGIP_EJUNAWA_FOUND_4xx_RESPONSE_TEST "Detected SIP Error Response" { snmptrap OID=".1.3.6.1.4.1.3375.1.1.110.201"; lcdwarn description="Detected SIP Error Response" priority="4" } +++++++++++++++++++++++++++++

[Problem description] We have performed testing for alarm detection and found that in particular case, the SNMP trap is not invoked even though the response code is greater than 300. We have narrowed down the suspected scenario/part and confirmed what makes difference is::: whether Reason header exists or not. Reason header => Reason: Q.850 ;cause=17;x-source=2

[Test we performed] Test1. Send a packet of SIP::response code (486,403) WITH Reason header Result. SNMP trap is invoked and alarm is raised expectedly

Test2. Send a packet of SIP::response code (486,403) WITHOUT Reason header Result. SNMP trap is not invoked and alarm is not raised against expection

[Questions]

Could you confirm if it's necessary for a packet to include "reason header" in order to send SNMP trap by iRule system?
If it's not the above case, could you take a look and investigate why SNMP trap is not sent?

thanks in advance !