[SR-Users] sipp dead calls

[Diego Nadares]

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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at lists.sip-router.org
>
>
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20161216/79a55ec5/attachment.html>