Ed,
My primary interest is to add ethereal more rtp payloads. The problem
born to me when I had implemented a h263 dissector and was testing
it. I was using Darwin Streaming Server and QuickTime to analyze
traffic between both application, when I discovered Darwing managed
h263 as a dynamic payload, because of that Ethereal doesn't know
which is the real payload of the RTP stream.
The only one way I see to identify a dynamic payload is 'remember'
SDP description of the stream transmitted. To achieve it ethereal has
to had a 'SDP state' or something like that. When RTP dissector was
called to analyze a RTP packet and sees a dynamic payload, it'll ask
to SDP dissector about the real payload of the stream.
I'm thinking about a good solution. At the moment, I have thought to
store SDP state with the last RTSP negotiations analyzed. I'll write
an API to talk with SDP module in order to get sdp information. In rtp
dissector, when a rtp packet with a dynamic payload arrived, I'll ask
for the SDP dissector and I'll try to get information with the implemented
API, and then I could know the real payload of the stream. For now
I'm sure that other dissector has similar problems, and sure there are
different solves to this. I'll be glad if someone give me other point of
view. We can talk about that.
> are trying to achieve? Are you talking about using
> the rtp-map media attributes from SDP to define these 'dynamic' rtp
> payload types?
Yes, this is what I mean.
Regards,
Francisco J. Cabello
