["Keith French" <keithfrench@xxxxxxxxxxxxx>]

Martin,

 

Sorry I didn't realise that RTP only used even port numbers.

 

So back to my question why should this packet from UDP source port 6996 to destination port 26642 be decoded as DPLAY and not RTP?

 

Keith.

----- Original Message -----

From: Martin Mathieson

To: Community support list for Wireshark

Sent: Friday, April 11, 2008 2:09 PM

Subject: Re: [Wireshark-users] RTP decoded as DPLAY in V1.0.0

On Fri, Apr 11, 2008 at 1:57 PM, Keith French <keithfrench@xxxxxxxxxxxxx> wrote:

Martin,

 

No they do not show up only as UDP. They decode as DPLAY on port 26642, not RTP as they should. I do have the ""Try to decode RTP outside of conversations" ticked.

 

I should have read the thread more carefully from the start, Japp's advice is good.
 

I'm not sure what you mean about both ports being even numbered? The source is 6996 and the destination is 26642. However, the source port could be odd or even in the 6xxx range.

Section 11 from RFC 3550 says:

RTP relies on the underlying protocol(s) to provide demultiplexing of

   RTP data and RTCP control streams.  For UDP and similar protocols,
   RTP SHOULD use an even destination port number and the corresponding
   RTCP stream SHOULD use the next higher (odd) destination port number.

Also the start of section 8 from RFC 3551:

As specified in the RTP protocol definition, RTP data SHOULD be

   carried on an even UDP port number and the corresponding RTCP packets
   SHOULD be carried on the next higher (odd) port number.

I've never seen RTP used on an odd-numbered port, so thought it was a reasonable assumption to add to the heuristic dissector to avoid false positives.

Regards,
Martin
 

 

Keith.

----- Original Message -----

From: Martin Mathieson

To: Community support list for Wireshark

Sent: Friday, April 11, 2008 1:39 PM

Subject: Re: [Wireshark-users] RTP decoded as DPLAY in V1.0.0

Are you seeing the frames as just UDP?

I did check in a change to the RTP heuristic dissector a before 1.0.

I loosened it up by making it accept PTs in the normal dynamic range (something like 96-127).
But I also tightened it by only accepting if both UDP ports were even-numbered.

Does this explain your problem?

On Fri, Apr 11, 2008 at 1:11 PM, Keith French <keithfrench@xxxxxxxxxxxxx> wrote:

Jaap,

I have tried the UDP preference "Try heuristic sub-dissectors first", but
didn't solve the problem. I always have the RTP preference "Try to decode
RTP outside of conversations" ticked.

Has anything changed in the dissectors in Wireshark V1.0.0, because it was
decoded as RTP fine in V0.99.8?

Keith.

----- Original Message -----
From: "Jaap Keuter" <jaap.keuter@xxxxxxxxx>
To: "Community support list for Wireshark" <wireshark-users@xxxxxxxxxxxxx>
Sent: Friday, April 11, 2008 10:26 AM
Subject: Re: [Wireshark-users] RTP decoded as DPLAY in V1.0.0


> Hi,
>
> This is really a conceptual problem. A port number is to be associated
> with its service. That concept break when talking about dynamic data
> ports, these are negotiated 'by other means'.
>
> Wireshark tries to pick up these negotiations, like SDP, and configure the
> dissectors accordingly.
> Otherwise it tries to heuristically determine the protocol. That is the
> case with the DirectPlay protocol, its not related to a specific port as
> you state.
>
> These methods aren't perfect. Therefor the dissectors are outfitted with
> preferences to help make Wireshark make the right choices. In this case
> the UDP preference "Try heuristic sub-dissectors first" might help, if
> switched off. Another may be of the RTP dissector, "Try to decode RTP
> outside of conversations".
>
> Yet another option is to select the DirectPlay protocol in the packet
> details pane and select "Disable protocol..." from the righthand click
> menu. That knocks out the DirectPlay dissector for this session. Or you
> can disable it completely from the Analyze|Enabled Protocols... menu
> option.
>
> Bottom line is: protocol usually give poor support for solid heuristics.
> With more and more protocols being dissected in Wireshark these collisions
> are bound to happen more often.
>
> Thanx,
> Jaap
>
>> Since Wireshark V1.0.0 (on Windows XP SP2) an RTP packet using UDP port
>> number 26642 is being decoded as DPLAY. This port number is in the range
>> used by Cisco for RTP. In V0.99.8 and before it has always been decoded
>> as
>> RTP.
>>
>> Obviously I can do a "Decode As" for the time being.
>>
>> I assume this is a bug, and if so I will raise it on there when bugzilla
>> is back up again.
>>
>> Keith French.
>
> _______________________________________________
> Wireshark-users mailing list
> Wireshark-users@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-users
>

--------------------------------------------------------------------------------


No virus found in this incoming message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.12/1373 - Release Date: 11/04/2008
09:17

_______________________________________________
Wireshark-users mailing list
Wireshark-users@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-users

---

_______________________________________________
Wireshark-users mailing list
Wireshark-users@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-users

---

No virus found in this incoming message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.12/1373 - Release Date: 11/04/2008 09:17

_______________________________________________
Wireshark-users mailing list
Wireshark-users@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-users

---

_______________________________________________
Wireshark-users mailing list
Wireshark-users@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-users

---

No virus found in this incoming message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.12/1373 - Release Date: 11/04/2008 09:17