On Monday 17 January 2005 01:32 pm, Martin Regner wrote:
> Jon Ringle wrote:
> > On Monday 17 January 2005 11:25 am, martin.regner@xxxxxxxxx wrote:
> > > Jon Ringle wrote:
> > > > Yes. I am currently working on having rtp.version == 0 be dissected
> > > > by stun. I'll be posting a patch soon.
> > >
> > > Please note that T.38 UDPTL packets may also appear as rtp.version==0
> > > packets.
> >
> > I'm not familiar with T.38. I assume it gets negotiated via SDP? If so,
> > can it be identified separately from RTP in the SDP?
>
> ... and I'm not so familiar with STUN (yet) so I don't know if there is
> something else that can be used except for the version bits to
> differentiate between T.38 UDPTL and STUN.
>
> Unfortunately there is often problem with T.38 being decoded as RTP
> since the same UDP port numbers are often used first for voice (RTP) then
> fax (T.38/UDPTL) and maybe then voice (RTP) again in the same capture - and
> there is actually no good way of recognizing T.38/UDPTL, but the bits
> corresponding to rtp.version is 0 for normal scnarios (except maybe for
> very long fax-sessions).
>
> There is a sample RTP/T.38-UDPTL capture on the following page:
> http://www.brooktrout.com/support/productinfo.cfm?frmProduct=TR1034&frmCate
>gory=Knowledgebase&frmKnowBaseID=1983&Level=2
I took a look at the capture, and it seems to me that the problem is that
ethereal can't handle having multiple conversations across time that happen
to use the same src/dest tuple.
I am quite new to the ethereal source code, so my understanding of it is a bit
limited right now, but it looks like this might be resolved globally by
changing the conversation_t structure to include the frame number of the
packet that created a conversation. Then in the find_conversation() function
add a parameter that passes in the frame number of the currently dissecting
packet, and find the conversation that has the largest frame number in the
conversation_t structure, but smaller than the current dissecting frame
number. This would allow multiple conversations to be registered that happen
to use the same src/dest tuple within the same capture.
What do the ethernet veterans think about this?
Jon