Anders Broman wrote:
Richard van der Hoff wrote:
Well, if your H.223 is over TCP, it may or may not be bitswapped
Guy wrote:
That presumably means that either
1) call setup negotiates the bit order
or
2) the bit order is chosen "out of band" (e.g., manually).
If it's negotiated at call setup time, presumably if the call setup
traffic is present, Wireshark can determine the bit order, so this
presumably would be needed only in the case where the call setup traffic
*isn't* present, so you would have to manually specify that the TCP
connection is carrying H.223 traffic.¨
Yes, it's chosen out-of-band. There is no call setup with a TCP
connection (at least with our implementation here) - it's just a TCP
connection carrying a raw H.223 stream. Whether it's bitswapped or not
depends on which applications you're looking at (ie, whether you're
upstream or downstream of the thing doing the bitswapping), and hence
which port. It really does make sense to be able to choose this as a
"Decode as..." option.
The reason, then, that it needs to be two separate protocols, is that
you need to be able to choose between them in the "Decode as..."
dialogue box.
For H.223 over TDM I know there has been trouble on agreeing what the proper
Bit order is between manufacturers so at least some implementations
determine the bit order heuristically...
Hrm; I've never seen any conflicts between manufacturers. It *is*
well-specced, if slightly perversely (ie, the opposite way to the
bit-ordering for) audio data. Determining it heuristically would be
difficult - if you receive data which looks bitswapped, do you suddenly
swap the ordering of the bytes you are transmitting? What happens if
both ends do that at the same time? Writing a dissector to cope with
that would also be very hard, particularly in the absence of test data.
I also should have said - H.223-over-rtp is bitswapped too. So I guess
the question becomes "when is it not bitswapped?" To which the answer is
"TCP. Usually."
