Hi Michele, Could I get some more diagnostics to try and work out why third-party registration is no longer working. The Sprout logs (which can be found on SPNs under /var/log/sprout/sprout_current.txt) for a registration may be helpful here.
Thanks, Andrew From: Clearwater [mailto:[email protected]] On Behalf Of Michele Furlanetto Sent: Wednesday, July 26, 2017 4:40 PM To: [email protected] Subject: Re: [Project Clearwater] [Clearwater] AS Configuration and untrusted sources I went a little forward, removing the line relative to as1.service.example.com<http://as1.service.example.com> in file /etc/hosts and adding srv-host=_sip._udp.scscf.cw-aio,scscf.cw-aio,5054 srv-host=_sip._udp.as1.service.example.com<http://udp.as1.service.example.com>,example.com<http://example.com>,5071 to /etc/dnsmasq.conf. now the SUBSCRIBEs (and other messages) are delivered to as1, but I’ve lost the working third-party registration. After fixing this, the next step for me will be adding another AS, as2, which will dialog only with as1. The simplest think I could try is adding srv-host=_sip._udp.as2.service.example.com<http://udp.as2.service.example.com>,example.com<http://example.com>,5072 but is not enough. What configuration I’m missing? Thank you, Michele Il giorno 26 lug 2017, alle ore 11:27, Michele Furlanetto <[email protected]<mailto:[email protected]>> ha scritto: Hi Andrew, As I said, I didn’t configure any DNS service to support our AS, all I did in this way was adding the lines to /etc/hosts 10.2.0.91 as1.service.example.com<http://participant.mcptt.example.com/> 10.2.0.127 example.com<http://example.com/> In attachment you can find the local_config and shared_config files. Referring the previous message, my SIP client does use the same port for both REGISTER and SUBSCRIBE. Thank you for your support, Michele <local and shared configs.zip> Il giorno 25 lug 2017, alle ore 15:40, Andrew Edmonds <[email protected]<mailto:[email protected]>> ha scritto: Hi Michele, I’ve spoken to a colleague about this issue and have a new idea now as to why the SUBSCRIBE message is being rejected. After Bono receives the SUBSCRIBE from the SIP device we can see the log: 24-07-2017 10:38:25.414 UTC Verbose pjsip: tcpc0x7f094c03 TCP transport 10.2.0.127:5058 is connecting to 10.2.0.127:5060.. 10.2.0.127 is the Bono node’s IP address. So this is telling us that Bono is forwarding the SUBSCRIBE to itself from its trusted port 5058 (used to communicate with the IMS core) to its untrusted port 5060 (which SIP devices send their requests to). We then see in the logs Bono receiving this SUBSCRIBE and then rejecting it. So the question we need to resolve now becomes why is Bono routing the SUBSCRIBE to itself? To answer this we need to understand how SIP messages are routed. Messages containing SIP methods (like INVITEs, SUBSCRIBEs, REGISTERs etc.) are routed based off of the Route-header. If we look at the route headers for one of the SUBSCRIBERs we see: Route: sip:scscf.cw-aio;transport=udp;lr;orig;username=6505550751%40example.com;nonce=716970855dbe8690 Here the port of the S-CSCF (5054) has not been included in the SIP address of the S-CSCF. We can also see from the logs that we do not retrieve a port number via SRV DNS lookup: 24-07-2017 10:38:25.414 UTC Debug dnscachedresolver.cpp:686: Received DNS response for _sip._udp.scscf.cw-aio type SRV 24-07-2017 10:38:25.414 UTC Warning dnscachedresolver.cpp:828: Failed to retrieve record for _sip._udp.scscf.cw-aio: Domain name not found This means that Bono does not know which port to forward the message to and so it chooses 5060 which routes the message back to itself. The next thing to consider then is why does the Route-Header not contain the port number? The Route header which is to be applied to future requests for a subscriber is communicated to Bono by the S-CSCF in a Service-Route header after it successfully authenticates a subscriber. If we have a look at the 200 OK in response to the registration we see: Service-Route: sip:scscf.cw-aio;transport=udp;lr;orig;username=6505550751%40example.com;nonce=716970855dbe8690 This means that it is the S-CSCF that is causing Bono to attach a Route header to the SUBSCRIBE which does not contain a port number. To figure out why the S-CSCF is doing this could you please send me a copy of /etc/clearwater/shared_config and /etc/clearwater/local_config from the SPN and a copy of the SPN log file during a REGISTRATION and SUBSCRIBE. Thanks, Andrew
_______________________________________________ Clearwater mailing list [email protected] http://lists.projectclearwater.org/mailman/listinfo/clearwater_lists.projectclearwater.org
