https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5208
Huang Qiangxiong <qiangxiong.huang@xxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #5234| |review_for_checkin?
Flag| |
--- Comment #6 from Huang Qiangxiong <qiangxiong.huang@xxxxxxxxx> 2010-09-29 10:27:21 PDT ---
Created an attachment (id=5234)
--> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=5234)
Patch for correctly dissecting rtp dynamic payload type which setup by rtsp
session
I make the patch based on the newest wireshark source
(http://anonsvn.wireshark.org/wireshark/trunk).
This patch should be able to resolve all problems that RTP can not
automatically correctly dissect the dynamic payload while the RTP conversations
is setup by RTSP conversation.
Following are situations that RTSP setup RTP conversations:
(1) SDP is present in the reply message of RTSP DESCRIBE method.
You can test it with attachment "rtsp_sdp_in_DESCRIBE_reply_quicktime.pcap".
How it work: In rtsp dissector, we save each base_url (rtsp url) of request and
response transaction. While calling SDP dissector, SDP will call a function
provided by rtsp dissector to save (rtsp_url to dyn_payload_info) relation in a
global map (binarytree). Later, when rtsp setup a rtp conversation, it can
according to its rtsp_url to find a correct dynamic payload type information
and passed it to rtp_add_address().
(2) SDP is present in a HTTP reply message. RTSP Client setup RTSP conversation
according to "a=control:" attribute of SDP.
You can test it with attachment "rtsp_sdp_in_http_reply_quicktime.pcap".
How it work: Similar to (1), when SDP dissector is being called before RTSP
session, it will call the function provied by rtsp dissector to save the
rtsp_url(from "a=control:rtsp://xxx") to dyn_payload_info relation in a global
map. RTSP dissector will use it during dissecting SETUP request (or reply)
message to create RTP conversation.
(3) SDP is present in a RTSP ANNOUNCE request message. I don't have this kind
of capture file, so I didn't test it, but this situation should have been
covered by this patch.
How it work: same as (1).
(4) RTP packet is interleaved in RTSP connection.
You can test it with attachment "rtsp_interleaved_coreplayer.cap".
How it work: different from previous situations, interleaved rtp conversation
can not be setup by ip+port. So we have to find the dynamic payload information
by interleaved_channel_num->rtsp_url->dyn_payload_info while dissecting a
interleaved rtsp packet, and transfer dyn_payload_info to rtp dissector which
saves it in per packet data. while rtp dissector is called, it retrieve
dyn_payload_info from per packet data.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
