Stats can be collected from each MGCP endpoint by several categories. After completion of each call, or following the DLCX delete connection message, the endpoint will immediately generate a message back to the switch with the following parameters:
__________________________________________________________________ | Connection parameter| Code| Connection parameter | | name | | value | |_____________________|______|____________________________________| | Packets sent | PS | The number of packets that | | | | were sent on the connection. | | Octets sent | OS | The number of octets that | | | | were sent on the connection. | | Packets received | PR | The number of packets that | | | | were received on the connection. | | Octets received | OR | The number of octets that | | | | were received on the connection. | | Packets lost | PL | The number of packets that | | | | were not received on the | | | | connection, as deduced from | | | | gaps in the sequence number. | | Jitter | JI | The average inter-packet arrival | | | | jitter, in milliseconds, | | | | expressed as an integer number. | | Latency | LA | Average latency, in milliseconds, | | | | expressed as an integer number. | |_____________________|______|____________________________________|
Extension parameters names are composed of the string "X-" followed by a two letters extension parameter name. Call agents that received unrecognized extensions shall silently ignore these extensions.
An example of connection parameter encoding is:
P: PS=1245, OS=62345, PR=0, OR=0, PL=0, JI=0, LA=48
These stats may be obtained from any packet capture or from completing a tcpdump on the interface of the customer router/provider switch. A similar command would look like this:
tcpdump -i eth0 -s 0 -n port 2727
This will capture port 2727 (MGCP signaling port) of any device talking to the switch which will contain the info we are looking to find.
