[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