Hello,
my question is related to Bug 11446 and behaving I'm observing with
attached sample.
The issue (demonstrated with my sample) is how RTP stream is decoded
when RTP stream starts before SIP with SDP is captured (you start
capture in mid of session).
My sample:
#1 - RTP packed (172.16.176.24:5012->172.16.176.11:8204)
#2-#4 - SIP with SDP
#5 - RTP packet (172.16.176.24:5012->172.16.176.11:8204)
Nowadays #1 and #5 is shown as UDP.
Expected behaving is that #1 can be shown as UDP, but #5 should be
shown as RTP packet (or #1 and #5 can be shown as RTP packet).
I analysed the code and found that for #1 is created "full"
conversation (full = SRC_IP:SRC_PORT <-> DST_IP:DST_PORT) with UDP as
protocol.
SIP/SDP analyse then tries to find conversation for proposed media,
but only in half way (SRC_IP:SRC_PORT or DST_IP:DST_PORT). As
consequence of it (my understanding), it do not find it and creates new
"half" conversation with RTP protocol.
When #5 is decoded, the "full" conversation is found and it is decoded
as UDP then.
Is there a way how to solve it?
I know that there is option for conversation to set packet number from
which is conversation valid. But it do not work in this case, because
"full" conversation does exists.
Sincerely yours,
Jirka Novak
Attachment:
x4.pcapng.gz
Description: Unix tar archive