@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?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/2590#issuecomment-754504173_______________________________________________
Kamailio (SER) - Development Mailing List
[email protected]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
