Howdy,
I've been looking into bug 9835, which involves SIP+SDP setting up RTP conversations/flows. I've found 3 bugs so far in the relevant code areas, but the last one I'm stuck on looks like it's by design. It looks like the UDP dissector creates a addr:port-specific conversation for new packets, even if no protocol/heuristic ends up claiming its payload; and if that happens before a wildcarded conversation is added sometime later that would have matched the conversation, then it won't match it ever. Is that correct?
In other words, imagine you've got this:
Packet #1: UDP source addr:port A -> dest addr:port B, non-dissected payload.
Packet #2: SIP/SDP that sets up wildcarded RTP conversations for dest addr:port A, and another one for dest addr:port B; these should match packet #1 (in a second pass) and #3 and #4 in the first pass.
Packet #3: UDP source addr:port A -> dest addr:port B, matches "conversation" created by Packet #1, not the RTP one.
Packet #4: UDP source addr:port B -> dest addr:port A, matches "conversation" created by Packet #1, not the RTP one.
Am I understanding the code correctly? Is that the way it *should* work?
If so, I'll have to change the SIP/SDP logic. Currently it only creates the RTP conversations on receiving the SDP answer, instead of on the offer. But RTP can (and in fact often does) start flowing in the upstream direction based on the SDP offer, before an SDP answer is received.
-hadriel