http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1589
------- Comment #5 from takis.issaris@xxxxxxxxxxx 2007-05-09 09:16 GMT -------
Thanks for you explanation.
My apologies for my mistake. I was aware of the list of payload types, but
assumed that because of some other RFC, it might have become common use to use
99 as the payload type for H.264. And that was because initially, I wasn't
aware that Wireshark deducts the payload type name from the entire
conversation, not from the individual packets.
I do think that Wireshark is adding just a tiny bit to the confusion here, as
it shows "Payload type: H.264 (99)" when decoding the packets. As it shows
"Payload type: ITU G.711 PCMU (0)" for fixed payload types such as 0, this only
added to my impression that the name before the number in brackets was implying
equality. Honestly, I wouldn't know a better way to express in short that one
is the payload type number and the other is the actual deducted type from the
conversation... or maybe something like this:
Payload type: <the actual name and number from the rtp-parameters list>
And in case the number is a dynamic one (maybe also for the unassigned ones?)
show in a separate line the deducted payload type?
Deducted payload type: H.264
>From your suggestion I understood that I would have to modify the preferences,
to be able to stop Wireshark from interpreting the RTP packets as containing
Redundant Audio Data. But after modifying the 99 below into 98, 100, or 110
nothing changes.
Edit->Preferences->Protocols->RTP->Payload type for RFC2198: 99
I tried restarting Wireshark, checking if the parameter was still 110 and not
reset to 99, but it appears to make no difference in the decoding of the
packets, every packet still shows up as containing RFC2198: Redundant Audio
Data.
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
