Hi Matt You nailed it. The SCSCF name I provisioned in the HSS was a CNAME that pointed to one of the route 53 A records chef created. I reprovisioned the SCSCF with one of the A record host names, deleted and recreated my user and voila - I am registered.
Thank you so much! Kind regards Jim RedMatter Ltd Jim Page VP Mobile Services +44 (0)333 150 1666 +44 (0)7870 361412 [email protected]<mailto:[email protected]> On 22 Sep 2017, at 11:23, Matt Williams <[email protected]<mailto:[email protected]>> wrote: Thanks! When the I-CSCF receives the User-Authentication-Answer from the HSS, the HSS returns "sip:scscf.ims.rmcore.net" as the S-CSCF to which the subscriber is assigned... but the configuration below is such that the S-CSCF doesn't recognize this as itself. Normally, the I-CSCF would then route the request to this other S-CSCF, except the domain name resolves to our own S-CSCF again. I'm not quite sure how the HSS got into this state (maybe the first registration was while the S-CSCF was still being reconfigured?), but please can you either try forcing de-registration on the HSS or (if this isn't easy with your HSS) creating a new subscriber and registering with that? It would be great if you could grab the same logs and network captures as before for the first registration attempt, in case this doesn't fix it itself. Thanks, Matt From: Clearwater [mailto:[email protected]] On Behalf Of Jim Page Sent: 22 September 2017 11:00 To: [email protected]<mailto:[email protected]> Subject: Re: [Project Clearwater] Looping authentication with Bria One more factoid - the HSS installation via chef was not perfect. The HSS package postinstall scripts failed … I -think- because mysql was already running when the package was installed, and also it wrote some bad config into /etc/resolv.conf which messed up DNS. Finally, the SCSCF and ICSCF ports were incorrectly configured. I think I sorted most of that out, and I can see diameter packets arriving and the HSS logs indicate that stuff is being processed, but I thought I should mention it in case it rings any bells. Kind regards Jim RedMatter Ltd Jim Page VP Mobile Services +44 (0)333 150 1666 +44 (0)7870 361412 [email protected]<mailto:[email protected]> On 22 Sep 2017, at 10:56, Jim Page <[email protected]<mailto:[email protected]>> wrote: Matt, does the HSS have any input into the process of deciding whether the URI is on the home domain? If so, is it possible I misconfigured the HSS? I have had a look through and cannot see anything obvious, but I am really not sure what HSS config might be relevant. Kind regards Jim RedMatter Ltd Jim Page VP Mobile Services +44 (0)333 150 1666 +44 (0)7870 361412 [email protected]<mailto:[email protected]> On 22 Sep 2017, at 10:52, Jim Page <[email protected]<mailto:[email protected]>> wrote: Hi Matt Here it is: [sprout-1]ubuntu@ec2-35-176-248-167:~$ cat /etc/clearwater/shared_config # Deployment definitions home_domain=ims.rmcore.net<http://ims.rmcore.net/> sprout_hostname=sprout.ims.rmcore.net<http://sprout.ims.rmcore.net/> sprout_hostname_mgmt=sprout.ims.rmcore.net:9886<http://sprout.ims.rmcore.net:9886/> hs_hostname=hs.ims.rmcore.net:8888<http://hs.ims.rmcore.net:8888/> hs_hostname_mgmt=hs.ims.rmcore.net:8886<http://hs.ims.rmcore.net:8886/> hs_provisioning_hostname=hs.ims.rmcore.net:8889<http://hs.ims.rmcore.net:8889/> homestead_impu_store="site1=vellum-site1.ims.rmcore.net<http://vellum-site1.ims.rmcore.net/>” xdms_hostname=homer.ims.rmcore.net:7888<http://homer.ims.rmcore.net:7888/> ralf_hostname=ralf.ims.rmcore.net:10888<http://ralf.ims.rmcore.net:10888/> cdf_identity=cdf.ims.rmcore.net<http://cdf.ims.rmcore.net/> sprout_impi_store=vellum.ims.rmcore.net<http://vellum.ims.rmcore.net/> sprout_registration_store="site1=vellum-site1.ims.rmcore.net<http://vellum-site1.ims.rmcore.net/>” cassandra_hostname=vellum.ims.rmcore.net<http://vellum.ims.rmcore.net/> chronos_hostname=vellum.ims.rmcore.net<http://vellum.ims.rmcore.net/> ralf_session_store="site1=vellum-site1.ims.rmcore.net<http://vellum-site1.ims.rmcore.net/>” memento_auth_store=vellum.ims.rmcore.net<http://vellum.ims.rmcore.net/> sas_server=0.0.0.0 enum_server= alias_list= scscf_uri=sip:scscf.sprout.ims.rmcore.net upstream_port=0 # Email server configuration smtp_smarthost=localhost smtp_username= smtp_password= [email protected]<mailto:[email protected]> # HSS configuration hss_hostname=hss-site1.ims.rmcore.net<http://hss-site1.ims.rmcore.net/> hss_port=3868 # CDF configuration billing_realm=cdf.ims.rmcore.net<http://cdf.ims.rmcore.net/> # Registrar configuration # P-CSCF configuration trusted_peers=“” # Sproutlet configuration memento=5055 gemini=5055 cdiv=5055 # Keys signup_key=“QEgRgtKh” turn_workaround=“eHMwX98p” ellis_api_key=“ENYNhvPg” ellis_cookie_key=“FUZG1jMB” # Advanced options nonce_count_supported=Y Kind regards Jim RedMatter Ltd Jim Page VP Mobile Services +44 (0)333 150 1666 +44 (0)7870 361412 [email protected]<mailto:[email protected]> On 22 Sep 2017, at 10:47, Matt Williams <[email protected]<mailto:[email protected]>> wrote: Jim, Thanks for those diagnostics! I think the problem occurs here - specifically the uri_classifier logs: 22-09-2017 09:04:02.770 UTC Debug sproutletproxy.cpp:163: Find target Sproutlet for request 22-09-2017 09:04:02.770 UTC Debug sproutletproxy.cpp:197: Found next routable URI: sip:ims.rmcore.net;lr;service=registrar 22-09-2017 09:04:02.770 UTC Debug sproutletproxy.cpp:300: Found services param - registrar 22-09-2017 09:04:02.770 UTC Debug uri_classifier.cpp:139: home domain: false, local_to_node: false, is_gruu: false, enforce_user_phone: false, prefer_sip: true, treat_number_as_phone: false 22-09-2017 09:04:02.770 UTC Debug uri_classifier.cpp:185: Classified URI as 5 22-09-2017 09:04:02.770 UTC Debug sproutletproxy.cpp:427: Creating URI for service subscription Basically, we have a SIP URI that says "service=registrar". This invokes the registrar Sproutlet. However, the registrar Sproutlet checks that the URI looks right before it accepts it (using the URIClassifier), and it finds that it's not for our home domain (see "home domain: false"). This means that it classifies URI as "5", which is a bit cryptic but corresponds to the URIClass enum, and means OFFNET_SIP_URI... so we route it off net. So why isn't ims.rmcore.net<http://ims.rmcore.net/> recognized as the home domain? Please can you share the /etc/clearwater/shared_config file from your system? Thanks, Matt From: Jim Page [mailto:[email protected]] Sent: 22 September 2017 10:27 To: [email protected]<mailto:[email protected]> Cc: Matt Williams <[email protected]<mailto:[email protected]>> Subject: Re: [Project Clearwater] Looping authentication with Bria Hi Matt Thanks a lot for getting in touch. I have attached PCAPs of the bria (just sip) and the bono and sprout hosts (everything). Also the bono and sprout logs at log_level=5. I have copied this email to your metaswitch email in case the zip is removed from the forum emails, hope that’s ok. Your explanation makes sense - let’s hope it’s an easy fix! This is my #1 priority right now so please let me know if there’s anything else I can do to help debug this. Kind regards Jim _______________________________________________ Clearwater mailing list [email protected]<mailto:[email protected]> http://lists.projectclearwater.org/mailman/listinfo/clearwater_lists.projectclearwater.org _______________________________________________ Clearwater mailing list [email protected]<mailto:[email protected]> http://lists.projectclearwater.org/mailman/listinfo/clearwater_lists.projectclearwater.org _______________________________________________ Clearwater mailing list [email protected]<mailto:[email protected]> http://lists.projectclearwater.org/mailman/listinfo/clearwater_lists.projectclearwater.org
_______________________________________________ Clearwater mailing list [email protected] http://lists.projectclearwater.org/mailman/listinfo/clearwater_lists.projectclearwater.org
