Hi Guys, me again,
I increased the pause in uas after RINGING to 1000 milliseconds. With this
value, works fine if I send 15 cps BUT if I send 25 I have to increase the
pause to 2000 milliseconds.
<send>
<![CDATA[
SIP/2.0 180 Ringing
[last_Record-route]
[last_Via:]
[last_From:]
[last_To:];tag=[call_number]
[last_Call-ID:]
[last_CSeq:]
Contact: <sip:[local_ip]:[local_port];transport=[transport]>
Content-Length: 0
]]>
</send>
<pause milliseconds="2000"/>
If you see the first trace is kamailio who answers the BYE with a 404. Is
it like the call wasn't established?
Any help we'll be appreciated.
Thanks in advance.
Diego!
El El mié, 14 de dic. de 2016 a las 18:22, Diego Nadares <dnadares(a)gmail.com>
escribió:
Hi Mack,
The only thing I added to the basic scenarios is rrs="true"
In UAS
<recv rrs="true" request="INVITE" crlf="true">
In UAC
<recv response="200" rrs="true" crlf="true">
I use the same scenario with the same fields for every call. In a test of
6000 calls I see ~5 dead calls.
Diego
2016-12-14 17:28 GMT-03:00 Mack Hendricks <mack(a)dopensource.com>om>:
Hey Diego,
This smells like a sipP scenario file issue. Did you customize the the
scenario file being used by sipP B?
-Mack
On Dec 14, 2016, at 3:23 PM, Diego Nadares <dnadares(a)gmail.com> wrote:
Hi guys,
We are testing kamailio with sipp. We are running it with 20cps and some
calls do the following. When Kamailio is processing the 'ringing' a
'200ok'
arrives in the middle. First, kamailio forwards the 200 ok and then the
ringing. 'ACK' arrives and, I suppose, the call is established. The thing
is than when the 'BYE' arrives kamailio responds with a 404.
This is the summary of the call
Id Time Source Destination Protocol Len Info
6483 2016-12-14 11:26:06.264697 SIPP-A KAMAILIO SIP/SDP 692 Request:
INVITE sip:11111111@172.16.213.38:5060 |
6484 2016-12-14 11:26:06.264937 KAMAILIO SIPP-A SIP 367 Status: 100
trying -- your call is important to us |
6485 2016-12-14 11:26:06.266327 KAMAILIO SIPP-B SIP/SDP 1179 Request:
INVITE sip:22222222@172.16.213.31:5060 |
*6486 2016-12-14 11:26:06.267217 SIPP-B KAMAILIO SIP 566 Status: 180
Ringing | *
6487 2016-12-14 11:26:06.267268 SIPP-B KAMAILIO SIP/SDP 733 Status: 200
OK |
6488 2016-12-14 11:26:06.267758 KAMAILIO SIPP-A SIP/SDP 788 Status: 200
OK |
*6489 2016-12-14 11:26:06.267833 *KAMAILIO SIPP-A* SIP 442 Status: 180
Ringing | *
6490 2016-12-14 11:26:06.268868 SIPP-A KAMAILIO SIP 493 Request: ACK
sip:127.0.0.8;line=sr-N6IAzBFwMJZfWJZLM.M7MlF-W.y6Mx14NEt7Nw05NhPQKjaP |
6491 2016-12-14 11:26:06.269162 KAMAILIO SIPP-B SIP 609 Request: ACK
sip:172.16.213.31:5060;transport=UDP |
6492 2016-12-14 11:26:06.269614 SIPP-A KAMAILIO SIP 404 Request: BYE
sip:11111111@172.16.213.38:5060 |
6493 2016-12-14 11:26:06.269782 KAMAILIO SIPP-A SIP 348 Status: *404 Not
here* |
We are using modules rtjson, evapi, uac, topoh, rtpproxy for all calls. My
debug level is -1. With higher levels this behavior increase.
Kamailio is running in a virtual machine with centos7 with 8 cores and 8gb
of ram.
Do you need any further information? I can send you a pcap or ngrep file.
Best regards,
Diego.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users