Franck,
Ellie is away for the next week or so, so I'm replying in her absence.
I think the IFC you've specified (formatted below) should only send INVITEs
(not NOTIFYs) to the AS.
<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>
However, bear in mind that IFCs only apply for the first message of a dialog.
When the initial INVITE flows, we match these IFCs and decide to send the call
to the AS. At this point, the AS has a choice as to whether it adds a
"Record-Route" header to the INVITE.
· If the AS does add this header, all subsequent messages in the dialog
will be sent via the AS, no matter what the SIP message is or what the IFCs are.
· If the AS does not add this header, no further messages in the dialog
will be sent via the AS - not even re-INVITEs.
The Record-Route headers contain the "route set" that describes the route that
SIP messages follow.
Assuming that the REFER was sent in the same dialog as the INVITE, it would use
the same route-set as the INVITE, and the NOTIFY would then inherit this route
set too. As a result, it would go via the AS.
In other words, I don't think there's a way for bypassing the AS on this
in-dialog NOTIFY. However, I would expect the AS to propagate the NOTIFY - do
you know why that's not happening?
Incidentally, for more information on the Record-Route header, see RFC 3261,
section 20.30.
Please let me know if I've misunderstood the scenario (e.g. if the REFER is
out-of-dialog or if the AS did not Record-Route itself), or if you have any
questions.
Thanks,
Matt
From: Clearwater [mailto:[email protected]] On
Behalf Of Franck Malka
Sent: 20 January 2016 13:34
To: Eleanor Merry <[email protected]>
Cc: [email protected]
Subject: Re: [Clearwater] Configuration of iFCs rules
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<sip:10.0.20.215%3c/ServerName%3e%3cDefaultHandling%3e0%3c/DefaultHandling%3e%3c/ApplicationServer%3e%3c/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]<mailto:[email protected]>]
Sent: Tuesday, January 12, 2016 8:19 PM
To: Eleanor Merry
<[email protected]<mailto:[email protected]>>
Cc:
[email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>]
Sent: 08 January 2016 05:00
To:
[email protected]<mailto:[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]<mailto:[email protected]>> wrote:
Attached the requested logs:
-Franck.
From: Eleanor Merry
[mailto:[email protected]<mailto:[email protected]>]
Sent: Thursday, January 7, 2016 1:46 PM
To: Franck Malka <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[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]]
Sent: 07 January 2016 11:42
To: Eleanor Merry;
[email protected]<mailto:[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]<mailto:[email protected]>]
Sent: Thursday, January 7, 2016 1:35 PM
To: Franck Malka <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[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]]
Sent: 07 January 2016 10:17
To: Eleanor Merry;
[email protected]<mailto:[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]<mailto: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]<mailto: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]<mailto:[email protected]>]
Sent: Wednesday, January 6, 2016 3:51 PM
To: Eleanor Merry
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[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]<mailto:[email protected]>]
Sent: Wednesday, January 6, 2016 3:44 PM
To: Franck Malka <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[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<sip:10.0.20.215%3c/ServerName%3e%3cDefaultHandling%3e0%3c/DefaultHandling%3e%3c/ApplicationServer%3e%3c/InitialFilterCriteria>>
Ellie
From: Franck Malka [mailto:[email protected]]
Sent: 05 January 2016 15:18
To: Eleanor Merry;
[email protected]<mailto:[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<sip:10.0.20.215%3c/ServerName%3e%3cDefaultHandling%3e0%3c/DefaultHandling%3e%3c/ApplicationServer%3e%3c/InitialFilterCriteria>>
Is there a known issue getting the terminating party SIP INVITEs?
-Franck.
From: Eleanor Merry
[mailto:[email protected]<mailto:[email protected]>]
Sent: Thursday, October 1, 2015 3:08 PM
To: Franck Malka <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[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]] On
Behalf Of Franck Malka
Sent: 01 October 2015 12:31
To:
[email protected]<mailto:[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
