21 Feb
2016
21 Feb
'16
9 p.m.
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
22 Feb
22 Feb
9:41 a.m.
New subject: Registration Failure - IMS
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>:
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
9:49 a.m.
New subject: Registration Failure - IMS
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
11 Mar
11 Mar
9:33 p.m.
New subject: Registration Failure - IMS
Hi Carsten,
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.
Any news on this topic?
BR Franz
2976
days inactive
2995
days old
3 comments
3 participants
participants (3)
-
Carsten Bock -
Cristina Caridi -
Franz Edler