[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