Re: [Project Clearwater] Is it a bug that Clearwater invalidates the ODI once it receives 200 ok response?

[Anthony Lee]

I see, thanks for the  clarification and the suggestion.
I'll try it.

On Mar 6, 2018 09:16, "Bennett Allen"  wrote:

> Hi Anthony,
>
> We've had a look in the 3GPP specs to confirm whether Clearwater is doing
> the right thing here, and TS 23.218 section 5.2.3 states:
>
> "If an Application Server decides to locally terminate a request and sends
> back a final response for that request via the ISC interface to the S-CSCF,
> the S-CSCF shall abandon verification of the matching of the triggers of
> lower priority in the list.
> NOTE 4:  If AS has service logic whereby it wishes to send a request to
> the S-CSCF to continue with filter criteria evaluation from where it left
> off with the final response to the previous request, then a new request
> must be sent with data that can be used by the S-CSCF to determine where it
> left off with filter criteria evaluation.  For example, a parameter can be
> included in the request that is also defined in a service point trigger."
> I think this is describing the situation you're in - your AS has sent a
> final response (the 200 OK), and now "wishes to send a request to the
> S-CSCF to continue with filter criteria evaluation from where it left off
> with the final response to the previous request". The specs suggest that
> what you're currently doing, checking a parameter in the service point
> trigger, is the right approach.
>
> Instead of checking the P-Served-User header, one thing we've seen that
> works well is to have the application server add an extra header when it
> re-originates the request, checking for that header in the IFCs, and
> skipping the application server if it's present. For example:
>
> 
> 1
> 2
> 
> X-ContinueFC
> orig
> 
> 
> 
>
> Let us know how it goes,
> Ben
>
>
>
> -Original Message-
> From: Clearwater [mailto:clearwater-boun...@lists.projectclearwater.org]
> On Behalf Of clearwater-requ...@lists.projectclearwater.org
> Sent: 05 March 2018 21:55
> To: clearwater@lists.projectclearwater.org
> Subject: Clearwater Digest, Vol 59, Issue 10
>
> Send Clearwater mailing list submissions to
> clearwater@lists.projectclearwater.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.projectclearwater.org/mailman/
> listinfo/clearwater_lists.projectclearwater.org
>
> or, via email, send a message with subject or body 'help' to
> clearwater-requ...@lists.projectclearwater.org
>
> You can reach the person managing the list at
> clearwater-ow...@lists.projectclearwater.org
>
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of Clearwater digest..."
>
>
> Today's Topics:
>
>1. Re: Is it a bug that Clearwater invalidate the ODI once it
>   receives 200OK response? (Anthony Lee)
>2. Re: Problems in manual installation of clearwater
>   (Richard Whitehouse (projectclearwater.org))
>
>
> --
>
> Message: 1
> Date: Mon, 5 Mar 2018 12:06:40 -0500
> From: Anthony Lee 
> To: "Richard Whitehouse (projectclearwater.org)"
> 
> Cc: "clearwater@lists.projectclearwater.org"
> 
> Subject: Re: [Project Clearwater] Is it a bug that Clearwater
> invalidate the ODI once it receives 200OK response?
> Message-ID:
>  mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Richard,
>
> My application server is doing RCS Message Store and Forward, it have two
> roles: Originating and Terminating.
> When it act as terminating role(let's called it TPF) it provides
> Store-and-Forward: it accepts the Invite request from the network and act
> as below:
>  1. if the user is in registered state,
> sends 200OK response to the network, sends a new Invite request to
> the user;
>
>  2. if the user is not in registered state,
> sends 200OK response to the network.
>
> After the Sip session is established TPF store the MSRP messages it
> received when the receiver is in unregistered state and will send the
> message(s) to the receiver once he registers.
>
> Now when I tested my application server with Clearwater the 200OK from TPF
> let Clearwater believes that the transaction is finished and Clearwater
> invalidats OID for the service chain and this makes my application server
> can't execute the rest service after it sends 200OK back to Clearwater's
> scscf.
>
> In the TS spec I don't find any suggestion that this behavior should be
> supported or should not be supported.
> My understanding is that while the 200OK response does mean the SIP
> transaction is done but  it doesn't mean the service chain 

Re: [Project Clearwater] Could not get subscriber data from HSS

[Bennett Allen]

charge-term>
Record-Route: 
<sip:scscf.sprout.clearwater.local:5054;transport=TCP;lr;billing-role=charge-orig>
Record-Route: <sip:10.67.79.17:5058;transport=TCP;lr>
Record-Route: 

Call-ID: 1-21165@10.67.79.16
From: <sip:277012@clearwater.opnfv>;tag=21165SIPpTag001
To: 
<sip:277015@clearwater.opnfv>;tag=z9hG4bKPjtk6L-d0QjzkZB8rbq-CMdJGW9zpHhMbt
CSeq: 1 INVITE
Content-Length:  0


Total calls: 1
Successful calls: 0 (0.0%)
Failed calls: 1 (100.0%)
Unfinished calls: 0

Retransmissions: 0

Average time from INVITE to 180 Ringing: 0.0ms # of calls with 0-2ms from 
INVITE to 180 Ringing: 0 (0.0%) # of calls with 2-10ms from INVITE to 180 
Ringing: 0 (0.0%) # of calls with 10-20ms from INVITE to 180 Ringing: 0 (0.0%) 
# of calls with 20-50ms from INVITE to 180 Ringing: 0 (0.0%) # of calls with 
50-100ms from INVITE to 180 Ringing: 0 (0.0%) # of calls with 100-200ms from 
INVITE to 180 Ringing: 0 (0.0%) # of calls with 200-500ms from INVITE to 180 
Ringing: 0 (0.0%) # of calls with 500-1000ms from INVITE to 180 Ringing: 0 
(0.0%) # of calls with 1000-2000ms from INVITE to 180 Ringing: 0 (0.0%) # of 
calls with 2000+ms from INVITE to 180 Ringing: 0 (0.0%)
Failed: call success rate 0.0% is lower than target 100.0%!

Total re-REGISTERs: 5
Successful re-REGISTERs: 5 (100.0%)
Failed re-REGISTERS: 0 (0.0%)

REGISTER retransmissions: 0

Average time from REGISTER to 200 OK: 12.0ms


Thanks,
Linda

???: wang wulin <wangwu...@hotmail.com>
: 2018?3?2? 15:38
???: clearwater@lists.projectclearwater.org
??: [Clearwater] Could not get subscriber data from HSS


Hi Clearwater Team,


I deployed a stress node according to this guidance: 
http://clearwater.readthedocs.io/en/stable/Clearwater_stress_testing.html, and 
tried to run stress via "nice -n-20 /usr/share/clearwater/bin/sipp -i 
10.67.79.16 -sf ./sip-stress.xml 10.67.79.17 -t tn -s clearwater.opnfv -inf 
./users.csv.1 -users 1000 -m 1000 -default_behaviors all,-bye -max_socket 65000 
-max_reconnect -1 -reconnect_sleep 0 -reconnect_close 0 -send_timeout 4000 
-recv_timeout 12000 ".

"Register" works now, but Call step still failed, please see below for detailed 
info: https://hastebin.com/inekabihin.sql

2018-03-05  22:55:36:1311520290536.131506: Aborting call on unexpected 
message for Call-Id '679-28944@10.67.79.16': while expecting 'INVITE' (index 
23), received 'SIP/2.0 480 Temporarily Unavailable
Via: SIP/2.0/TCP 
10.67.79.16:8412;rport=8412;received=10.67.79.16;branch=z9hG4bK-201642-679-30.00-1
Record-Route: 
<sip:scscf.sprout.clearwater.local:5054;transport=TCP;lr;billing-role=charge-term>
Record-Route: 
<sip:scscf.sprout.clearwater.local:5054;transport=TCP;lr;billing-role=charge-orig>
Record-Route: <sip:10.67.79.17:5058;transport=TCP;lr>
Record-Route: 
<sip:n409qMON4B@bono-i2sn7d.clearwater.local:5060;transport=TCP;lr>
Call-ID: 201642-30.00///679-28944@10.67.79.16
From: <sip:201642@clearwater.opnfv>;tag=28944SIPpTag006791234
To: 
<sip:201643@clearwater.opnfv>;tag=z9hG4bKPj33yF8tC.WrHnJKCwT2P.NJawKhULQPY1
CSeq: 546 INVITE
Content-Length:  0


 I got the error from /var/log/sprout: "Error hssconnection.cpp:704: Could not 
get subscriber data from HSS"


I only executed the 4 commands below on Vellum Node:
1)  . /etc/clearwater/config; for DN in {277000..277099} ; do echo 
sip:$DN@$home_domain,$d...@clearwater.opnf<mailto:d...@clearwater.opnf>v,clearwater.opnfv,7kkzTyGW
 ;done > users.csv
2) cd /usr/share/clearwater/crest-prov/src/metaswitch/crest/tools/ && python 
bulk_create.py users.csv
3) ./users.create_xdm.sh
4) ./users.create_homestead.sh

Did I miss some other steps?
Do you know if we "HSS" node is also required?


2)

I also got the error from Dime node:


root@dime-5y29tl:/var/log/ralf# vim /var/log/syslog Mar  2 06:37:01 dime-5y29tl 
issue-alarm: zmq_msg_recv: Invalid argument Mar  2 06:37:02 dime-5y29tl 
config-manager[10778]: dropped request: 'issue-alarm config-manager 8500.3'
Mar  2 06:37:08 dime-5y29tl issue-alarm: zmq_msg_recv: Invalid argument Mar  2 
06:37:18 dime-5y29tl issue-alarm: message repeated 12 times: [ zmq_msg_recv: 
Invalid argument] Mar  2 06:37:18 dime-5y29tl queue-manager[10648]: dropped 
request: 'issue-alarm queue-manager 9001.1'
Mar  2 06:37:21 dime-5y29tl queue-manager[10648]: dropped request: 'issue-alarm 
queue-manager 9002.1'
Mar  2 06:37:22 dime-5y29tl issue-alarm: zmq_msg_recv: Invalid argument

root@dime-5y29tl:/var/log/ralf# vim /var/log/monit.log
[UTC Mar  2 02:31:43] error: 'poll_etcd_cluster' 
'/usr/share/clearwater/bin/poll_etcd_cluster.sh' failed with exit status (1) -- 
1
[UTC Mar  2 02:31:43] info : 'poll_etcd_cluster' exec: /bin/bash
[UTC Mar  2 02:31:53] info : 'poll_etcd_cluster' status succeeded 
[status=0] -- zmq_msg_recv: Resource temporarily unavailable


Any help w

Re: [Project Clearwater] Is it a bug that Clearwater invalidates the ODI once it receives 200 ok response?

[Bennett Allen]

Hi Anthony, 

We've had a look in the 3GPP specs to confirm whether Clearwater is doing the 
right thing here, and TS 23.218 section 5.2.3 states:

"If an Application Server decides to locally terminate a request and sends back 
a final response for that request via the ISC interface to the S-CSCF, the 
S-CSCF shall abandon verification of the matching of the triggers of lower 
priority in the list.
NOTE 4:  If AS has service logic whereby it wishes to send a request to the 
S-CSCF to continue with filter criteria evaluation from where it left off with 
the final response to the previous request, then a new request must be sent 
with data that can be used by the S-CSCF to determine where it left off with 
filter criteria evaluation.  For example, a parameter can be included in the 
request that is also defined in a service point trigger."
I think this is describing the situation you're in - your AS has sent a final 
response (the 200 OK), and now "wishes to send a request to the S-CSCF to 
continue with filter criteria evaluation from where it left off with the final 
response to the previous request". The specs suggest that what you're currently 
doing, checking a parameter in the service point trigger, is the right approach.

Instead of checking the P-Served-User header, one thing we've seen that works 
well is to have the application server add an extra header when it 
re-originates the request, checking for that header in the IFCs, and skipping 
the application server if it's present. For example:


1
2

X-ContinueFC
orig




Let us know how it goes,
Ben



-Original Message-
From: Clearwater [mailto:clearwater-boun...@lists.projectclearwater.org] On 
Behalf Of clearwater-requ...@lists.projectclearwater.org
Sent: 05 March 2018 21:55
To: clearwater@lists.projectclearwater.org
Subject: Clearwater Digest, Vol 59, Issue 10

Send Clearwater mailing list submissions to
clearwater@lists.projectclearwater.org

To subscribe or unsubscribe via the World Wide Web, visit

http://lists.projectclearwater.org/mailman/listinfo/clearwater_lists.projectclearwater.org

or, via email, send a message with subject or body 'help' to
clearwater-requ...@lists.projectclearwater.org

You can reach the person managing the list at
clearwater-ow...@lists.projectclearwater.org

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of Clearwater digest..."


Today's Topics:

   1. Re: Is it a bug that Clearwater invalidate the ODI once it
  receives 200OK response? (Anthony Lee)
   2. Re: Problems in manual installation of clearwater
  (Richard Whitehouse (projectclearwater.org))


--

Message: 1
Date: Mon, 5 Mar 2018 12:06:40 -0500
From: Anthony Lee 
To: "Richard Whitehouse (projectclearwater.org)"

Cc: "clearwater@lists.projectclearwater.org"

Subject: Re: [Project Clearwater] Is it a bug that Clearwater
invalidate the ODI once it receives 200OK response?
Message-ID:

Content-Type: text/plain; charset="utf-8"

Hi Richard,

My application server is doing RCS Message Store and Forward, it have two
roles: Originating and Terminating.
When it act as terminating role(let's called it TPF) it provides
Store-and-Forward: it accepts the Invite request from the network and act as 
below:
 1. if the user is in registered state,
sends 200OK response to the network, sends a new Invite request to the 
user;

 2. if the user is not in registered state,
sends 200OK response to the network.

After the Sip session is established TPF store the MSRP messages it received 
when the receiver is in unregistered state and will send the message(s) to the 
receiver once he registers.

Now when I tested my application server with Clearwater the 200OK from TPF let 
Clearwater believes that the transaction is finished and Clearwater invalidats 
OID for the service chain and this makes my application server can't execute 
the rest service after it sends 200OK back to Clearwater's scscf.

In the TS spec I don't find any suggestion that this behavior should be 
supported or should not be supported.
My understanding is that while the 200OK response does mean the SIP transaction 
is done but  it doesn't mean the service chain is done.

About when or what should trigger the invalidation of OID, maybe invalidate OID 
once there is no more iFC is matched with the request for the terminating 
session case?

Currently I'm using a walk around to make Clearwater continue to check the rest 
iFCs:

 
0
52

  P-Served-User