<div dir="ltr">Hello Franz, <div><br></div><div>thank you for your support! </div><div>I confirm that I changed the pcscf uri that was by default for<span style="color:rgb(80,0,80);font-size:12.8px"> smilecoms.I agree with you,</span><span style="color:rgb(80,0,80);font-size:12.8px"> the problem is that the P-CSCF is not able to handle the notify message. </span><span style="color:rgb(80,0,80);font-size:12.8px">In the next days I will try to modify the code in the config file even if I'm not a developer and an IMS expert.</span></div><div><span style="color:rgb(80,0,80);font-size:12.8px">Please, keep in touch for any update.</span><br></div><div><span style="color:rgb(80,0,80);font-size:12.8px"><br></span></div><div><span style="color:rgb(80,0,80);font-size:12.8px">Thank you,</span></div><div><span style="color:rgb(80,0,80);font-size:12.8px">Cristina</span></div><div><span style="color:rgb(80,0,80);font-size:12.8px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-02-21 21:00 GMT+01:00 Franz Edler <span dir="ltr"><<a href="mailto:franz.edler@technikum-wien.at" target="_blank">franz.edler@technikum-wien.at</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Hi Cristina,<br>
<br>
> But I have another problem related to registration process. After REGISTER-<br>
> 401 Unauthorized-REGISTER-200 OK, the IMS client sends the SUBSCRIBE<br>
> message (for the "reg" event package subscription) to the S-CSCF, the latter<br>
> replies with NOTIFY and the client correctly responds with 200 OK. In order to<br>
> be notified on any change of registration state for the client, also the P-CSCF<br>
> sends the SUBSCRIBE message to the S-CSCF, the S-CSCF sends a NOTIFY to<br>
> the proxy but, instead of replying with 200 OK, the P-CSCF replies with 404-<br>
> Not Here (like it doesn't recognize that the recipient of the NOTIFY in the<br>
> Req-URI is the P-CSCF itself).<br>
><br>
> Have you ever seen similar issue?<br>
<br>
I have now spent some time to reproduce the issue.<br>
First of all: I had to adapt module reg_mod.c in ims_registrar_pcscf, because it containes a hardcoded P-CSCF address:<br>
str pcscf_uri = str_init("sip:<a href="http://pcscf.ims.smilecoms.com:4060" rel="noreferrer" target="_blank">pcscf.ims.smilecoms.com:4060</a>");<br>
which is only valid for smilecoms.<br>
Did you also change that?<br>
<br>
Then I got exactly the same problem. I found that the P-CSCF config causes in the part "# Check for Subsequent requests:" a reject " sl_send_reply("404","Not here");"<br>
I have doubts that this is correctly designed and have to dig deeper into the logic of the config-file.<br>
Fact is: the NOTIFY request does not contain a Route header and as it not an ACK it goes straight to the reject.<br>
Maybe any IMS expert can shed some light on this code as shown below:<br>
<br>
# Check for Subsequent requests:<br>
if (has_totag()) {<br>
# sequential request withing a dialog should<br>
# take the path determined by record-routing<br>
if (loose_route()) {<br>
if ($route_uri =~ "sip:mo@.*") {<br>
setflag(FLT_MO);<br>
}<br>
if(!isdsturiset()) {<br>
handle_ruri_alias();<br>
}<br>
# RTP-Relay, if necessary<br>
route(RTPPROXY);<br>
t_relay();<br>
} else {<br>
if ( is_method("ACK") ) {<br>
if ( t_check_trans() ) {<br>
# no loose-route, but stateful ACK;<br>
# must be an ACK after a 487<br>
# or e.g. 404 from upstream server<br>
t_relay();<br>
exit;<br>
} else {<br>
# ACK without matching transaction ... ignore and discard<br>
exit;<br>
}<br>
}<br>
sl_send_reply("404","Not here");<br>
}<br>
exit;<br>
<br>
BR Franz<br>
<br>
<br>
</div></div></blockquote></div><br></div>