2009/1/9 Daniel-Constantin Mierla <[email protected]>: > *But the CANCEL comes with the wrong CSeq: > > Probabky this kind of message has to be replied with 404 Bad message.
It would require matching the RURI line method against the CSeq method, so would decrese performance (not too much but...). I wouldn't implement it. For a CANCEL just the branch should be matched against current INVITE transactions (or CANCEL transaction if it's a CANCEL retransmission). Any reason for cheking more data in the CANCEL request? If the CANCEL doesn't match a current INVITE transaction (stateless proxy for example) then it must be processed as any other request, so an entire request check would be performed, but in case the CANCEL matches a transaction I don't see benefic on checking it. In fact, CANCEL is hop by hop, so Kamailio wouldn't forward that CANCEL but generate a new one. -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Kamailio (OpenSER) - Devel mailing list [email protected] http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
