Hi Andrew, A call in my architecture follows this flow: user1 <=> AS1 <=> AS2 <=> AS(1or3) <=> user2.
Every AS knows the URI of the next in chain. I know how to apply an IFC to requests made by a user (using Ellis or a shared IFC), but not how to apply it to an AS. The result I’m actually getting is the flow interrupting after AS1, because [from Sprout log] 05-10-2017 09:32:31.740 UTC Debug pjutils.cpp:1701: Logging SAS Call-ID marker, Call-ID 854DE32027F7A5B8E1F6 05-10-2017 09:32:31.740 UTC Debug thread_dispatcher.cpp:268: Queuing cloned received message 0x7f31a40a3fd8 for worker threads 05-10-2017 09:32:31.740 UTC Debug thread_dispatcher.cpp:145: Worker thread dequeue message 0x7f31a40a3fd8 05-10-2017 09:32:31.740 UTC Debug pjsip: sip_endpoint.c Distributing rdata to modules: Request msg SUBSCRIBE/cseq=62401 (rdata0x7f31a40a3fd8) 05-10-2017 09:32:31.740 UTC Debug uri_classifier.cpp:160: home domain: false, local_to_node: false, is_gruu: false, enforce_user_phone: false, prefer_sip: true, treat_number_as_phone: false 05-10-2017 09:32:31.740 UTC Debug uri_classifier.cpp:206: Classified URI as 5 05-10-2017 09:32:31.740 UTC Debug basicproxy.cpp:62: Process SUBSCRIBE request 05-10-2017 09:32:31.740 UTC Verbose sproutletproxy.cpp:582: Sproutlet Proxy transaction (0x7f3198091760) created 05-10-2017 09:32:31.740 UTC Debug basicproxy.cpp:1282: Report SAS start marker - trail (6d) 05-10-2017 09:32:31.740 UTC Debug pjutils.cpp:695: Cloned Request msg SUBSCRIBE/cseq=62401 (rdata0x7f31a40a3fd8) to tdta0x7f3198082ba0 05-10-2017 09:32:31.740 UTC Debug pjsip: tsx0x7f31980c6 Transaction created for Request msg SUBSCRIBE/cseq=62401 (rdata0x7f31a40a3fd8) 05-10-2017 09:32:31.740 UTC Debug pjsip: tsx0x7f31980c6 Incoming Request msg SUBSCRIBE/cseq=62401 (rdata0x7f31a40a3fd8) in state Null 05-10-2017 09:32:31.740 UTC Debug pjsip: tsx0x7f31980c6 State changed from Null to Trying, event=RX_MSG 05-10-2017 09:32:31.740 UTC Debug basicproxy.cpp:183: tsx0x7f31980c6ca8 - tu_on_tsx_state UAS, TSX_STATE RX_MSG state=Trying 05-10-2017 09:32:31.740 UTC Debug pjsip: endpoint Response msg 408/SUBSCRIBE/cseq=62401 (tdta0x7f31980b02d0) created 05-10-2017 09:32:31.740 UTC Debug sproutletproxy.cpp:170: Find target Sproutlet for request 05-10-2017 09:32:31.741 UTC Debug sproutletproxy.cpp:204: Found next routable URI: sip:as2.service.example.com 05-10-2017 09:32:31.741 UTC Debug sproutletproxy.cpp:337: Possible service name as2 will be used if service.example.com is a local hostname 05-10-2017 09:32:31.741 UTC Debug sproutletproxy.cpp:229: No Sproutlet found using service name or host 05-10-2017 09:32:31.741 UTC Debug sproutletproxy.cpp:235: Find default service for port 5055 05-10-2017 09:32:31.741 UTC Debug mmtel.cpp:61: Failed to find P-Served-User header - not invoking MMTEL 05-10-2017 09:32:31.741 UTC Debug sproutletproxy.cpp:170: Find target Sproutlet for request 05-10-2017 09:32:31.741 UTC Debug sproutletproxy.cpp:204: Found next routable URI: sip:as2.service.example.com 05-10-2017 09:32:31.741 UTC Debug sproutletproxy.cpp:337: Possible service name as2 will be used if service.example.com is a local hostname 05-10-2017 09:32:31.741 UTC Info sproutletproxy.cpp:644: Reject request 05-10-2017 09:32:31.741 UTC Error basicproxy.cpp:245: Failed to create BasicProxy UAS transaction object, Option/operation is not supported (PJ_ENOTSUP) 05-10-2017 09:32:31.741 UTC Debug basicproxy.cpp:399: Rejecting SUBSCRIBE request with 500 status code 05-10-2017 09:32:31.741 UTC Debug pjsip: endpoint Response msg 500/SUBSCRIBE/cseq=62401 (tdta0x7f31980b2290) created 05-10-2017 09:32:31.741 UTC Debug pjsip: sip_resolve.c Target '10.2.0.91:5071' type=UDP resolved to '10.2.0.91:5071' type=UDP (UDP transport) 05-10-2017 09:32:31.741 UTC Verbose common_sip_processing.cpp:106: TX 534 bytes Response msg 500/SUBSCRIBE/cseq=62401 (tdta0x7f31980b2290) to UDP 10.2.0.91:5071: Thanks, Michele > Il giorno 03 ago 2017, alle ore 12:00, Andrew Edmonds > <[email protected]> ha scritto: > > Hi Michele, > > Thanks for the additional diagnostics. > > In order to diagnose the problem I need to understand what you expect the > flow between as1 and as2 to look like. How do you expect Clearwater will be > involved in the routing here? Typically we route to application servers by > using iFCs but from the looks of the sprout log the iFC used here doesn’t > include as2. How do you expect calls to be routed to as2? > > Thanks, > > Andrew > > From: Clearwater [mailto:[email protected]] On > Behalf Of Michele Furlanetto > Sent: Thursday, August 3, 2017 10:05 AM > To: [email protected] > Subject: Re: [Project Clearwater] [Clearwater] AS Configuration and untrusted > sources > > Hi Andrew, > > About the third-party registration I had misconfigurated something. So I > restarted from the .ova image and now works. > The last thing I have to configure is to enable communication between as1 and > as2. > > In attachment you can find the files /etc/hosts, /etc/dnsmasq.conf and the > logs of bono and sprout. > > > Thanks for the help, > Michele > > > > Il giorno 31 lug 2017, alle ore 11:07, Andrew Edmonds > <[email protected] <mailto:[email protected]>> ha > scritto: > > 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] > <mailto:[email protected]>] On Behalf Of Michele > Furlanetto > Sent: Wednesday, July 26, 2017 4:40 PM > To: [email protected] > <mailto:[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 > > <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 > > <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] > <mailto:[email protected]> > http://lists.projectclearwater.org/mailman/listinfo/clearwater_lists.projectclearwater.org > > <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 > > <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
