Hi Abaco, I've just spoken to a colleague and he mentioned that client support for what you are trying to do is very limited. imsdroid may work, but we don't have much experience with it.
However when you register for sip:[email protected] using [email protected], sip:[email protected] will also become registered and calls to that ID will ring the registered device. Maybe that is sufficient for what you are trying to achieve? Thanks, Alex. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Alex Hockey Sent: 23 October 2014 18:14 To: Ruggero Schiavi Cc: [email protected] Subject: Re: [Clearwater] FoHSS integration - busy everywhere Hi Abaco You’re right that multiple public identities (like sip:[email protected], sip:[email protected]) can be authenticated by one private identity (like [email protected]<mailto:[email protected]> – note no “sip:” prefix). Clearwater allows this. Another feature that Clearwater supports is that, if a private ID is not supplied on a SIP REGISER, it will derive a private ID from the public ID by removing the “sip:” prefix. So given the public ID sip:[email protected] it would calculate a private ID of [email protected]<mailto:[email protected]>. This works fine if the public ID and private ID are the same phone number, but doesn’t work if they are different. So I suspect what’s happening here is that you haven’t entered the private ID into your client correctly. Could you double check this? If you still don’t have any luck, the next step would be to gather sprout logs for a registration attempt. The sprout logs are produced in /var/log/sprout/sprout*.txt. By default the logging level is set to log level 2, which only includes errors and very high level events. To enable debug logs, change the log level to 5 by writing log_level=5 to /etc/clearwater/user_settings (creating it if it doesn't exist already), and restart sprout (using service sprout stop - monit automatically restarts it). One more thing – you mention that you have tried both Ellis and OpenHSS, that’s great! However things might not work properly if you use both Ellis and an HSS on the same deployment. I don’t think that is the problem here but I wanted to mention it. Hope this helps, Alex. From: Ruggero Schiavi [mailto:[email protected]] Sent: 23 October 2014 15:09 To: Alex Hockey Cc: Eleanor Merry; [email protected] Subject: Re: [Clearwater] FoHSS integration - busy everywhere Thank you very much for the explanations Alex, I have still a little doubt about identites. I should be able to associate a private identity with more public identities. Taking as example x-lite the authorization name should always be the private one and the user ID should correspond to the public ID I am willing to register. Both with Ellis and openHSS if the two identies are not the same the registration can not be fulfilled. For instance if I have a private identity 8888@domain and two associated public identities 8888@domain 8889@domain I will be only able to register the first public identity. How is this really working in Clearwater/HSS? Thank you very much for any hint you can provide, Regards, Abaco 2014-10-20 17:33 GMT+02:00 Alex Hockey <[email protected]<mailto:[email protected]>>: Hi Abaco, I'm glad you seem to have gotten things working! For future reference, in IMS subscriber service configuration consists of two parts. - What services a subscriber is allowed to use. This is configured in the HSS (as "Initial Filter Criteria"). - What setting a subscriber is using for their services. This contains things like call diversion rules. These live in XML documents in an XDMS (XML Data Management Server), which for Clearwater is Homer. Thanks, Alex. -----Original Message----- From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Ruggero Schiavi Sent: 20 October 2014 10:43 To: Eleanor Merry Cc: [email protected]<mailto:[email protected]> Subject: Re: [Clearwater] FoHSS integration - busy everywhere Hi, I supposed that now the xml file for each user was not created anymore at user creation on the mmtel, in fact homer was answering not found. I did a PUT of the XML (using the indication at: https://github.com/Metaswitch/crest/blob/dev/docs/homer_api.md) on homer for the desired uri, e.g. sip:011555xx, and everything worked well. I suppose that now this is the only correct way to configure mmtel for the users requiring call diversion etc. Thanks again for the help, Abaco _______________________________________________ Clearwater mailing list [email protected]<mailto:[email protected]> http://lists.projectclearwater.org/listinfo/clearwater _______________________________________________ Clearwater mailing list [email protected] http://lists.projectclearwater.org/listinfo/clearwater _______________________________________________ Clearwater mailing list [email protected] http://lists.projectclearwater.org/listinfo/clearwater
