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