Ethereal-dev: RTP/T.38 dissecting (was: Re: [Ethereal-dev] [patch] stun dissector)
On Monday 17 January 2005 09:16 pm, Jon Ringle wrote:
> On Monday 17 January 2005 01:32 pm, Martin Regner wrote:
> > There is a sample RTP/T.38-UDPTL capture on the following page:
> > http://www.brooktrout.com/support/productinfo.cfm?frmProduct=TR1034&frmCa
> >te gory=Knowledgebase&frmKnowBaseID=1983&Level=2
>
> Oh. I see now. Frame 13 sets up both RTP and T.38 using port 56000. Using
> frame number as I have suggested wont help in this case. Does an
> application using RTP and T.38 on the same port demultiplex based on
> rtp.version == 0 to decide to parse with T.38 parser?
I am figuring that an application that sees this stream of data has to be able
to decide whether to use an RTP parser or a T.38 parse either from the data
present in upd port 56000, *OR* from new information presented to it by
another stream of data. It seems that a transition from voice RTP to fax T.38
packets occur as a result of the new SDP negotiation at Frame 808.
So, I am thinking that the following may be true (please correct me if I am
wrong):
1) If an SDP contains both m=audio and m=image, an application will use an RTP
parser.
2) If an SDP contains only m=image, an application T.38 will use an T.38
parser.
I now have code that adds the first_frame number to conversation_t and changes
find_conversation() and conversation_new() to pass the first_frame number.
With the sample RTP/T.38-UDPTL capture, my code correctly chooses the RTP or
T.38 (except for frame 809 which is an RTP packet, but gets dissected as T.38
because of the SDP m=image only change in frame 808).
Jon
