[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