Richard van der Hoff wrote:
You're absolutely right, there is a wee bit of a bug in there :/.
>
> <snip>
Yes, the h223-over-rtp capture is doing something a bit odd too - I'll
look into that. But it's not really supposed to look like it does under
0.99.4 - it depends on some new functionality that hasn't been committed
to trunk yet for proper dissection.
It's correct that it no longer attempts to dissect the payload as
RFC2198 data - this was a change committed by Anders on 1st Feb.
I'll do a bit more investigation and testing, then submit a new patch.
Along with this bug, identified by Mark, there is another problem, in
that one of the chunks of my earlier patch seemed to get missed off when
Anders committed it. This won't break anything yet, as the
H.223-over-RTP dissection hasn't landed on trunk yet, but it will cause
all sorts of nasties when it does.
Here is a new patch, against current trunk, which should fix Mark's bug,
my bug, and a comment typo. Please could this be applied ASAP.
Index: epan/dissectors/packet-rtp.c
===================================================================
--- epan/dissectors/packet-rtp.c (revision 12021)
+++ epan/dissectors/packet-rtp.c (working copy)
@@ -227,9 +227,8 @@
/* Try heuristic RTP decode */
static gboolean global_rtp_heur = FALSE;
- /* desegmnent RTP streams */
- static gboolean desegment_rtp = TRUE;
-
+/* desegment RTP streams */
+static gboolean desegment_rtp = TRUE;
/* RFC2198 Redundant Audio Data */
static guint rtp_rfc2198_pt = 99;
@@ -555,7 +554,7 @@
if(finfo == NULL || !desegment_rtp) {
/* Hand the whole lot off to the subdissector */
newtvb=tvb_new_subset(tvb,offset,data_len,data_reported_len);
- process_rtp_payload(tvb, pinfo, tree, rtp_tree, payload_type);
+ process_rtp_payload(newtvb, pinfo, tree, rtp_tree, payload_type);
return;
}
@@ -1746,6 +1745,8 @@
"Payload Type for RFC2198 Redundant Audio Data",
10,
&rtp_rfc2198_pt);
+
+ register_init_routine(rtp_fragment_init);
}
void
