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

[Scott Godin <sgodin@xxxxxxxxxxxxxxx>]

Hi Julio,

There was a fix in 1.8.9 for this.  You can see from the logs that we are getting back WouldBlock from the write call and it wasn't handled properly:

07/10/2013 22:06:30 [Info] RESIP:TRANSPORT | 11964 | TcpConnection.cxx:97 | Failed write on 3776 Unknown error

07/10/2013 22:06:30 [Debug] RESIP:TRANSPORT | 11964 | Transport.cxx:156 | Would Block 

07/10/2013 22:06:30 [Info] RESIP:TRANSPORT | 11964 | Connection.cxx:168 | Write failed on socket: 3776, closing connection

07/10/2013 22:06:30 [Debug] RESIP:TRANSPORT | 11964 | ConnectionBase.cxx:93 | ConnectionBase::~ConnectionBase 0A730638

Note - the SBC will not be able to connect back to resip on the ephemeral port used for the outbound TCP connection towards the SBC.  resip will listen on the configured TCP port for inbound connections.

Scott

On Mon, Oct 7, 2013 at 9:51 PM, Julio Cesar Esteves Cabezas <jcabezas@xxxxxxxxxxxxx> wrote:

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.   

_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/