Re: [Project Clearwater] Failed to register to client (Zoiper5 and XLite)

[Bennett Allen]

Hi Pushpendra,
Firstly I have CC’d this onto the clearwater mailing list and please send all 
replies via this as otherwise your emails may not be seen by my colleagues or 
me!
In answer to your questions I don’t think what the ns value is matters so what 
you’ve got should be fine, and the second value using your bind IP looks good. 
It also doesn’t look like the DNS server/queries is the problem in your 
situation, as homestead is trying to contact the vellum node and failing there.
If you have a look at the logs on the vellum node for Cassandra, Astaire and 
Rogers, these are at /var/log/Cassandra/, /var/log/Astaire and /var/log/rogers. 
This should give a clue as to what is happening, as based on the monit.log they 
don’t look like they’re working properly.
Let us know how it goes,
Ben


From: Pushpendra [mailto:pushpendra16mn...@gmail.com]
Sent: 09 March 2018 11:06
To: Bennett Allen 
Subject: Failed to register to client (Zoiper5 and XLite)

Hi Ben,
I am able to login and create private identity on ellis, but when I am trying 
to register these identity on client app (zoiper5 an XLite), its not 
registered. Its in an endless loop. I am using  as domain while 
registering to client. Please find the log detail below:
Please let me what is wrong and how can I fix, thanks in advance ☺

[vellum]ubuntu@vellum:/var/log$ tail -40 monit.log
[IST Mar  7 23:54:05] error: 'cassandra_process' process is not running
[IST Mar  7 23:54:05] info : 'cassandra_process' trying to restart
[IST Mar  7 23:54:05] info : 'cassandra_process' restart: /bin/bash
[IST Mar  7 23:54:06] info : 'cassandra_process' process is running with 
pid 31746
[IST Mar  7 23:54:06] error: 'cassandra_uptime' 
'/usr/share/clearwater/infrastructure/monit_uptime/check-cassandra-uptime' 
failed with exit status (1) -- no output
[IST Mar  7 23:54:06] error: 'astaire_uptime' 
'/usr/share/clearwater/infrastructure/monit_uptime/check-astaire-uptime' failed 
with exit status (1) -- no output
[IST Mar  7 23:54:16] error: 'rogers_process' process is not running
[IST Mar  7 23:54:16] info : 'rogers_process' trying to restart
[IST Mar  7 23:54:16] info : 'rogers_process' restart: /bin/bash
[IST Mar  7 23:54:16] info : 'rogers_process' process is running with pid 
31827
[IST Mar  7 23:54:16] error: 'clearwater_cluster_manager_process' process 
is not running
[IST Mar  7 23:54:16] info : 'clearwater_cluster_manager_process' trying to 
restart
[IST Mar  7 23:54:16] info : 'clearwater_cluster_manager_process' restart: 
/bin/bash
[IST Mar  7 23:54:17] error: 'cassandra_process' process is not running
[IST Mar  7 23:54:17] info : 'cassandra_process' trying to restart
[IST Mar  7 23:54:17] info : 'cassandra_process' restart: /bin/bash
[IST Mar  7 23:54:17] info : 'cassandra_process' process is running with 
pid 32022
[IST Mar  7 23:54:17] error: 'cassandra_uptime' 
'/usr/share/clearwater/infrastructure/monit_uptime/check-cassandra-uptime' 
failed with exit status (1) -- no output
[IST Mar  7 23:54:17] error: 'astaire_uptime' 
'/usr/share/clearwater/infrastructure/monit_uptime/check-astaire-uptime' failed 
with exit status (1) -- no output
[IST Mar  7 23:54:27] error: 'rogers_uptime' 
'/usr/share/clearwater/infrastructure/monit_uptime/check-rogers-uptime' failed 
with exit status (1) -- no output
[IST Mar  7 23:54:27] info : 'clearwater_cluster_manager_process' process 
is running with pid 31936
[IST Mar  7 23:54:27] error: 'cassandra_process' process is not running
[IST Mar  7 23:54:27] info : 'cassandra_process' trying to restart
[IST Mar  7 23:54:27] info : 'cassandra_process' restart: /bin/bash
[IST Mar  7 23:54:28] info : 'cassandra_process' process is running with 
pid 32610
[IST Mar  7 23:54:28] error: 'cassandra_uptime' 
'/usr/share/clearwater/infrastructure/monit_uptime/check-cassandra-uptime' 
failed with exit status (1) -- no output
[IST Mar  7 23:54:28] error: 'astaire_uptime' 
'/usr/share/clearwater/infrastructure/monit_uptime/check-astaire-uptime' failed 
with exit status (1) -- no output
[IST Mar  7 23:54:38] error: 'rogers_uptime' 
'/usr/share/clearwater/infrastructure/monit_uptime/check-rogers-uptime' failed 
with exit status (1) -- no output
[IST Mar  7 23:54:38] error: 'cassandra_uptime' 
'/usr/share/clearwater/infrastructure/monit_uptime/check-cassandra-uptime' 
failed with exit status (1) -- no output
[IST Mar  7 23:54:39] info : 'astaire_uptime' status succeeded [status=0] 
-- zmq_msg_recv: Resource temporarily unavailable
[IST Mar  7 23:54:46

Re: [Project Clearwater] Does Clearwater support to provision wildcarded PSI?

[Bennett Allen]

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:7gbcen27b7lqvh3noa3nt8nftc7gbcen27b7lqvh3noa3nt8n...@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:7gbcen27b7lqvh3noa3nt8nftc7gbcen27b7lqvh3noa3nt8n...@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 
mailto: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 
mailto: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 
mailto: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

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

[Bennett Allen]

Hi Linda,
Thank you for all the information. It's interesting that it works with XLite 
but then not when you use SIPp. We would suggest having a look at the SIP 
invite messages for both methods (using a packet capture tool such as tcpdump) 
and seeing if you can spot any differences between them? If you can spot any 
differences this would give an idea of what needs changing in SIPp.
Let us know how it goes.
Thank you,
Ben



-Original Message-
From: Clearwater [mailto:clearwater-boun...@lists.projectclearwater.org] On 
Behalf Of clearwater-requ...@lists.projectclearwater.org
Sent: 07 March 2018 03:36
To: clearwater@lists.projectclearwater.org
Subject: Clearwater Digest, Vol 59, Issue 15

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: [Clearwater] Could not get subscriber data from HSS
  (wang wulin)


--

Message: 1
Date: Wed, 7 Mar 2018 03:35:15 +
From: wang wulin 
To: "clearwater@lists.projectclearwater.org"

Subject: Re: [Project Clearwater] [Clearwater] Could not get
subscriber data from HSS
Message-ID:



Content-Type: text/plain; charset="gb2312"

Hi Ben,


Sorry, I did not receive neither Adm's answer earlier nor your answer.  There 
seems something issue with my hotmail.

1) I deoloyed clearwater via one testcase named "cloudify_ims" from 
opnfv/functest project, where 3 steps are run:

   * deploy a VNF orchestrator (Cloudify)

   * deploy a Clearwater vIMS (IP Multimedia Subsystem) VNF from this 
orchestrator based on a TOSCA blueprint defined in [1]

   * run suite of signaling tests on top of this VNF

[1]: 
https://github.com/Orange-OpenSource/opnfv-cloudify-clearwater/archive/master.zip

8 instances are created and I also created a new instance named "stress_node" 
according to this guidance: 
http://clearwater.readthedocs.io/en/stable/Clearwater_stress_testing.html
Please see https://hastebin.com/edixewanip.rb for detailed instance info or 
below bash-4.3# openstack server list
+--+++--+--+---+
| ID   | Name   
| Status | Networks | Image 
   | Flavor|
+--+++--+--+---+
| 50b934e1-131f-4599-a7aa-85d744fda72c | stress_node
| ACTIVE | cloudify_ims_network=10.67.79.14 | ubuntu_14.04  
   | m1.small  |
| bc7da755-b58b-48a5-8258-dda0bdb2b92d | 
server_clearwater-opnfv_bono_host_zk2kcg   | ACTIVE | 
cloudify_ims_network=10.67.79.17, 192.168.33.211 | ubuntu_14.04 | 
m1.small  |
| 3fe2b0bf-4b12-42a1-8be7-a9222c46428f | 
server_clearwater-opnfv_sprout_host_s6a4tr | ACTIVE | 
cloudify_ims_network=10.67.79.20 | ubuntu_14.04 | 
m1.small  |
| c032dacd-eb8b-48a8-b314-9520f7ff64da | 
server_clearwater-opnfv_dime_host_kag04s   | ACTIVE | 
cloudify_ims_network=10.67.79.18 | ubuntu_14.04 | 
m1.small  |
| 7d09aa0f-bbeb-4b62-be56-95bfd097def0 | 
server_clearwater-opnfv_vellum_host_ldyhbh | ACTIVE | 
cloudify_ims_network=10.67.79.6  | ubuntu_14.04 | 
m1.small  |
| 3005c542-0ee5-4430-9f56-f221ccb1f104 | 
server_clearwater-opnfv_ellis_host_s7cahy  | ACTIVE | 
cloudify_ims_network=10.67.79.15, 192.168.33.201 | ubuntu_14.04 | 
m1.small  |
| 04b894ff-1c07-428a-9a8b-72db5335e843 | 
server_clearwater-opnfv_homer_host_m88cq7  | ACTIVE | 
cloudify_ims_network=10.67.79.9  | ubuntu_14.04 | 
m1.small  |
| 4614747e-2cb7-4450-837e-aa9c51af8e53 | 
server_clearwater-opnfv_bind_host_643c4w   | ACTIVE | 
cloudify_ims_network=10.67.79.10, 192.168.33.208 | ubuntu_14.04 | 
m1.small  |
| 8f26ed2c-8095-43b1-8c40-13ddc080fbc9 | 
server_clearwater-opnfv_proxy_host_nocslx  | ACTIVE | 
cloudify_ims_network=10.67.79.5  | ubuntu_14.04 | 
m1.small  |
| 7ae3612f-67a5-42c6-ab1b-94dbd067272a | cloudify_manager   
| ACTIVE | cloudify_ims_network=10.67.79.11, 192.168.33.207 | 
cloudify_manager_4.0 | m1.medium |
+---

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
  .+\;sescase=orig\;.+
   
 

The first time the request hits the terminating side the P-Served-User is 
there, the second time this header is not there so this 

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

[Bennett Allen]

Hi Linda,

Did you receive Adam's email, asking for additional logs and config which we'd 
need to debug this? 

He asked for:
*   The contents of /var/log/homestead/ on the Dime node, with potentially 
increased logging level, so we can spot errors when it reads from the Cassandra 
subscriber store.
*   The /etc/clearwater/shared_config config file.
*   The output of `sudo monit summary`.

Also, you mentioned a 'Bind Node' - this isn't part of Project Clearwater (you 
can see what is part of Project Clearwater at 
http://www.projectclearwater.org/technical/clearwater-architecture/). Could you 
confirm how you created this deployment - for example, was it from OpenStack 
Heat templates? 

Thanks,
Ben

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

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. ??: [Clearwater] 480 Temporarily Unavailable (wang wulin)


--

Message: 1
Date: Tue, 6 Mar 2018 02:05:30 +
From: wang wulin 
To: "Clearwater@lists.projectclearwater.org"

Subject: [Project Clearwater] ??: [Clearwater] 480 Temporarily
Unavailable
Message-ID:



Content-Type: text/plain; charset="gb2312"

I checked the syslog on Bind Node, it says:

Description: clearwater-cluster-manager is exiting due to missing 
configuration. @@Cause: clearwater-cluster-manager was started without the 
mandatory etcd_cluster_key parameter. @@Effect: Datastore cluster management 
services are no longer available. @@Action: Verify that the configuration file 
/etc/clearwater/local_config is correct according to the documentation.

Anyone would give some instructions about how to config etcd_cluster_key ?

Thanks,
Linda

???: wang wulin 
: 2018?3?6? 9:23
???: Clearwater@lists.projectclearwater.org
??: [Clearwater] 480 Temporarily Unavailable


Hi Clearwater Team,


I tried with "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"


and the statistics shows here: 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: 

Record-Route: 

Record-Route: 
Record-Route: 

Call-ID: 201642-30.00///679-28944@10.67.79.16
From: ;tag=28944SIPpTag006791234
To: 
;tag=z9hG4bKPj33yF8tC.WrHnJKCwT2P.NJawKhULQPY1
CSeq: 546 INVITE
Content-Length:  0

Thanks,
Linda

???: wang wulin 
: 2018?3?2? 16:39
???: clearwater@lists.projectclearwater.org
??: ??: [Clearwater] Could not get subscriber data from HSS


Hi Clearwater Team,


Here is the result after running ""/usr/share/clearwater/bin/run_stress 
clearwater.opnfv 16 10 "."


2018-03-02  08:25:12.757782 1519979112.757782: Aborting call on unexpected 
message for Call-Id '1-21165@10.67.79.16': while expecting '183' (index 2), 
received 'SIP/2.0 480 Temporarily Unavailable
Via: SIP/2.0/TCP 10.67.79.16:54572;received=10.67.79.16;branch=z9hG4bK-21165-1-0
Record-Route: 

Record-Route: 

Record-Route: 
Record-Route: 

Call-ID: 1-21165@10.67.79.16
From: ;tag=21165SIPpTag001
To: 
;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