<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div>Hi all,</div>
<div><br>
</div>
<div>Remember this question from 23.1.</div>
<div><br>
</div>
<div>It's solved now, thanks for help:-)</div>
<div><br>
</div>
<div>All the best</div>
<div>Christoph </div>
<div><br>
</div>
<div id="composer_signature">
<div style="font-size:85%;color:#575757" dir="auto">Von meinem Samsung Galaxy Smartphone gesendet.</div>
</div>
<div><br>
</div>
<div style="font-size:100%;color:#000000"><!-- originalMessage -->
<div>-------- Ursprüngliche Nachricht --------</div>
<div>Von: Valentin Christoph <Christoph.Valentin@kapsch.net> </div>
<div>Datum: 23.01.19 15:06 (GMT+01:00) </div>
<div>An: sr-users@lists.sip-router.org </div>
<div>Cc: Scherney Theodor <Theodor.Scherney@kapsch.net>, Onic Roman <Roman.Onic@kapsch.net>
</div>
<div>Betreff: [SR-Users] Problem at Rx Interface - kamailio P-CSCF 5.1.6 </div>
<div><br>
</div>
</div>
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US">Hi all,</span></p>
<p class="MsoNormal"><span lang="EN-US"> </span></p>
<p class="MsoNormal"><span lang="EN-US">We are using kamailio 5.1.6, configured as P-CSCF, facing following problem. Please indicate, if you need further information – e.g. I could provide a tshark trace.</span></p>
<p class="MsoNormal"><span lang="EN-US"> </span></p>
<p class="MsoNormal"><span lang="EN-US">If during call setup (by simulated UAs) at the terminating P-CSCF the simulated PCRF rejects the Diameter AAR message, then the kamailio P-CSCF runs into a questionable behaviour.</span></p>
<p class="MsoNormal"><span lang="EN-US"> </span></p>
<p class="MsoNormal"><span lang="EN-US">By calling the Rx_AAR() function in configuration, the processing of the 200 OK is suspended (by the ims_qos module) and then resumed with the receipt of the AAA message.</span></p>
<p class="MsoNormal"><span lang="EN-US"> </span></p>
<p class="MsoNormal"><span lang="EN-US">Now the ims_dialog module is called with the dlg_terminate(“all”, “reason”) function, but the 200 OK has not yet been sent. The ims_dialog sends CANCEL downstream and 488 upstream. However, the 200 OK is sent additionally.
We would rather have expected the ims_dialog module should send BYE in both directions.</span></p>
<p class="MsoNormal"><span lang="EN-US"> </span></p>
<p class="MsoNormal"><span lang="EN-US">When we respond the CANCEL with 481 Call/Transaction does not exist (which we MUST according to RFC 3261), then we would expect the ims_dialog module at least now to react with BYE in both directions.</span></p>
<p class="MsoNormal"><span lang="EN-US"> </span></p>
<p class="MsoNormal"><span lang="EN-US">Could you help? What’s our misunderstanding? How could we proceed to get this issue fixed?</span></p>
<p class="MsoNormal"><span lang="EN-US"> </span></p>
<p class="MsoNormal"><span lang="EN-US">Kind regards</span></p>
<p class="MsoNormal"><span lang="EN-US">Christoph</span></p>
<p class="MsoNormal"><span lang="EN-US"> </span></p>
<p class="MsoNormal"><span lang="EN-US">P.S.: This is a retransmission, because the original message did not pass moderator approval due to the attached tshark trace</span></p>
</div>
<span style="font-size:9px"><br>
<br>
<br>
The information contained in this e-mail message is privileged and confidential and is for the exclusive use of the addressee. The person who receives this message and who is not the addressee, one of his employees or an agent entitled to hand it over to the
addressee, is informed that he may not use, disclose or reproduce the contents thereof, and is kindly asked to notify the sender and delete the e-mail
<span style="font-size:11px"></span>immediately.<br>
<br>
</span>
</body>
</html>