https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7066
--- Comment #10 from Cristian Constantin <const.crist@xxxxxxxxxxxxxx> 2012-04-12 10:19:00 PDT ---
(In reply to comment #9)
> Obviously, WS is failing to set up the reverse conversation 10.72.0.22 ->
> 10.72.0.11 as T.38.
> It should have done so when parsing the SDP from frame 102 (SIP/200 OK).
cristian: actually the t38 conversation is stored and looked up based on:
- connection address in the sdp line "Connection information"
- port in the sdp line "Media Description"
this is done in the dissect_sdp, like this:
/* Add t38 conversation, if available and only if no rtp */
if((!pinfo->fd->flags.visited) && port!=0 && !set_rtp && is_t38 &&
is_ipv4_addr){
src_addr.data=(guint8*)&ipaddr;
if(t38_handle){
t38_add_address(pinfo, &src_addr, port, 0, "SDP", pinfo->fd->num);
}
}
the problem appears because in this capture there are two conversations having
the same key {10.72.0.14, 32516, UDP}:
- the one setup by the INVITE in frame 1 (rtp)
- the one setup by the 200-OK (re-INVITE) in frame 102 (t38)
when wireshark calls:
#0 try_conversation_dissector (addr_a=<optimized out>, addr_b=<optimized out>,
ptype=<optimized out>, port_a=<optimized out>, port_b=<optimized out>,
tvb=0x1bb4b60, pinfo=0x7fffffffd790, tree=0x0) at conversation.c:1154
#1 0x00007ffff58e79c4 in decode_udp_ports (tvb=0x1cd8000, offset=<optimized
out>, pinfo=0x7fffffffd790, tree=0x0, uh_sport=46230, uh_dport=32516,
uh_ulen=16) at packet-udp.c:238
#2 0x00007ffff58e80e3 in dissect (tvb=0x1cd8000, pinfo=0x7fffffffd790,
tree=0x0, ip_proto=<optimized out>) at packet-udp.c:589
#3 0x00007ffff52ecdc0 in call_dissector_through_handle (handle=0x14e2730,
tvb=0x1cd8000, pinfo=0x7fffffffd790, tree=0x0) at packet.c:419
#4 0x00007ffff52ed4a5 in call_dissector_work (handle=0x14e2730, tvb=0x1cd8000,
pinfo_arg=0x7fffffffd790, tree=0x0, add_proto_name=1) at packet.c:510
#5 0x00007ffff52edc4e in dissector_try_uint_new (sub_dissectors=<optimized
out>, uint_val=17, tvb=0x1cd8000, pinfo=0x7fffffffd790, tree=0x0,
add_proto_name=1) at packet.c:935
for the first t38 frame, the conversation is identified as:
(gdb) p *conversation
$27 = {next = 0x7fffe1ba79a0, last = 0x7fffe1ba79a0, index = 0, setup_frame =
1, data_list = 0x1b0e510, dissector_handle = 0x1234940, options = 3, key_ptr =
0x7fffe1ba2838}
(gdb) p *conversation->dissector_handle
$28 = {name = 0x7ffff5fe05d8 "rtp", is_new = 0, dissector = {old =
0x7ffff57ee270 <dissect_rtp>, new = 0x7ffff57ee270 <dissect_rtp>}, protocol =
0x12348f0}
obviously wrong.
not sure yet how this worked before my patch was applied.
maybe by looking for the conversation with the setup frame closest to the
current frame number. but is this _really_ correct?
cristian
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.