Hi Ellie,
I am not sure either or not I still have a problem with the iFCs triggers or not. I am still using the following trigger <InitialFilterCriteria><TriggerPoint><ConditionTypeCNF>1</ConditionTypeCNF><SPT><ConditionNegated>0</ConditionNegated><Group>0</Group><Method>INVITE</Method></SPT></TriggerPoint><ApplicationServer><ServerName> sip:10.0.20.215</ServerName><DefaultHandling>0</DefaultHandling></ApplicationServer></InitialFilterCriteria > But I noticed that when I am transferring a call between parties, the NOTIFY message is not reaching the REFERing client. I would like to make a test where NOTIFY is excluded from the trigger and is not forwarded to the MMTEL AS. Can you help with the correct syntax of the iFC? -Franck. *From:* Franck Malka [mailto:[email protected]] *Sent:* Tuesday, January 12, 2016 8:19 PM *To:* Eleanor Merry <[email protected]> *Cc:* [email protected] *Subject:* RE: [Clearwater] Configuration of iFCs rules Thanks i just used a non registered private identity as a trigger and it did the job for me. Franck On Jan 12, 2016 20:01, "Eleanor Merry" <[email protected]> wrote: Hi Franck, Thanks for sending the logs across. On the terminating leg of the call, Sprout asks Homestead for the subscriber data of sip:[email protected]. It doesn’t look like Homestead knows anything about this PSI though, so it returns a 404, and Sprout then rejects the call. You’ll need to make sure Clearwater knows about the PSI. Are you using an external HSS? If so, then add the PSI to the HSS (the details for how to do so depend on your HSS). If you’re not using a HSS, then you can add the PSI using the Ellis API (see https://github.com/Metaswitch/ellis/blob/dev/docs/api.md#provisioning-specific-numbers for details). Then you can set up the PSI IFC in the same way that you’ve done for your other subscribers (but make sure that the IFC for the PSI doesn’t only trigger for **registered** subscribers). Ellie *From:* Franck Malka [mailto:[email protected]] *Sent:* 08 January 2016 05:00 *To:* [email protected]; Eleanor Merry *Subject:* RE: [Clearwater] Configuration of iFCs rules Hi Further investigating this issue, i was told by the MMTEL AS guys that i need to configure an iFC for a Public Service Identity (PSI) with conf-factory URI. any guidelines on how would look the syntax of such an iFC? Franck On Jan 7, 2016 14:28, "Franck Malka" <[email protected]> wrote: Attached the requested logs: -Franck. *From:* Eleanor Merry [mailto:[email protected]] *Sent:* Thursday, January 7, 2016 1:46 PM *To:* Franck Malka <[email protected]>; [email protected] *Subject:* RE: [Clearwater] Configuration of iFCs rules Hi Franck, To turn on debug logging create/edit the file /etc/clearwater/user_settings, add log_level=5 and then restart Sprout (service sprout stop – it’s automatically restarted by monit). The logs are output in /var/log/sprout/. Ellie *From:* Franck Malka [mailto:[email protected] <[email protected]>] *Sent:* 07 January 2016 11:42 *To:* Eleanor Merry; [email protected] *Subject:* RE: [Clearwater] Configuration of iFCs rules Can you tell me how to enable debug logs? The only thing I see in the sprout log is [cw-aio]ubuntu@cw-aio:/var/log/sprout$ tail -f sprout_current.txt 07-01-2016 11:35:58.468 UTC Status load_monitor.cpp:237: Maximum incoming request rate/second increased to 14390.840820 (based on a smoothed mean latency of 1301 and 0 upstream overload responses) 07-01-2016 11:37:41.905 UTC Status load_monitor.cpp:237: Maximum incoming request rate/second increased to 14400.557617 (based on a smoothed mean latency of 2830 and 0 upstream overload responses) 07-01-2016 11:39:42.301 UTC Status load_monitor.cpp:237: Maximum incoming request rate/second increased to 14410.234375 (based on a smoothed mean latency of 3231 and 0 upstream overload responses) 07-01-2016 11:40:22.812 UTC Error httpconnection.cpp:743: cURL failure with cURL error code 0 (see man 3 libcurl-errors) and HTTP error code 404 07-01-2016 11:40:22.812 UTC Error hssconnection.cpp:593: Could not get subscriber data from HSS 07-01-2016 11:41:12.701 UTC Status load_monitor.cpp:237: Maximum incoming request rate/second increased to 14419.383789 (based on a smoothed mean latency of 8509 and 0 upstream overload responses) 07-01-2016 11:41:12.714 UTC Error httpconnection.cpp:743: cURL failure with cURL error code 0 (see man 3 libcurl-errors) and HTTP error code 404 07-01-2016 11:41:12.714 UTC Error hssconnection.cpp:593: Could not get subscriber data from HSS 07-01-2016 11:41:12.944 UTC Error httpconnection.cpp:743: cURL failure with cURL error code 0 (see man 3 libcurl-errors) and HTTP error code 404 07-01-2016 11:41:12.945 UTC Error hssconnection.cpp:593: Could not get subscriber data from HSS -Franck. *From:* Eleanor Merry [mailto:[email protected]] *Sent:* Thursday, January 7, 2016 1:35 PM *To:* Franck Malka <[email protected]>; [email protected] *Subject:* RE: [Clearwater] Configuration of iFCs rules Hi Frank, Can you send me the Sprout debug logs for this call? Ellie *From:* Franck Malka [mailto:[email protected] <[email protected]>] *Sent:* 07 January 2016 10:17 *To:* Eleanor Merry; [email protected] *Subject:* RE: [Clearwater] Configuration of iFCs rules Hello Again, I think I am getting closer to my problem here. In fact, the UE dials to the conf-factory and the MMTEL AS routes the call according to the P-Served-User Header sescase tag. So when the calls come-in to the AS with P-Served-User: <sip:[email protected]>;sescase=orig;regstate=reg The sescase tag is orig, so the AS threat the call as an originating leg and return the call to the S-CSCF as for any usual call. Now the gets the S-CSCF the INVITE back the AS expect the S-CSCF to change the header to P-Served-User: <sip:[email protected]>;sescase=term;regstate=reg And to return the request to the AS, then the AS shall detect the terminating leg and forward handle the call as a conference call. My problem here is that the S-CSCF do not change the sescase tag to term, so the INVITE request is going back and forward between the S-CSCF and the AS and nobody handles it. So, the refined question would be: How do I configure the S-CSCF to change the leg type here? See attached pcap. -Franck. *From:* Franck Malka [mailto:[email protected]] *Sent:* Wednesday, January 6, 2016 3:51 PM *To:* Eleanor Merry <[email protected]>; [email protected] *Subject:* RE: [Clearwater] Configuration of iFCs rules Hi Ellie, Thanks for the comment. I think I originally misunderstood the problem I have. I do get originating and terminating triggers on the MMTEL AS. This works fine. The problem I face is with MMTEL Conference. In this specific scenario, the MMTEL AS sends the INVITE Request with the conf-factory URI to the S-CSCF and the MMTEL AS expects to get back an MT leg for it with the conference focus id. I thought we were missing the terminating trigger but It was a misinterpretation of the logs. We are missing the terminating leg for the conf-factory. I am not sure where and how shall we configure this specific trigger for the conferencing feature. -Franck. *From:* Eleanor Merry [mailto:[email protected]] *Sent:* Wednesday, January 6, 2016 3:44 PM *To:* Franck Malka <[email protected]>; [email protected] *Subject:* RE: [Clearwater] Configuration of iFCs rules Hi Franck, Your trigger is using the Conjunctive Normal Form, so it matches a message if at least of one of each entry in your groups is true. Group 0 in your IFC is ("INVITE" OR "MESSAGE" OR "SUBSCRIBE") and Group 1 is ("INVITE" or "MESSAGE" or session case 0 or session case 1), so this should match any INVITE and any MESSAGE requests, and any SUSCRIBE requests that are originating registered or terminating registered. This IFC should be triggered for originating and terminating INVITEs therefore – can you please send me the Sprout debug logs for a call? To turn on debug logging create/edit the file /etc/clearwater/user_settings, add log_level=5 and then restart Sprout (service sprout stop – it’s automatically restarted by monit). Also, you don’t need this complicated a trigger if you just want to match all INVITEs – you could just use: <InitialFilterCriteria><TriggerPoint><ConditionTypeCNF>1</ConditionTypeCNF><SPT><ConditionNegated>0</ConditionNegated><Group>0</Group><Method>INVITE</Method></SPT></TriggerPoint><ApplicationServer><ServerName> sip:10.0.20.215</ServerName><DefaultHandling>0</DefaultHandling></ApplicationServer></InitialFilterCriteria > Ellie *From:* Franck Malka [mailto:[email protected] <[email protected]>] *Sent:* 05 January 2016 15:18 *To:* Eleanor Merry; [email protected] *Subject:* RE: [Clearwater] Configuration of iFCs rules Thanks Ellie, I reviewed the spec and the links provided. But I could not reach a situation where the application server gets notified of both originating and terminating SIP INVITEs… This is the trigger I used lastly. <InitialFilterCriteria><TriggerPoint><ConditionTypeCNF>1</ConditionTypeCNF><SPT><ConditionNegated>0</ConditionNegated><Group>0</Group><Method>INVITE</Method></SPT><SPT><ConditionNegated>0</ConditionNegated><Group>0</Group><Method>MESSAGE</Method></SPT><SPT><ConditionNegated>0</ConditionNegated><Group>0</Group><Method>SUBSCRIBE</Method></SPT><SPT><ConditionNegated>0</ConditionNegated><Group>1</Group><Method>INVITE</Method></SPT><SPT><ConditionNegated>0</ConditionNegated><Group>1</Group><Method>MESSAGE</Method></SPT><SPT><ConditionNegated>0</ConditionNegated><Group>1</Group><SessionCase>0</SessionCase></SPT><SPT><ConditionNegated>0</ConditionNegated><Group>1</Group><SessionCase>1</SessionCase></SPT></TriggerPoint><ApplicationServer><ServerName> sip:10.0.20.215</ServerName><DefaultHandling>0</DefaultHandling></ApplicationServer></InitialFilterCriteria > Is there a known issue getting the terminating party SIP INVITEs? -Franck. *From:* Eleanor Merry [mailto:[email protected]] *Sent:* Thursday, October 1, 2015 3:08 PM *To:* Franck Malka <[email protected]>; [email protected] *Subject:* RE: [Clearwater] Configuration of iFCs rules Hi Franck, We’ve got some examples of iFC configuration in http://clearwater.readthedocs.org/en/stable/Configuring_an_Application_Server/index.html#direct-configuration-via-curl and https://github.com/Metaswitch/memento/blob/dev/docs/memento_overview.md#configuration/. For a full description of how to configure iFCs, I recommend that you check out TS 29.228 (release 10, Annex C and F). Ellie *From:* Clearwater [mailto:[email protected] <[email protected]>] *On Behalf Of *Franck Malka *Sent:* 01 October 2015 12:31 *To:* [email protected] *Subject:* [Clearwater] Configuration of iFCs rules Hi, I could not find in the doc pages a full guide for the configuration of iFC rules. I need to configure a rule for 3rd party registrar and for MMTel Conferencing. I there some information available around this topic somewhere? -Franck.
_______________________________________________ Clearwater mailing list [email protected] http://lists.projectclearwater.org/mailman/listinfo/clearwater_lists.projectclearwater.org
