Michael Oliveras wrote:
> Guy,
>
> Thanks for the bug fix.
>
> >From what I know about T38, the call is always setup as a voice call. When
> the terminating device detects the CED tone from the fax machine, it
> initiates the switch over to T38 by sending an H245 RequestMode towards the
> originator.
I think that it is possible to setup a T.38 call directly, but it is probably more normal to first setup a voice call
and then change to fax codec.
Guy Harris wrote:
>
> Is there anything in that capture that indicates that it's setting up a
> T.38 call, rather than an RTP call? Presumably we shouldn't just be
> assuming that H.245 is setting up an RTP session.
>
The OpenLogicalChannel message will indicate that it is data/t38 when setting up the logical channel for T.38 (and also
indicate if TCP
or UDP is to be used for T.38).
Similar the OLC will indicate data/t120 when T.120 channel is setup.
The OpenLogicalChannelAck message doesn't indicate this..
This makes it more complicated to know if the OLC_Ack is for audio/video (RTP) or for data (T.38/T.120/...).
You would need to match the OLC_Ack with the corresponding OLC message.
In most scenarios there is no big problem when T.38 over TCP is used, except that you have to use "Decode As..."
to decode the T.38 packets.
For T.38/UDPTL there could however be a problem since T.38 is sent over UDP and Ethereal will then normally decode these
packets as RTP packets with "unknown version: 0".
There is a quite normal scenario where same UDP port numbers are used both for RTP and T.38/UDPTL
at different times in the capture. This is a scenario that is problematic in Ethereal, since H.245 dissector
will start a conversation and dissect both the RTP and T.38 packets with the RTP dissector.
There is currently no way to stop a conversation and I think that it could be quite complicated to solve this in a good
way.
This problem may also appear when using SDP instead of H.245 (even though the SDP dissector only starts a RTP
conversation when the SDP packet indicates RTP).
