Project

General

Profile

OSmux

OSmux is a multiplex protocol that proxies voice (RTP-AMR) and signalling traffic in order to reduce the bandwidth consumption, which can be specially important in satellite based GSM back-haul systems. Development of the protocol has been so far mainly accomplished by sysmocom GmbH and funded by On-Waves ehf.

The latest version of the reference specification can be found in the nightly build of osmo-gsm-manuals: osmux-reference.pdf

Reference implementation can be found in libosmo-netif: osmuxh.h osmux.c

So far, main use of OSmux has been connecting several OsmoBSC with a bsc_nat through a satellite link to multiplex and batch calls together. Both use the implementation in libosmo-netif to gain OSmux support. Use of OSmux protocol in those projects can be configured using the VTY configuration interface.

Wireshark

Wireshark gained initial support to dissect Osmux packets in mid July 2016 (fdbf443d27, after release 2.3.0rc0).

The packet dissector can be found in packet-gsm_osmux.c

Support for Osmux was later improved during May-June 2017. Some of the new features include:
  • Support dissecting more than one OSmux frame per UDP packet.
  • Display each AMR payload separately instead of showing all of them together.
  • Display the RTP M bit in the packet tree.
  • Add menu "Telephony->Osmux" to run the "Packet counter" stats tree, both for wireshark-gtk and wireshark-qt.
  • Support and display correctly both old Dummy packets (see below) and official dummy packets.
  • Add support to identify different OSmux streams, assigning an ID to each of them. This ID is showed in the packet tree for each packet, and can be used as a filter ("osmux.stream_id 123").

How-To use the OSmux Wireshark dissector

First, load a pcap file or start recording on an interface with an OSmux connection ongoing.

If the Osmux connection is not detected and it only shows up as a regular UDP flow, then select any of the UDP packet flows and right click to open the menu, then select "Decode As...". A window with a list of protocol will show up. Select "GSM Osmux" and press "Apply". At this point, the dissector should be displaying all OSmux information for packets on that UDP flow. See screenshot section below to have an idea how it should look like.

On the info column, for each UDP packet you should see a summary of what does that packet contain from OSmux point of view. It will show the OSmux frame type. If there is more than one OSmux frame per packet, then all will be shown separated by commas.

Packets displayed as "Old Dummy" are specifically crafted packets from early specs/implementation days of Osmux. Support to dissect them is left for backward compatibility and to be able to dissect correctly old pcap traces. They can be identified because its Osmux frame length is 2 bytes containing only the control byte (1st byte) and the CID (2nd byte). In this kind of packets, the control bytes has the value 0x23

You can select any packet and you will see all the bits decoded in the packet tree.

Every OSmux frame will contain an "Osmux Stream ID". That's a value calculated by Wireshark which identifies uniquely every tuple [ip-src, port-src, ip-dst, port-dst, cid], which means for each call between A<->B, you will have 2 streams, one for each flow direction. You can right click on the "Osmux Stream ID" field on the packet tree and use it as a filter ("Apply As Filter"->"Selected") to filter and list packets for a specific stream.

Limitation: If you record for long enough or the same tuple (IPs, ports and CID) is reused fast enough to set up a new call, the code in the Osmux dissector won't be able to differentiate between the old call and the new call, and thus both will be assigned the same "Osmux Stream ID", which is bad specifically if you want to calculate the statistics using the stats tree, as then the calculated values will probably be wrong. The advise here is to manually review and make sure this doesn't happen, by knowing context of the trace or following some heuristics like "this stream didn't receive packets for a long time and after that packets start flowing again, probably starting with a few Dummy packets". If it's the case, identify manually the different streams and split them into a different capture to have good results from the OSmux tree.

How-To use the OSmux Wireshark stats tree

The stats tree is a built-in graphical interface from Wireshark to display a few variables and counters over a set of packets.

OSmux uses this interface to display some statistics for each stream ID identified. To open the stats tree GUI for OSMux streams, use the following menu: "Telephony->Osmux->Packet Counter". A new small window will appear which let's you apply a filter to calculate statistics for only a subset of the packets already detected as OSmux by the dissector. For instance, if you want to calculate statistics only for a certain stream with ID 123, you can pass osmux.stream_id 123", then press "Create Stat".

The stats tree GUI will appear, listing the streams according to the applied filter. See screenshot section below to have an idea how it should look like. Each stream is shown in the following format:

STREAM_ID ([IP_SRC:PORT_SRC->IP_DST:PORT_DST]:CID)

On the Count column you will find the number of packets which are part of that stream.

For each stream, the following fields are displayed:
  • Count: AMR frames: In the Count column, number of packets for that stream which are of type AMR Codec (1).
  • Count: Osmux Packets: In the Count column, number of packets for that stream.
  • Field: FT AMR: In the Count column, number of packets for that stream which are of type AMR Codec (1) and are not Old Dummy packets.
  • Field: Old Dummy: In the Count column, number of packets for that stream which are of type AMR Codec (1) and are Old Dummy packets.
  • Field: RTP Marker (M): In the Count column, number of packets for that stream which are of type AMR Codec (1) and have the RTP Marker (M) bit set, as explained in the OSmux specification.
  • Jitter Analysis: Relative Transmit Time [ms]:
    • column Count, number of packets used to calculate the value (should be the same as the one in Field: FT AMR).
    • column Average, average value of Relative Transit Time for the stream as specified in RFC3550 section 6.4.1 field "interarrival jitter", calculated in milliseconds.
    • column Min val, the minimum value registered (Take into account the value is signed but Wireshark shows it as an unsigned value, so you may need to convert manually).
    • column Max val, the minimum value registered.
  • Jitter Analysis: Relative Transmit Time (abs) [ms]:
    • column Count, number of packets used to calculate the value (should be the same as the one in Field: FT AMR).
    • column Average, last value of Relative Transit Time for the stream as specified in RFC3550 section 6.4.1 field "interarrival jitter", absolute value calculated in milliseconds.
    • column Min val, the minimum value registered.
    • column Max val, the minimum value registered.
  • Jitter Analysis: Jitter [ms]:
    • column Count column, number of packets used to calculate the value (should be the same as the one in Field: FT AMR).
    • column Average, last value of Jitter for the stream as specified in RFC3550 appendix a.8, calculated in milliseconds.
    • column Min val, the minimum value registered.
    • column Max val, the minimum value registered.
  • SeqNum Analysis: Consecutive Repeated: Number of times that a packet has the same OSmux Seq field as the previous one, i.e. number of duplicated packets.
  • SeqNum Analysis: Lost: Estimation of packets lost based on Osmux seq field values jumping forward increasing more than 1 since last packet received (+ some heursitics to check for wrap).
  • SeqNum Analysis: In Order: Regular situation in which Osmux seq field value N+1 comes after N (+ some heursitics to check for wrap).
  • SeqNum Analysis: Out of Order: Estimation of packets received in a later timer with a Osmux seq field value smaller than the higher one we received previosuly (+ some heursitics to check for wrap).

Fields which have no packets matching are not shown and their values can be usually understood to be zero or similar logical value.

Screenshot

Screenshot summarizing current features:

osmux-stats.png (229 KB) pespin, 06/02/2017 10:17 AM