Hi Cristina,
But I have another problem related to registration
process. After REGISTER-
401 Unauthorized-REGISTER-200 OK, the IMS client sends the SUBSCRIBE
message (for the "reg" event package subscription) to the S-CSCF, the latter
replies with NOTIFY and the client correctly responds with 200 OK. In order to
be notified on any change of registration state for the client, also the P-CSCF
sends the SUBSCRIBE message to the S-CSCF, the S-CSCF sends a NOTIFY to
the proxy but, instead of replying with 200 OK, the P-CSCF replies with 404-
Not Here (like it doesn't recognize that the recipient of the NOTIFY in the
Req-URI is the P-CSCF itself).
Have you ever seen similar issue?
I have now spent some time to reproduce the issue.
First of all: I had to adapt module reg_mod.c in ims_registrar_pcscf, because it containes
a hardcoded P-CSCF address:
str pcscf_uri = str_init("sip:pcscf.ims.smilecoms.com:4060");
which is only valid for smilecoms.
Did you also change that?
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");"
I have doubts that this is correctly designed and have to dig deeper into the logic of the
config-file.
Fact is: the NOTIFY request does not contain a Route header and as it not an ACK it goes
straight to the reject.
Maybe any IMS expert can shed some light on this code as shown below:
# Check for Subsequent requests:
if (has_totag()) {
# sequential request withing a dialog should
# take the path determined by record-routing
if (loose_route()) {
if ($route_uri =~ "sip:mo@.*") {
setflag(FLT_MO);
}
if(!isdsturiset()) {
handle_ruri_alias();
}
# RTP-Relay, if necessary
route(RTPPROXY);
t_relay();
} else {
if ( is_method("ACK") ) {
if ( t_check_trans() ) {
# no loose-route, but stateful ACK;
# must be an ACK after a 487
# or e.g. 404 from upstream server
t_relay();
exit;
} else {
# ACK without matching transaction ... ignore and discard
exit;
}
}
sl_send_reply("404","Not here");
}
exit;
BR Franz