reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate-users] TransactionState assert, sendCurrentToWire

Hi Krister,

Can you please try adding the following highlighted lines to processServerNonInvite, and see if this resolves the issue for you?

Scott


TransactionState::processServerNonInvite(TransactionMessage* msg)
{
   StackLog (<< "TransactionState::processServerNonInvite: " << msg->brief());

   if (isRequest(msg) && !isInvite(msg) && isFromWire(msg)) // retransmission from the wire
   {
      if (mState == Trying)
      {
         // ignore
         delete msg;
      }
      else if (mState == Proceeding || mState == Completed)
      {
         if(mIsAbandoned)
         {
            assert(mState == Completed);
            mIsAbandoned=false;
            // put a 500 in mNextTransmission
            SipMessage* req = dynamic_cast<SipMessage*>(msg);
            resetNextTransmission(Helper::makeResponse(*req, 500));
            sendCurrentToWire();
         }
         else
         {
            // We have already sent a 100, but we have just received a retransmission.  Requests 
            // likely crossed on the wire.  We need to respond with another 100, but the last one was
            // cleared so re-create the 100 now. 
            SipMessage* sip = dynamic_cast<SipMessage*>(msg);
            if (sip && mMsgToRetransmit.empty() && !mNextTransmission)
            {
               resetNextTransmission(make100(sip));
            }
            sendCurrentToWire();
         }
         delete msg;
      }

Scott


On Thu, Apr 11, 2013 at 5:40 AM, Krister Jarl <kj@xxxxxxxxxxx> wrote:
Hi!

I've finally found the cause of this problem. It's caused by the TU failing to respond to a CANCEL-request in time. When timer Trying fires mNextTransmission is deleted after 100 Trying is sent. If a retransmission of the CANCEL-request is then received from the wire there will be nothing around to respond with.

Steps to reproduce:

resiprocate/peer
<---INVITE
100--->
180--->
<---CANCEL
TU does not respond
100-->
<---CANCEL

Adding a fix similar to that in processServerInvite() (lines 1652-1656, tag 1.8.5) seems to fix the issue, but I'm not sure if this is the correct way.

Regards,
Krister
Från: Krister Jarl
Skickat: den 21 november 2012 09:41
Till: Scott Godin

Kopia: resiprocate-users@xxxxxxxxxxxxxxx
Ämne: Re: [reSIProcate-users] TransactionState assert, sendCurrentToWire

Hi Scott,

I'm afraid not.

Regards,
Krister
Från: slgodin@xxxxxxxxx [slgodin@xxxxxxxxx] för Scott Godin [sgodin@xxxxxxxxxxxxxxx]
Skickat: den 20 november 2012 18:17
Till: Krister Jarl
Kopia: resiprocate-users@xxxxxxxxxxxxxxx
Ämne: Re: [reSIProcate-users] TransactionState assert, sendCurrentToWire

Hi Krister,

It seems that mNextTransmission is being cleared out prematurely somehow.  Do you have a stack level log of this?

Scott


On Tue, Nov 20, 2012 at 4:34 AM, Krister Jarl <kj@xxxxxxxxxxx> wrote:
Hi,

we recently upgraded to 1.8.5 from 1.5, but we've found a rare issue where TransactionState fails in sendCurrentToWire. Our application logs show no hint on what has happened. Looking the TransactionState object in frame 3 it seems to be a CANCEL. I've applied the patch for the CANCEL issue reported earlier (http://list.resiprocate.org/archive/resiprocate-devel/msg08100.html)

#0  0x00007f6a2a99ded5 in raise () from /lib/libc.so.6
#1  0x00007f6a2a99f3f3 in abort () from /lib/libc.so.6
#2  0x00007f6a2a996dc9 in __assert_fail () from /lib/libc.so.6
#3  0x0000000000766e2f in resip::TransactionState::sendCurrentToWire (this=0x7f6a1fe40800) at TransactionState.cxx:2579
#4  0x000000000076840c in resip::TransactionState::processServerNonInvite (this=0x7f6a1fe40800, msg=0x7f6a1fa8acf0)
    at TransactionState.cxx:1461
#5  0x000000000076e388 in resip::TransactionState::process (controller=@0x7f6a1e309f70, message=0x7f6a1fa8acf0)
    at TransactionState.cxx:719
#6  0x000000000075fe8d in resip::TransactionController::process (this=0x7f6a1e309f70, timeout=-1)
    at TransactionController.cxx:141
#7  0x0000000000753c74 in resip::SipStack::processTimers (this=0x7f6a1e30db00) at SipStack.cxx:790

Regards,
Krister

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