Comment # 20
on bug 9920
from Hadriel Kaplan
(In reply to comment #19)
> I.e., those data structures are only needed on the first, sequential, pass
> through the packets, and are not needed by subsequent re-dissection of the
> packets?
That's a really good point. Yes you're right, it will be needed for
subsequent/random re-dissection.
Thinking about that, it raises another potential bug: RTP keeps the payload
type mapping info in the conversation, so what happens if in the same capture
the call ends, another one begins, and the new one uses the same IP:ports for
the RTP flows but with different payload type mappings?
My guess is it would replace the conversation info, and change the results of
the first call depending on what you click in the GUI. (I.e., if you select one
of the first call's RTP packets, it will probably dissect it using the second
call's mapping info; until you click the first call's SIP messages, at which
point it now dissects the second call's RTP using the first call's info)
I'd have to test that to be sure though - I'm just guessing.
It's not as unlikely a scenario as one might expect, since SIP SBCs, gateways,
and test equipment re-use the same IP:ports from previously ended calls in a
relatively short timeframe.
You are receiving this mail because:
- You are watching all bug changes.