| Bug ID |
9946
|
| Summary |
SDP inserts rtpmap dynamic payload info into wrong media channel
|
| Classification |
Unclassified
|
| Product |
Wireshark
|
| Version |
1.11.x (Experimental)
|
| Hardware |
All
|
| OS |
All
|
| Status |
UNCONFIRMED
|
| Severity |
Normal
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Build Information:
Paste the COMPLETE build information from "Help->About Wireshark", "wireshark
-v", or "tshark -v".
--
While investigating bug 9920, I noticed that in the 200 OK, the SDP dissector
is inserting the dynamic payload hash for the rtpmap into the wrong media
channel. It should be inserting it into channel #2, but it's inserting it for
channel #3.
This may be related to this comment I put in a while ago in packet-sdp.c:
/* XXX: I don't know why this was done here - I'm keeping it here in case
* removing it causes problems, but it's wrong. transport_info->media_count
* is already incremented in the while() loop above. Incrementing it
* again here will cause bugs. The name of this is misleading, because
* 'transport_info->media_count' is actually an index, not count.
* In other words, it's a 0-based number, of the current rtp channel.
* So debug printing shows bogus rtp channels get created and then later
* removed because luckily it knows they were bogus. But it will cause bugs
* because if we're not delaying, then for the SDP_EXCHANGE_ANSWER_ACCEPT
* run through this function, it will add new RTP channels at a +1 index,
* which will likely cause problems.
*/
You are receiving this mail because:
- You are watching all bug changes.
