On Jan 6, 2004, at 1:53 AM, Martin Regner wrote:
In the capture I have experimented with (which I got from LFAIM since
I seem
to have lost the UDPTL captures where I noticed similar problems
myself)
there is the following scenario:
packet#4 Setup with Fast Start OpenLogicalChannel
(mediaChannel ip x.x.x.x port 19530 is in the message, so
conversations will
be started for one direction).
This is actually a RTP session.
packet#5 Call Proceeding with Fast Start OpenLogicalChannel
(media Channel ip y.y.y.y port 16558 + ip x.x.x.x 19530 in the
message, so
conversation will be started for other direction).
This is actually a RTP session.
So are packet #4 and #5 really referring to the same session, with
packet #4 containing only one endpoint, and packet #5 either containing
both endpoints or containing the other endpoint? (If so, I assume
there's no way to infer the other endpoint from packet #4.)
If so, then perhaps for packet #5 it should use
"conversation_set_port2()" and "conversation_set_addr2()" to
un-wildcard the conversation, so it applies only to that particular
pair of endpoints, not to all traffic to or from x.x.x.x port 19530.
packet#924 CloseLogicalChannel
packet#925 CloseLogicalChannel, OpenLogicalChannel (t38fax)
packet#928 OpenLogicalChannel (t38fax)
packet#932 OpenLogicalChannelAck
(mediaChannel ip x.x.x.x port 19530 is in the message, conversation
already
started for that combination).
Now it's a T.38 session (but you may get still get some RTP packets
during
the switch over from RTP to T.38 so the T.38
application may have to check if the packet has a low UDPTL sequence
number)
packet#933 OpenLogicalChannelAck
(mediaChannel ip y.y.y.y port 16558, conversation already started for
that
combination).
Now it's a T.38 session.
("Frame" here means "top-level link-layer packet".)
This looks like it could use a feature that the "circuit" mechanism has
but the "conversation" mechanism doesn't, which, for circuits, is
multiple circuits with the same circuit ID and, for conversations,
would be multiple conversations with the same endpoints. You'd "close"
a conversation, which would set its "last frame" value; frames past
that would not be considered part of that conversation. When a
conversation is created, its first frame would be set; frames before
that frame would not be considered part of the conversation.
Frames for which there's a circuit ID or conversation endpoint match,
but that aren't in the frame range of any circuit or conversation,
should probably be considered to belong to the last circuit or
conversation whose "last frame" is < that frame, but perhaps flagged as
"showed up after the circuit or conversation was closed".