Hi Michael, Thanks for your reply.
In my case, I need to implement a Group Chat service which is in the middle of the Service Chain, on the left side there is Originating Function and on the right side there is Terminating Function, Both Originating Function and Terminating Function are using iFCs and all the subscribers are share service triggers. Currently I try to use Clearwater to build a end to end test environment, for each Group Chat there is unique ID and once it is generated the Originating Function will send Subscribe and other request to this dynamically generated Sip URI. Since Clearwater don't support wildcard PSI I wonder if I could setup ICSCF so that it would use subdomain based routing to reach the Group Chat Service. Or I have to use external HSS? Thanks Anthony On Fri, Mar 16, 2018 at 1:02 PM, Michael Duppré < michael.dup...@metaswitch.com> wrote: > Hi Anthony, > > > > Sorry, I’m not quite sure you mean here… There are five ways you could > route to a PSI hosted by an App Server: > > - Subscribers could send requests to the SIP URI of the App Server > directly – e.g. the INVITE could have a request URI of sip: > as.example.com > - ENUM could return a translation for the PSI to point directly to the > Application Server > - e.g. 0.0.0.0.5.5.5.3.2.2.1.e164.arpa could resolve to a > translation pointing to sip:as.example.com, which would result in > calls for going to as.example.com See > http://clearwater.readthedocs.io/en/stable/ENUM.html > <http://clearwater.readthedocs.io/en/stable/ENUM.html> > - You can directly attach a PSI by configuring the HSS to point to it > - In this case, the Location Information Answer (LIA) (in response > to the LIR that Clearwater sends) will return the location of the > application server, and the I-CSCF (Sprout) will then route to it. > - You can indirectly attach a PSI by configuring the HSS to point to > an S-CSCF, and then provide IFCs which route to the App Server > - You could configure each subscriber who will create a session with > the PSI to have IFCs which invoke the App Server during originating > processing, matching on the Request URI in the IFCs. > > > In each of these cases, there will be a SIP URI, which will be resolved as > per RFC 3261, with the relevant DNS queries if it represents a domain, or > just routed if it’s an IP address. > > I hope this helps and points you into the right direction? > > > > Kind regards, > > Michael > > > > > > *From:* Clearwater [mailto:clearwater-boun...@lists.projectclearwater.org] > *On Behalf Of *Anthony Lee > *Sent:* 13 March 2018 18:50 > > *To:* clearwater@lists.projectclearwater.org > *Subject:* Re: [Project Clearwater] Does Clearwater support to provision > wildcarded PSI? > > > > Thanks, Ben. > > > > > > I wonder what the difference is between using DNS to map the (w)PSI domain > to my application server > > and using (w)PSI in HSS profile. > > > > > > Anthony > > > > > > On Tue, Mar 13, 2018 at 1:17 PM, Bennett Allen < > bennett.al...@metaswitch.com> wrote: > > Hi Anthony, > > From the logs you have sent I see that you are using homestead-prov, we > only support wildcarded entries with a HSS, which would explain the issues > you are hitting. Here is a link to the docs about a HSS - > http://clearwater.readthedocs.io/en/stable/External_HSS_Integration.html . > > Let us know how it goes, > > Ben > > > > > > *From:* Clearwater [mailto:clearwater-boun...@lists.projectclearwater.org] > *On Behalf Of *Anthony Lee > *Sent:* 10 March 2018 20:02 > *To:* clearwater@lists.projectclearwater.org > *Subject:* Re: [Project Clearwater] Does Clearwater support to provision > wildcarded PSI? > > > > Now I added P-Profile-Key header into the request, the header value is my > wildcard PSI uri( sip:.+@list-service.example.com ). > > > > Homestead log: > > 10-03-2018 19:39:50.073 UTC [7f22987f8700] Debug http_handlers.cpp:619: > Determining request type from '{"reqtype": "call", "server_name": " > sip:scscf.192.168.1.10:5054;transport=TCP", "wildcard_identity": " > sip:.+@list-service.example.com"}' > > > > 10-03-2018 19:39:50.074 UTC [7f22c4fb1700] Debug memcached_cache.cpp:27: > Pausing stopwatch due to Memcached GET fetch result for > impu\\sip:.+@list-service.example.com > > 10-03-2018 19:39:50.075 UTC [7f22c4fb1700] Debug memcached_cache.cpp:33: > Resuming stopwatch due to Memcached GET fetch result for impu\\ > sip:.+@list-service.example.com > > > > 10-03-2018 19:39:50.075 UTC [7f22c4fb1700] Debug memcachedstore.cpp:414: > Key not found > > > > 10-03-2018 19:39:50.075 UTC [7f229affd700] Debug hsprov_store.cpp:78: > Issuing get for key sip:7gbcen27b7lqvh3noa3nt8nftc7gbc > en27b7lqvh3noa3nt8n...@list-service.example.com > > > > 10-03-2018 19:39:50.078 UTC [7f229affd700] Debug cassandra_store.cpp:536: > Cassandra request failed: rc=2, Row sip:7gbcen27b7lqvh3noa3nt8nftc7gbc > en27b7lqvh3noa3nt8n...@list-service.example.com not present in > column_family impu > > > > > > Looks like Homestead uses P-Profile-Key's value to search in cache but > uses R-URI to search in database. > > > > Is it expected behavior? > > > > > > > > > > > > > > > > > > On Sat, Mar 10, 2018 at 10:48 AM, Anthony Lee <anthonyn...@gmail.com> > wrote: > > Sorry, forgot to mention that Sprout's log shows that 404 not found for > that wildcard PSI return from Homestead. . > > > > On Sat, Mar 10, 2018 at 10:44 AM, Anthony Lee <anthonyn...@gmail.com> > wrote: > > My wildcard PSI is sip:.+@list-service.example.com > > > > > > I found some information in Homestead_current.txt: > > > > Debug http_handlers.cpp:695: Did not receive valid JSON with a > 'wildcard_identity' element > > > > Does it mean scscf need to add "wildcard_identity" into the JSON request? > > Is there any configuration need to be done in Sprout? > > > > > > > > On Fri, Mar 9, 2018 at 10:54 PM, Anthony Lee <anthonyn...@gmail.com> > wrote: > > I need to provision wildcarded PSI, does clearwater support to do that? > > If yes, could you provide an example? > > > > Thanks > > > > Anthony > > > > > > > > > _______________________________________________ > Clearwater mailing list > Clearwater@lists.projectclearwater.org > http://lists.projectclearwater.org/mailman/listinfo/clearwater_lists. > projectclearwater.org > > > > _______________________________________________ > Clearwater mailing list > Clearwater@lists.projectclearwater.org > http://lists.projectclearwater.org/mailman/listinfo/clearwater_lists. > projectclearwater.org > >
_______________________________________________ Clearwater mailing list Clearwater@lists.projectclearwater.org http://lists.projectclearwater.org/mailman/listinfo/clearwater_lists.projectclearwater.org
