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@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@dopensource.com:

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@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@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@lists.sip-router.org

http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users