[Jon Ringle <ml-ethereal@xxxxxxxxxx>]

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

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?

Jon