22 Feb
2016
22 Feb
'16
10:49 a.m.
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(a)gmail.com>om>:
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(a)technikum-wien.at>at>:
--
Carsten Bock
CEO (Geschäftsführer)
ng-voice GmbH
Millerntorplatz 1
20359 Hamburg / Germany
http://www.ng-voice.com
mailto:carsten@ng-voice.com
Office +49 40 5247593-40
Fax +49 40 5247593-99
Sitz der Gesellschaft: Hamburg
Registergericht: Amtsgericht Hamburg, HRB 120189
Geschäftsführer: Carsten Bock
Ust-ID: DE279344284
Hier finden Sie unsere handelsrechtlichen Pflichtangaben:
http://www.ng-voice.com/imprint/
Hi Cristina,
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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