[reSIProcate] assert bug in TransactionState

Byron Campen bcampen at estacado.net
Thu Aug 24 14:52:49 CDT 2006


When a sip message comes off the state-machine fifo, we check to see  
whether it is for a CANCEL transaction, like so...

*snip*
    // This ensures that CANCEL requests form unique transactions
    if (sip && sip->header(h_CSeq).method() == CANCEL)
    {
       tid += "cancel";
    }

    TransactionState* state = 0;
    if (message->isClientTransaction()) state =  
controller.mClientTransactionMap.find(tid);
    else state = controller.mServerTransactionMap.find(tid);

*snip*

It is important to note that we are using the CSeq for both requests  
and responses here. However, if we look at the code for request- 
handling in processServerInvite, we see the following...

*snip*
    if (isRequest(msg) && isFromWire(msg))
    {
       SipMessage* sip = dynamic_cast<SipMessage*>(msg);
       switch (sip->header(h_RequestLine).getMethod())
       {
//...

          case CANCEL:
             assert(0);
             break;


*snip*

So, if someone sent us a CANCEL with the CSeq deliberately malformed  
to read something like
"CSeq: INVITE 1", we would not identify this as a CANCEL in the first  
block of code, and send this request to the original INVITE server  
transaction for processing. Then, the second block would cause us to  
assert, because it would see CANCEL in the request-line.

	I propose we write SipMessage::method(), which will check the  
Request line if it is a request, and the CSeq if it is a response.  
This would be the "correct" way to check the method of a SipMessage.

Best regards,
Byron Campen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060824/23be88e4/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/23be88e4/attachment.bin>


More information about the resiprocate-devel mailing list