[SR-Users] Registration Failure - IMS

Cristina Caridi cri.caridi at gmail.com
Mon Feb 22 09:41:22 CET 2016


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 at 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 at .*") {
>                                 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20160222/0918fd1e/attachment.html>


More information about the sr-users mailing list