Guy Harris wrote:
>
> 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.
>
I don't have my H.245 signalling knowledge so fresh right now, but I'm quite
sure that I remember that there are certain scenarios where you just tell
that I'm listening on this address and this port and that you just get
information about the ip-address and port number that the remote sender is
listening on. However the RTP packets could be sent from another ip-address
or port.
http://www.packetizer.com/in/q32.html
In the Fast Start scenario you are supposed to expect packets immediately
after sending the OpenLogicalChannel (i.e. before you have got any
indication
that the remote end has accepted that logical channel) if I remember
correct.
In packet #5 it is actually optional to send the ip-address and port number
for the reverse channel (ip x.x.x.x. 19530) and I know that you cannot be
sure to trust the address that is sent there (but I have seen at least one
H.323 client that used it and this in combination with a fault in another
component gave a very strange behaviour).
http://www.packetizer.com/in/q111.html
> >
> > 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".
>
Yes, I actually started to look at circuit mechanism a couple of days ago
and I think that conversations may need to behave in a similar way.
But as I see it there is a lot of work that has to be done to get everything
working and first there is a need for a lot of
thinking.
I see several problems, e.g.:
-We need to store information about all H.245 logical channels and so on and
this needs to be done in a good way so that we can use
this for dynamic payload type information and so on.
-For exactly what scenarios should the conversations be
stopped/started/restarted/modified. Please note that you may see several
OLC/OLCACKs for the same
RTP stream in the same capture and there might be both H.245, SIP-SDP,
Megaco-SDP signalling for the same call in the same
capture. So the implementation might be tricky.
However if we make a good solution for this it would probably also be
possible to handle dynamic payload types in a good way, and I think
that there is similar problems for e.g. T.120 as for T.38.
It will certainly not be possible to implement this before next version of
Ethereal, so can you please have a look at just the packet-t38.c file I sent
in my previous message
http://www.ethereal.com/lists/ethereal-dev/200401/msg00085.html
The changes in packet-t38.c should solve point #3 to #6 and is actually
independent on the solution of point#1 to #2 (packet-rtp.c, packet.h,
conversations.c).
I would really like to have the Info-column improvements in the next
version.