| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
|
Thanks! I'll try this out.
Regards, Krister Från: slgodin@xxxxxxxxx [slgodin@xxxxxxxxx] för Scott Godin [sgodin@xxxxxxxxxxxxxxx]
Skickat: den 29 augusti 2012 15:50 Till: Krister Jarl Kopia: resiprocate-devel@xxxxxxxxxxxxxxx Ämne: Re: [reSIProcate] Seg. fault in TransactionState Yup - it looks like reception of the 200 will clear the mNextTransmission storage and handleInternalCancel just blindly accesses it. This line of code modifies the branch parameter in the CANCEL for cases where we re-tranmitted an INVITE (with a new branch)
because of transport failure. I've corrected this by ensuring we move the transaction state to completed when we receive a 200 response. This will cause the stack to instead internally generate a 200 for the cancel to the TU, and not call handleInternalCancel
to send the CANCEL on the wire.
Can you try out the following patch?
Index: TransactionState.cxx
===================================================================
--- TransactionState.cxx
(revision 9869)
+++ TransactionState.cxx
(working copy)
@@ -1216,6 +1216,7 @@
sendToTU(sip); // don't delete msg
//terminateClientTransaction(mId);
mMachine = ClientStale;
+ mState = Completed;
// !bwc! We have a final response. We don't need either of
// mMsgToRetransmit or mNextTransmission. We ignore further
// traffic.
Thanks,
Scott
On Wed, Aug 29, 2012 at 3:27 AM, Krister Jarl
<kj@xxxxxxxxxxx> wrote:
|