Hi Lianjie, There is a reg_max_expires option that controls the maximum length of a registration. This defaults to 300 (seconds). To change this, edit /etc/clearwater/config on each of your sprout nodes and add reg_max_expires=<time in seconds>, and restart each of your sprouts (service sprout stop). You can see more about the configuration options at https://github.com/Metaswitch/clearwater-docs/wiki/Clearwater-Configuration-Options-Reference.
In the scenario in your second question, how is the call failing? Why is it not receiving a response from the client? Also, what version of Clearwater are you running? We've recently added timer C support which will destroy the transaction on timeout, which will fix up the unending retransmissions. For your third question, I'm not sure why the ACKs are failing. ACKs aren't subject to overload control, and if it was due to overload then I'd expect more of the 200 OK responses to be lost. Can you let me know where the ACKs are lost (e.g. Sprout->Bono, Bono->Client)? Also how loaded is the system at this point? Ellie -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Lianjie Cao Sent: 07 October 2014 16:51 To: [email protected] Cc: Sharma, Puneet Subject: [Clearwater] Clearwater with Sipp Hi, We are performing some stress tests using SIPp against a manual installation of Clearwater. The xml scenario file we use is a little bit different from call_load2.xml in clearwater-sip-stress test. We are trying to separate register unregister from invite and test them separately. But we ran into some strange behaviors during the our tests. 1. No matter what value we set to Expires field in REGISTER message, the 200 OK response only returns an Expires value no more than 300. So, our REGISTER can only be valid for no more than 5 minute. Is there a way to change this default setting? 2. If a call failed before 200 OK sent out, Bono keeps sending 180 Ringing message to our SIPp worker even after the whole SIPp session ends (SIPp uses UDP by default). And since the session ends, the 180 Ringing from Bono cannot be delivered to the right port number. This can last for a very long time. For most times, we have to reboot Bono to resolve this. 3. Base on our observation, most of the failed calls are due to timeout on ACK request from SIPp worker. Attached is one example and our script of ACK message. Is there any specific reason for this? Is that because ACK is received and sent by Sprout, but Sprout is heavily loaded at the moment? Thanks, Lianjie ------------------------------ Scenario Screen -------- [1-9]: Change Screen -- Call-rate(length) Port Total-time Total-calls Remote-host 160.0(0 ms)/1.000s 5060 69.96 s 9600 10.0.0.31:5060(UDP) Call limit reached (-m 9600), 0.000 s period 0 ms scheduler resolution 0 calls (limit 2400) Peak was 1120 calls, after 31 s 0 Running, 4751 Paused, 0 Woken up 2432 dead call msg (discarded) 27 out-of-call msg (discarded) 1 open sockets Messages Retrans Timeout Unexpected-Msg INVITE ----------> 9600 0 503 <---------- 0 0 61 0 403 <---------- 0 0 0 0 408 <---------- 0 0 0 0 100 <---------- 8877 0 0 0 INVITE <---------- 662 0 0 0 100 <---------- 662 0 0 0 INVITE <---------- 8877 24 0 0 180 ----------> 9539 24 503 <---------- 0 0 0 5 408 <---------- 0 0 0 0 180 <---------- 9534 0 0 0 200 ----------> 9534 0 503 <---------- 0 0 20 0 408 <---------- 0 0 0 0 200 <---------- 9514 0 0 0 ACK ----------> 9514 0 503 <---------- 0 0 2327 0 408 <---------- 0 0 0 0 ACK <---------- 7187 0 0 0 Pause [ 5000ms] 7187 0 BYE ----------> 7187 0 503 <---------- 0 0 46 0 408 <---------- 0 0 0 0 BYE <---------- 7141 0 0 0 200 ----------> 7141 0 503 <---------- 0 0 0 0 408 <---------- 0 0 0 0 200 <---------- 7141 0 0 0 ------------------------------ Test Terminated -------------------------------- ----------------------------- Statistics Screen ------- [1-9]: Change Screen -- Start Time | 2014-10-06 20:47:49.142762 1412653669.142762 Last Reset Time | 2014-10-06 20:48:59.108387 1412653739.108387 Current Time | 2014-10-06 20:48:59.108452 1412653739.108452 -------------------------+---------------------------+------------------ -------------------------+---------------------------+-------- Counter Name | Periodic value | Cumulative value -------------------------+---------------------------+------------------ -------------------------+---------------------------+-------- Elapsed Time | 00:00:00:000000 | 00:01:09:965000 Call Rate | 0.000 cps | 137.211 cps -------------------------+---------------------------+------------------ -------------------------+---------------------------+-------- Incoming call created | 0 | 0 OutGoing call created | 0 | 9600 Total Call created | | 9600 Current Call | 0 | -------------------------+---------------------------+------------------ -------------------------+---------------------------+-------- Successful call | 0 | 7141 Failed call | 0 | 2459 -------------------------+---------------------------+------------------ -------------------------+---------------------------+-------- Call Length | 00:00:00:000000 | 00:00:06:463000 ------------------------------ Test Terminated -------------------------------- <recv response="200" rrs="true"></recv> <!-- Client #1 sends ACK to Clearwater --> <send> <![CDATA[ ACK sip:[$peer_dn]@[local_ip]:[local_port];transport=[transport] SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=z9hG4bK-[pid]-[call_number]-1 [routes] From: <sip:[$my_dn]@[service]>;tag=[pid]caller[call_number] To: <sip:[$peer_dn]@[service]>;tag=[pid]callee[call_number] Call-ID: [call_id] CSeq: [cseq] ACK Max-Forwards: 70 Content-Length: 0 ]]> </send> <!-- Contact: <sip:[$my_dn]@[local_ip]:[local_port];transport=[transport]> --> <!-- Client #2 expects ACK from Clearwater --> <recv request="ACK"></recv> _______________________________________________ Clearwater mailing list [email protected] http://lists.projectclearwater.org/listinfo/clearwater _______________________________________________ Clearwater mailing list [email protected] http://lists.projectclearwater.org/listinfo/clearwater
