I am using sipp to test the openser with the following result. It will create message 481 after a certain traffic. In what conditioin that openser will send 2 BYE to CISCO? When I increase the concurrent call to about 50, the system becomes unstable and almost hanged. I am concerning about the real loading of the openser. Does anyone can help me?
--------------my scenario---------- call: 3 / sec concurrent call: 30 total call made: 1002 failed call: 21 failure rate: 21/1002
From the log shown below, most of the error are created with message 481.
SIP/2.0 481 Call Leg/Transaction Does Not Exist
10.30.18.235 10.30.18.234 10.30.0.211 UA-------------------BYE--> openser -- BYE--> CISCO -- BYE --> CISCO <-- 481 -- CISCO UA <------------------- 481--openser
U 10.30.18.235:5060 -> 10.30.18.234:5060 BYE sip:936418703@10.30.0.211:5060 SIP/2.0. Via: SIP/2.0/UDP 10.30.18.235:5060;branch=z9hG4bK-104-10. Route: sip:10.30.18.234;ftag=104;lr=on;nat=yes. From: sipp sip:889642688756@10.30.18.235:5060;tag=104. To: sut sip:36418703@10.30.18.234:5060;tag=145085F8-1DF8. Call-ID: 104-13187@10.30.18.235. CSeq: 2 BYE. Contact: sip:889642688756@10.30.18.235:5060. Max-Forwards: 70. Subject: Performance Test. Content-Length: 0.
U 10.30.18.234:5060 -> 10.30.0.211:5060 BYE sip:936418703@10.30.0.211:5060 SIP/2.0. Record-Route: sip:10.30.18.234;ftag=104;lr=on. Via: SIP/2.0/UDP 10.30.18.234;branch=z9hG4bKadce.370d22c5.0. Via: SIP/2.0/UDP 10.30.18.235:5060;rport=5060;branch=z9hG4bK-104-10. From: sipp sip:889642688756@10.30.18.235:5060;tag=104. To: sut sip:36418703@10.30.18.234:5060;tag=145085F8-1DF8. Call-ID: 104-13187@10.30.18.235. CSeq: 2 BYE. Contact: sip:889642688756@10.30.18.235:5060. Max-Forwards: 69. Subject: Performance Test. Content-Length: 0.
U 10.30.18.234:5060 -> 10.30.0.211:5060 BYE sip:936418703@10.30.0.211:5060 SIP/2.0. Record-Route: sip:10.30.18.234;ftag=104;lr=on. Via: SIP/2.0/UDP 10.30.18.234;branch=z9hG4bKadce.370d22c5.0. Via: SIP/2.0/UDP 10.30.18.235:5060;rport=5060;branch=z9hG4bK-104-10. From: sipp sip:889642688756@10.30.18.235:5060;tag=104. To: sut sip:36418703@10.30.18.234:5060;tag=145085F8-1DF8. Call-ID: 104-13187@10.30.18.235. CSeq: 2 BYE. Contact: sip:889642688756@10.30.18.235:5060. Max-Forwards: 69. Subject: Performance Test. Content-Length: 0.
U 10.30.0.211:53419 -> 10.30.18.234:5060 SIP/2.0 481 Call Leg/Transaction Does Not Exist. Via: SIP/2.0/UDP 10.30.18.234;branch=z9hG4bKadce.370d22c5.0,SIP/2.0/UDP 10.30.18.235:5060;rport=5060;branch=z9hG4bK-104-10. From: sipp sip:889642688756@10.30.18.235:5060;tag=104. To: sut sip:36418703@10.30.18.234:5060;tag=145085F8-1DF8. Call-ID: 104-13187@10.30.18.235. CSeq: 2 BYE. Content-Length: 0.
U 10.30.18.234:5060 -> 10.30.18.235:5060 SIP/2.0 481 Call Leg/Transaction Does Not Exist. Via: SIP/2.0/UDP 10.30.18.235:5060;rport=5060;branch=z9hG4bK-104-10. From: sipp sip:889642688756@10.30.18.235:5060;tag=104. To: sut sip:36418703@10.30.18.234:5060;tag=145085F8-1DF8. Call-ID: 104-13187@10.30.18.235. CSeq: 2 BYE. Content-Length: 0.
Hello,
openser does not reply with 481 Call Leg/Transaction Does Not Exist in any circumstances. This is created by the gateway which has no active call matching the dialog attributes in BYE.
What do you mean by "unstable and almost hanged"? No more CPU? Memory? No message forwarding? Any error logs?
Cheers, Daniel
On 05/23/06 13:57, unplug wrote:
I am using sipp to test the openser with the following result. It will create message 481 after a certain traffic. In what conditioin that openser will send 2 BYE to CISCO? When I increase the concurrent call to about 50, the system becomes unstable and almost hanged. I am concerning about the real loading of the openser. Does anyone can help me?
--------------my scenario---------- call: 3 / sec concurrent call: 30 total call made: 1002 failed call: 21 failure rate: 21/1002
From the log shown below, most of the error are created with message 481.
SIP/2.0 481 Call Leg/Transaction Does Not Exist
10.30.18.235 10.30.18.234 10.30.0.211 UA-------------------BYE--> openser -- BYE--> CISCO -- BYE --> CISCO <-- 481 -- CISCO UA <------------------- 481--openser
U 10.30.18.235:5060 -> 10.30.18.234:5060 BYE sip:936418703@10.30.0.211:5060 SIP/2.0. Via: SIP/2.0/UDP 10.30.18.235:5060;branch=z9hG4bK-104-10. Route: sip:10.30.18.234;ftag=104;lr=on;nat=yes. From: sipp sip:889642688756@10.30.18.235:5060;tag=104. To: sut sip:36418703@10.30.18.234:5060;tag=145085F8-1DF8. Call-ID: 104-13187@10.30.18.235. CSeq: 2 BYE. Contact: sip:889642688756@10.30.18.235:5060. Max-Forwards: 70. Subject: Performance Test. Content-Length: 0.
U 10.30.18.234:5060 -> 10.30.0.211:5060 BYE sip:936418703@10.30.0.211:5060 SIP/2.0. Record-Route: sip:10.30.18.234;ftag=104;lr=on. Via: SIP/2.0/UDP 10.30.18.234;branch=z9hG4bKadce.370d22c5.0. Via: SIP/2.0/UDP 10.30.18.235:5060;rport=5060;branch=z9hG4bK-104-10. From: sipp sip:889642688756@10.30.18.235:5060;tag=104. To: sut sip:36418703@10.30.18.234:5060;tag=145085F8-1DF8. Call-ID: 104-13187@10.30.18.235. CSeq: 2 BYE. Contact: sip:889642688756@10.30.18.235:5060. Max-Forwards: 69. Subject: Performance Test. Content-Length: 0.
U 10.30.18.234:5060 -> 10.30.0.211:5060 BYE sip:936418703@10.30.0.211:5060 SIP/2.0. Record-Route: sip:10.30.18.234;ftag=104;lr=on. Via: SIP/2.0/UDP 10.30.18.234;branch=z9hG4bKadce.370d22c5.0. Via: SIP/2.0/UDP 10.30.18.235:5060;rport=5060;branch=z9hG4bK-104-10. From: sipp sip:889642688756@10.30.18.235:5060;tag=104. To: sut sip:36418703@10.30.18.234:5060;tag=145085F8-1DF8. Call-ID: 104-13187@10.30.18.235. CSeq: 2 BYE. Contact: sip:889642688756@10.30.18.235:5060. Max-Forwards: 69. Subject: Performance Test. Content-Length: 0.
U 10.30.0.211:53419 -> 10.30.18.234:5060 SIP/2.0 481 Call Leg/Transaction Does Not Exist. Via: SIP/2.0/UDP 10.30.18.234;branch=z9hG4bKadce.370d22c5.0,SIP/2.0/UDP 10.30.18.235:5060;rport=5060;branch=z9hG4bK-104-10. From: sipp sip:889642688756@10.30.18.235:5060;tag=104. To: sut sip:36418703@10.30.18.234:5060;tag=145085F8-1DF8. Call-ID: 104-13187@10.30.18.235. CSeq: 2 BYE. Content-Length: 0.
U 10.30.18.234:5060 -> 10.30.18.235:5060 SIP/2.0 481 Call Leg/Transaction Does Not Exist. Via: SIP/2.0/UDP 10.30.18.235:5060;rport=5060;branch=z9hG4bK-104-10. From: sipp sip:889642688756@10.30.18.235:5060;tag=104. To: sut sip:36418703@10.30.18.234:5060;tag=145085F8-1DF8. Call-ID: 104-13187@10.30.18.235. CSeq: 2 BYE. Content-Length: 0.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hi, Do you mean the 481 won't harm the system operation? Why openser creates 2 BYEs message instead of 1 and cause gateway to reponse 481?
From my case, my PC for testing is P3 1GHz and 384M ram. I find that
number of the RTP connection is related to CPU loading. Below data is captured using sipp. call: 3 / second concurrent: 30 CPU usage: 80% total call: 1000 unexpected message: 481
call: 4 /second concurrent: 90 CPU usage > 90% total call: 1000 unexpected message: 481 & 408
From the information above, CPU is the main factor of the number of
RTP session. What is the real implementation for using openser with mediaproxy to handle over 1000 RTP concurrent session?
Below is the screen dump about worst case in 4 calls /second. Sipp will quit with the following error Send: failed with Address family not supported by protocol Aborted -------------------------------------------------------- 4 new calls during 1.000 s period 2 ms scheduler resolution 32 concurrent calls (limit 108) Peak was 108 calls, after 105 s 483 out-of-call msg (discarded) 1 open sockets 102335 Total RTP pckts 285.516 last period RTP rate (kB/s)
Messages Retrans Timeout Unexpected-Msg INVITE ----------> 511 141 0 100 <---------- 624 0 74 180 <---------- 0 0 0 183 <---------- 295 0 0 200 <---------- E-RTD 431 129 0
ACK ----------> 431 129 [ NOP ] Pause [ 8000ms] 431 13 [ NOP ] Pause [ 1000ms] 392 8 BYE ----------> 384 809 7 403 <---------- 0 0 130 200 <---------- 247 0 0
------ [+|-|*|/]: Adjust rate ---- [q]: Soft exit ---- [p]: Pause traffic -----
Send: failed with Address family not supported by protocol Aborted
On 5/23/06, Daniel-Constantin Mierla daniel@voice-system.ro wrote:
Hello,
openser does not reply with 481 Call Leg/Transaction Does Not Exist in any circumstances. This is created by the gateway which has no active call matching the dialog attributes in BYE.
What do you mean by "unstable and almost hanged"? No more CPU? Memory? No message forwarding? Any error logs?
Cheers, Daniel
-
Daniel-Constantin Mierla -
unplug