[reSIProcate-users] Unexpected TCP connection termination disturbing call setup

["Julio Cesar Esteves Cabezas" <jcabezas@xxxxxxxxxxxxx>]

Hello,

 

Context:

    We have an UA app. built on top of recon/resiprocate that uses SUBSCRIBE/NOTIFY between UAs of different users to share information of calls.

   

    An UA can share that information (via event packages like RFC4235) with as much as tens of other UAs.

    So any call setup operation in a UA triggers emission of several NOTIFYs to peer UAs.

    Those UAs use an SBC as server that mediates all SIP signalling.

   

    Our app runs in Windows 7 x86/64 boxes and we are using reSIProcate 1.8.5.

 

Problem:   

    Very often a call fails because the 200 OK does not arrive at the originating UA.

    Wireshark shows that after some sucessive NOTIFYs the origin UA terminates unexpectedly the TCP connection (FIN) not allowing some pending due NOTIFYs to be transmitted.

    Note that the terminated TCP connection is the same in use both for the call setup as for the several NOTIFYs.

   

    After that, the SBC tries repeatedly to set up a new TCP connection with the same UA TCP port but this is refused by the UA with TCP RST.

    So, the connection termination disturbs both the delivery of call setup SIP messages and full notification of state to peer UAs.

   

    We noticed that if the number of peer UAs is low (1 or 2) that problem does not occur, so it seems related in some way with the number of NOTIFYs that the UA has to issue rapidly on the connection.

   

    Is that a configuration to be tuned or a known bug at some layer of the reSIProcate - TCP/IP stack ?

   

    Attached zipped [resip.log] of an UA making an unsuccesful call to itself, showing messages probably associated with the problem at lines 5546, 5548 and 7794.

    I can also provide the Wireshark capture if wanted.

 

Many thanks,

Julio.   

Attachment: resip.log.zip
Description: Binary data