@miconda almost correct - your scenario would lead to the same error, but it is a scenario with ims_qos module. The **t_suspend()** is not explicitly called, but it happens implicitly within the function $var(aarret) = **Rx_AAR**("**MT_aar_reply**","term","",-1); switch ($var(aarret)) { case 0: #suspend was successful and we must break exit;
The module sends a DIAMETER AAR message to some peer while the 200 OK is suspended, but the DIAMETER response (AAA) indicates a failure.
The 488 is created by **dlg_terminate()** from ims_dialog module. route[**MT_aar_reply**] { #this is async so to know status we have to check the reply avp switch ($avp(s:aar_return_code)) { case 1: xlog("L_DBG", "Diameter: Orig AAR success on media authorization\n"); break; default: #comment this if you want to allow even if Rx fails if(dlg_get("$avp(CALLID_CUSTOM_AVP)","$avp(FTAG_CUSTOM_AVP)","$avp(TTAG_CUSTOM_AVP)")){ **dlg_terminate("all", "Sorry no QoS available")**; usleep("100000"); #prm2272 exit; } } }
This leads to the situation that the 488 and the 200 OK are sent nearly at the same instance of time (only a few ms distance) and hence the ACK(488) is received AFTER the 200 OK is sent.
I can send you per e-mail a powerpoint from our analysis, OK?