> The VoIP calls analysis function registers taps for different protocols
that can be
> inside the same packet -e.g. SIP and SDP, or MTP and ISUP-. Would the
patch affect the
> behaviour in this case?
Well, no, unless your code relies on the specific "undefined" tap call order
we had till now ;-)
It was: The protocol item which called tap_queue_packet last got its tap
called first (LIFO).
I suggest changing it to calling the taps in strictly the same order as the
different dissectors call "tap_queue_packet" for a given packet (FIFO).
Since most dissectors call tap_queue_packet at the very end of dissection
(after having called sub-dissectors) that might brake some code that uses
taps at different protocol levels and shares state information among these
(and relies on taps of higher level protocols beign called *before* lower
level protocols).
Again, if this is the case, the code *was* already broken with regard to the
current documentation in which the order of tap listeners is explicitly
stated as "undefined".
Could you check if that might be a problem for VoIP calls?
regards,
Lars Ruoff
>
> Regards,
> Francisco
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev