[reSIProcate] memory leak bug in TransactionState

Byron Campen bcampen at estacado.net
Thu Aug 24 15:16:02 CDT 2006


	Alright, suppose something sends us an INVITE with a non-matching,  
unknown method in CSeq. This will parse successfully, since it is  
well-formed. This INVITE will be sent up to the TU, which will reply  
(hopefully). Unfortunately, TransactionState ingores the response...

*snip*
    else if (isResponse(msg, 100, 699) && isFromTU(msg))
    {
       SipMessage* sip = dynamic_cast<SipMessage*>(msg);
       int code = sip->header(h_StatusLine).responseCode();
       switch (sip->header(h_CSeq).method())
       {
//...


          default:
             //StackLog (<< "Received response to non invite or  
cancel. Ignoring");
             delete msg;
             break;

*snip*


So, should the stack be verifying that the method in CSeq matches the  
request-line when a request comes in? This is the second bug I have  
found in the last hour or so that could be solved by adding this check.

Best regards,
Byron Campen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060824/31d7f5a9/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2369 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060824/31d7f5a9/attachment.bin>


More information about the resiprocate-devel mailing list