Hi,

quick note: It should not be necessary to change any source-code to make the reginfo work. At least on my setups this is not needed. I'll check with my own configs later today or tomorrow, to help you out here.

Thanks, Carsten

2016-02-22 9:41 GMT+01:00 Cristina Caridi cri.caridi@gmail.com:

Hello Franz,

thank you for your support! I confirm that I changed the pcscf uri that was by default for smilecoms.I agree with you, the problem is that the P-CSCF is not able to handle the notify message. 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. Please, keep in touch for any update.

Thank you, Cristina

2016-02-21 21:00 GMT+01:00 Franz Edler franz.edler@technikum-wien.at:

...

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

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users