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