D. Recording VoIP or RoIP Calls¶
D.1. Introduction to Recording VoIP or RoIP Calls¶
This topic describes information related to recording Real-time Transport Protocol (RTP) data.
Voice Over Internet Protocol (VoIP) calls
Radio Over Internet Protocol (RoIP) calls
Eventide NexLog DX-Series™ recorders support both VoIP and RoIP, but this topic mainly describes VoIP. However, because RoIP is similar to VoIP, much of the information applies equally to both.
Cisco 7 through 10.5 are supported under the Local VoIP/RTP recording.
SIP Endpoints are also supported by Local VoIP/RTP Recording.
NG9-1-1 “SIP Invite” recording uses the Local VoIP/RTP feature on Eventide NexLog DX-Series™ recorders.
RoIP recording and IP Dispatch Console recording uses the Local VoIP/RTP feature on Eventide NexLog DX-Series™ recorders.
D.1.1. What is VoIP?¶
VoIP (Voice over Internet Protocol) is a technology that allows telephone calls to be made over local area networks (LAN) or the Internet. VoIP systems convert analog voice signals into digital data packets and supports real-time, two-way transmission of conversations using the Internet Protocol (IP).
VoIP calls can be made on the Internet using a VoIP service provider and standard computer audio systems. Alternatively, some service providers support VoIP through ordinary telephones that use special adapters to connect to a home computer network.
VoIP services convert voice or audio data into a digital signal that travels over a computer network such as a company intranet or the Internet. If you are calling a regular phone number, the signal is converted to a regular telephone signal before it reaches the destination. VoIP can allow you to make a call directly from a computer, a special VoIP phone, or a traditional phone connected to a special adapter.
D.1.2. The Advantages VoIP Provides¶
With traditional telephone service, also known as Plain Old Telephone Service (POTS), a telephone call is made on an analog telephone line through a pair of copper wires connected between the caller and the called party. This creates a physical connection dedicated for a single call, so the conversation is transmitted using a single, static pathway over the telephone network. It uses the Public Switched Telephone Network (PSTN), which is a circuit-switched network, meaning the connection between the endpoints (telephones) is made through switches that connect the lines together.
On the other hand, VoIP transmits the call using a packet-switched network. With VoIP, the audio signal of the telephone call is digitized and encapsulated into data packets that are sent over the network to the other party. The packets may take one or more paths over the network to reach the called party. At the other end of the line, the packets are reassembled and converted back into analog voice signals. This network can be used at the same time by other communications, which may include other VoIP telephone calls as well as a variety of packetized information such as data and video.
Because the VoIP network can carry many conversations at the same time and because it can also transmit other types of information, VoIP is a more efficient and flexible method for transporting voice. It can also produce a richer experience for the user if it is combined with other features, such as video. In addition, it can be cost-effective to implement because you may be able to add VoIP telephony services to an existing network infrastructure.
VoIP systems can interconnect and co-exist with existing PBX systems as well the traditional circuit-switched network. Of course, power sources are a consideration when implementing any VoIP system, because VoIP phones do not derive power from a PBX or from the telephone company Central Office. So, to protect against loss of telephone service due to power outages, it is necessary to install uninterruptible or back-up power supplies for both the LAN equipment and VoIP telephones.
D.1.3. Technical Considerations¶
The handling of audio data in VoIP differs significantly from how it is done on a conventional, circuit-switched network. On the latter, once a connection is established, it is defined between two fixed points, and both the upstream and downstream data are handled by the same pair of wires. The digital architecture of VoIP separates upstream and downstream data, and the transmission path across the network can vary. Audio is carried through RTP (Real Time Protocol) packets, which can be routed along different paths. As a result, data packets of audio data can become unsynchronized and be delivered out of their original sequence.
To address this, VoIP uses a buffering system that synchronizes delayed packets. The inherent delay caused by packet buffering should never exceed 500 ms.
Networks are by no means limited to carrying only voice data. As such, a packet filtering mechanism is used to detect and isolate RTP audio data packets from other data types carried across the network.
D.2. Network Requirements¶
The following requirements apply to recording VoIP calls:
Unlike a PBX phone system, which has a centralized switch from which to tap the telephone calls, a VoIP system transmits the calls over a distributed intranet, which also carries other data traffic. To capture and record VoIP calls from the intranet, you must configure your intranet topology to mirror or send a copy of the VoIP packets to a single Ethernet port, which is connected either to the Eventide NexLog Recorder (for Local VoIP) or, in now rare cases, to an Eventide VoIP Gateway. For example, this can be accomplished using a Cisco Systems Ethernet switch that supports Switched Port Analyzer (SPAN) technology or Remote Switched Port Analyzer (RSPAN) technology. These components create copies of the audio packets being sent across the network and send them to another designated port for network analysis. In the case of RSPAN, it places audio traffic on a SPAN port from different network switches.
For detailed information on SPAN and RSPAN, go to the following page on the Cisco Systems web site:
www.cisco.com/univercd/cc/td/doc/product/lan/c3550/12113ea1/3550scg/swspan.htm
In addition to SPAN or RSPAN, some systems use direct unicast or multicast connections to the recorder.
When using the Local VoIP feature on an Eventide NexLog DX-Series™ recorder, the recorder must be equipped with two network interface cards (NICs) if you are using SPAN/RSPAN. (One port is used for the unidirectional VoIP traffic sent to the recorder, and one port for bidirectional traffic with clients.)
Both the gateway and recorder need a second NIC card to be able to capture from a SPAN port. Since the SPAN port is unidirectional and in the case of the gateway it needs to be able to have bidirectional access to the recorder. Or in the case of the recorder it needs to have bidirectional access to the client applications.
Eventide suggests implementing VoIP on a virtual local area network (VLAN). A VLAN is a logical group on the network that effectively prioritizes network traffic to ensure enough bandwidth. VLANs also greatly ease the configuration issues surrounding SPAN and RSPAN ports.
The MAC or IP addresses of all active phone sets must be designated. This information is entered in Configuration Files area of the NexLog Recorder Configuration program. Additionally, port ranges for both the signaling ports (the call’s attributes) and audio ports (the actual audio data packets) must be designated. Only calls that occur on ports in these designated ranges are recorded; all others are ignored.
D.3. Local VoIP and RoIP¶
Local VoIP and RoIP refer to the feature of Eventide NexLog DX-Series™ recorders that provides the capability to record VoIP and RoIP without using an Eventide . This local IP recording capability is also used for recording IP-based P25 radio systems (by EF Johnson and others).
The Eventide NexLog DX-Series™ recorders support capturing and recording voice or radio traffic appearing in RTP packets on an Ethernet network. The recorder is able to monitor and record Ethernet Voice over Internet Protocol (VoIP) or Radio over Internet Protocol (RoIP) traffic directly.
Fig. D.1 IP Recording Virtual Interface Template Menu¶
To configure the recorder for VoIP (or RoIP) traffic, you must first add a virtual board of type Local IP and the required number of virtual channels to the system.
Fig. D.2 IP Recording Virtual Interface Template Menu With Search Input¶
The text input field at the top of the menu allows you to filter the list on characters or a word; shown here restricting the menu to just templates with “Moto” in the name.
If your system is not in the list of templates, select No Template and see the Advanced Local VoIP Recorder configuration section below.
D.4. Local VoIP and RTP Templates¶
Local IP boards can be set up using a template that will automatically create a configuration based on the settings required for the type of board selected.
For example, for a Telex/Vega Console, which requires a multicast address, a TX port and an RX port for each channel, the template looks like this:
Fig. D.3 Telex/Vega Console Template Example¶
On the other hand, an EFJohnson P25 system has different requirements: an IP address for the IMBE decoder and a default RTP port, with a multicast address, codec, and supergroup port configured for each channel.
Fig. D.4 EFJohnson Template Example¶
Any IP board configured with a template can be re-configured using the same template; this will effectively recreate the board from scratch, so if you have made per-channel changes, those will be reset to defaults. As such, you may want to make any necessary edits manually instead.
The templates included with NexLog DX-Series™ are:
Aastra SIP-DECT Phones
Aastra MX-ONE H.323 Phones (SPAN
Aastra MX-ONE SIP Phones (SPAN)
Asterix Radar Data over UDP
Avaya H.323 protocol (SPAN)
Avtec Scout RTP Forwarding
C4i SwitchPlusIP Console
Catalyst Advanced Recording Interface
Cisco CallManager “Skinny” Protocol (SPAN)
Cisco CallManager Built-in-Bridge
CSS Mindshare Console Protocol
EFJohnson Console Protocol
ESCHAT
Eventide AIS Proxy (ASTRO25)
Eurocae ED-137B Part 4 RTSP Recording Interface
Eurocae ED-137C Part 4 RTSP Recording Interface
Generic Multicast RTP
Generic SIP Phones (SPAN)
Generic Unicast RTP (Recorder as Endpoint)
Generic Unicast RTP (SPAN)
Harris P25 Recording
ICOM IDAS Repeater (NXDN)
Intrado Position (SPAN)
Intrado Trunk (SPAN)
Kenwood NEXEDGE Trunked (1st Generation)
Kenwood NEXEDGE Trunked (2nd Generation)
Mitel Secure Recording Connector
Motorola Dimetra AIS Interface
Motorola Wave 5000 Multicast RTP
MOTOTRBO Capacity Max Recording Interface
MOTOTRBO Controller-less Recording Interface
NEC Univerge Phone Recording Proprietary SIP (SPAN)
Nortel Unistim Protocol (SPAN)
Omnitronics DRG / IPR / IPE Recording
Panasonic MGCP Phones (SPAN)
Raven M4X Site Device RTP Forwarding
RadioPro / TurboVUi Console Protocol
Sepura/Fylde MPT / DMR/ dPMR Recording Interface
Shoretel (Mitel) MGCP Phones (SPAN)
Shoretel (Mitel) VQMS Recording (SPAN)
Siemens (ATOS) H.323 Phones (SPAN)
SIPREC
SIP Trunk (SPAN or Recorder as Endpoint)
Smart PTT Console Recording
Solacom i3 SIP Trunk
Tait Radio DMR/MPT Recording Interface
Tait Radio Trunked P25 ISSI
Telex/Vega Console Protocol
Toshiba Megaco Protocol Phones (SPAN)
VESTA/Sentinel 4 Console (SPAN)
VESTA/Sentinel 4 Trunk (SPAN)
Zetron Logger
Zetron MAX CallTaking Consoles (SPAN)
Zetron MAX Dispatch
D.5. Cisco VoIP Template¶
Fig. D.5 Cisco Callmanager “Skinny” Protocol (SPAN) Template¶
To configure Cisco Callmanager with Local VoIP recording, use the Cisco Callmanager “Skinny” Protocol (SPAN) template. Enter the SCCP and RTP ports in use, and then enter an IP address (xxx.xxx.xxx.xxx) or MAC address (xx:xx:xx:xx:xx:xx) for each phone line in the system.
D.6. Local VoIP and RTP Channel configuration¶
Like other board types, configuration of channels on local IP boards is done on the Recording->Boards page by opening the board and then clicking the gear on the channel you wish to edit. The channel edit page has three tabs. The first is the standard Edit Channel tab. The second and third are RTP and Diagnostics.
D.6.1. RTP¶
Fig. D.6 Top Half of Local IP Channel RTP Tab¶
This tab allows you to configure all the RTP specific options detailed below in the Channel Parameters subsection of the Advanced Local VoIP Recorder configuration section of this chapter.
Fig. D.7 Bottom Half of Local IP Channel RTP Tab¶
D.6.2. Diagnostics¶
The third tab is Diagnostics. It displays diagnostic information showing what data is arriving for the channel and can be used to help troubleshoot whether the channel is configured properly.
Fig. D.8 IP Channel Diagnostics Example¶
Each channel has up to 4 RTP queues for incoming RTP queues and signaling queue. These queues show the number of packets that have arrived and been Enqueued, and the number that have been Dequeued and handled. The remaining columns (Source, Dest, Elapsed, Codec, SSRC, Seq) display data about the most recent packet to arrive for that queue.
Source: The ip address and port of the source of the packet.
Dest: The IP address and port of the destination of the packet.
Elapsed: How much time since the packet came in.
Codec: How the audio was encoded. (RTP only)
SSRC: Source Identifier. (RTP only)
Seq: Sequence number of the packet. (RTP only)
When MUX is NONE, there will only be one RTP queue all packets to go. If MUX is DIR (one RTP queue will be for incoming packets and one for outgoing packets (relative to the IP address configured for the channel). If MUX is Port or IP_Port, queue assignments are made per port.
The Refresh button, as expected, refreshes the data displayed to be current.
D.7. Advanced Local VoIP Recorder configuration¶
The following information describes low level configuration of the built-in recorder based VoIP/RTP configuration, which is used for recording RoIP, NG9-1-1 “SIP Invite”, and IP Dispatch Consoles.
D.7.1. VoIP: Edit Board¶
The board level parameters are accessible by clicking on the board name in the Recording Interfaces NexLog Configuration Manager page. The board is named “Local IP Recording.” On that page the board can be configured to capture RTP traffic in different ways.
The UDP section is for configuring the virtual board to capture UDP packets addressed directly to the NexLog recorder’s IP address.
The PCAP section is for configuring Promiscuous Mode Packet Capture. This capture method allows the recorder to capture traffic not addressed to its IP address.
D.7.2. Board Level Configuration Parameters¶
The following information lists the parameters and valid values that can be specified in board level configuration. (Boldface indicates a default value.) They are described in the sections that follow.
D.7.2.1. List of Board Level Parameters¶
UDP Ports: port-list
UDP Multicast Addresses: IP-address-list
UDP Multicast Interface IP: IP-address
SIP Endpoint Config: contact Eventide for usage
PCAP Devices: eth0, eth1, eth2, etc.
PCAP Ports: port-list
PCAP Vlan: unchecked (off), checked (on)
PCAP Defragment: unchecked (off), checked (on)
Packet Filtering: Bpf None, Bpf Port, Bpf Full
Channel Count: number-of-channels-on-virtual-board
D.8. Device Information¶
PCAP Ports and UDP Ports: Specifies a port list (port numbers and/or port ranges) for ports to record. All ports that are used by all channels must appear in the list. The ports should also be specified in the channels specific pages. Valid Range: 1-65535. Format: To specify multiple port numbers, separate them with commas; for example: 1,2,3,5,9. To specify a port range, separate it with a hyphen or dash; for example: 1-3. To specify multiple port ranges, separate the ranges with a comma; for example: 1-3,7-12. To specify multiple port numbers and port ranges, separate each type with a comma; for example: 1,2,5,9,12-15,19,22-25,29,30. For readability and maintenance (and to avoid duplications), it is recommended that you specify port numbers in numerical order.
Note
For PCAP Ports, the smaller the range, the better the performance, so it is a good practice to identify only those ports that will be used. The ports belong to VoIP devices such as IP phones, IP softphones, IP PBX ports, or other VoIP endpoints on the network that you wish to record. Any packet received by the recorder that uses ports in this list as either destination or source will make it past the filter and be processed by the recorder.
Important
For UDP Ports**, it is very important to specify only the ports that will be used, because opening these ports will consume resources on the recorder. For example, specify 3,5 rather than 3-5 if port 4 will not be used.
UDP Multicast Addresses: Specifies one or more IP multicast group addresses from which to record. [Join or subscribe to.] Format: to specify multiple IP multicast group addresses, separate them with a comma; for example: 239.1.1.1,239.1.1.9.
UDP Multicast Interface IP: Specifies the IP address of the NexLog Recorder’s network interface device which will be used to capture the multicast traffic.
SIP Endpoint Config: Specifies a special parameter to configure the NexLog Recorder as a SIP Trunk endpoint instead of its usual configuration as a “listen only” device. Contact Eventide Service for assistance in configuring this parameter.
PCAP Devices: Ethernet Device name. Specifies the NexLog Recorder’s network interface device (NIC) containing the Ethernet port that will be used to record RTP data. Valid Values: eth0, eth1, etc. Typically, one Ethernet port on the recorder is used to record the VoIP traffic sent to the recorder and one port is used for bidirectional traffic with recorder clients, such as a PC with Eventide MediaWorks that is used for playback or live monitoring.
PCAP Vlan: Virtual Local Area Network. Enables the Packet Pre-Filtering (BPF) for use on a VLAN, which is often used with SPAN and RSPAN setups. This setting is used because the port/IP address information appears in a different location in packets depending upon whether the traffic is from a VLAN or LAN. Valid values:
unchecked: Disabled (default), for use on a LAN.
checked: Enabled, for use on a VLAN.
PCAP Defragment: Enables IP defragmentation. When disabled, only the first fragment is processed and subsequent fragments are ignored. It is usually unnecessary to enable IP defragmentation, because voice packets are typically small enough to avoid fragmentation, or if they are sent in multiple fragments, the necessary data is usually in the first fragment, and the rest can be ignored. (Fragmentation occurs when the payload results in a data packet size that is greater than the maximum transmission unit of the sending switch.) Valid values:
unchecked: Disabled (default). No IP defragmentation is performed.
checked: Enabled. IP defragmentation is performed.
D.8.1. Packet Filtering and Handling¶
Because networks carry many types of data packets that are bound for different destinations, the recorder uses a /packet filtering/ mechanism to detect and isolate the desired RTP audio data packets from other data types forwarded by the network to the recorder’s Ethernet port.
Packet Filtering: Berkeley Packet Filtering. Specifies a source port pre-filtering method for capturing RTP packets. Packets are pre-filtered at the NexLog Recorder network interface. This can reduce the load on the recorder, which is especially important in saturated high-throughput networks. BPF is a method used to capture and filter packets from a network interface that is used in promiscuous mode. When the NexLog Recorder network interface is in promiscuous mode, it receives a copy of each RTP packet appearing on the port, which is then run through a filter, so that only packets of interest are passed to the recording application layer. This pre-filtering can reduce the traffic load on the recorder CPU (except when no filtering is used).
The following settings can be used:
Full: (default) Accepts traffic from all source ports identified in the configuration by IP or MAC address or port number.
Port: Accepts traffic from all source ports identified in the configuration independent of IP or MAC address. This setting is used when the IP addresses may change.
None: No pre-filtering is performed. Accepts traffic from all source ports.
Typically, it is either set to FULL or to a list of ports, except when using dynamic channel mapping, in which case, it should be set to NONE or a list of ports.
D.8.2. Channel Parameters¶
The channel level configuration is accomplished the same way as other boards. Click on the plus sign (+) next to the board name to open the list of channels for a board. From there clicking on the gear icon will show the channel specific configuration. On the channel page there is an RTP tab where VoIP specific parameters can be changed. The settings include channel mapping parameters, which direct RTP packets from a specific IP address, MAC address, or port number to record on the specified channel (or which specifies dynamic channel mapping).
When a virtual board is added the virtual channels are added to the recorder and are assigned recorder channel numbers based on the channel numbering sequence. The channel numbering sequence starts with hardware based channels, beginning with installed telephony boards, followed by the channels on virtual boards in the order they were added via NexLog Configuration Manager. For example, if the recorder has 8 hardware-based channels, then the first virtual channel (Channel 1 of the virtual board) will be assigned to recorder channel 9.
D.8.3. Channel Configuration Parameters¶
The following information lists the channel configuration parameters and valid values that can be specified.
D.8.4. List of Channel Parameters¶
IP Address: <IP-address>
MAC Address: <MAC-address>
RTP Ports: <port-list>
Signal Ports: <port-list>
RTP Mixing Mode: Rtp Mux None, Rtp Mux Dir, Rtp Mux Port, Rtp Mux Ip Port, Rtp Mux Ssrc
Signal Protocol: Rtp Sig None, Rtp Sig Sip Trunk, Rtp Sig Zetron Rds, Rtp Sig Cisco Forked, Rtp Sig Telex Ip223, Rtp Sig Telex Ip223 Trunked, Rtp Sig Efjohnson
RTCP Ports: Rtp Rtcp None, Rtp Rtcp Odd, Rtp Rtcp Even
Break on SSRC: Rtp Ssrc Nobreak, Rtp Ssrc Break, Rtp Ssrc Fuzzy
Jitter Buffer (uSec): <millionths-of-second>
CallID Field Name: <SIP-field>
IP Field Name: <optional name of metadata field>
Steal Oldest Channel: *unchecked (off)*, checked (on)
Break On Jitter: *unchecked (off)*, checked (on)
Custom Protocol Handling: *unchecked (off)*, checked (on)
RFC2833 Codec: -1, <codec-number>
D.8.5. Channel Mapping¶
VoIP calls can be mapped to NexLog Recorder channels using the following options:
IP Address: Map the IP address of a VoIP device to a recorder channel using static channel mapping. Mutually exclusive with MAC address. A specific IP address can be used or Dynamic which can map VoIP calls to a bank of channels using a dynamic assignment that is controlled by other means, such as call control or custom programming. Used when the port range or IP address is variable or floats, such as with VoIP trunking (e.g., SIP trunking, where negotiation of the SIP phone call includes ports to use), or when using custom scripts or programming from Eventide. When used with SIP trunking, set channel 1 to the IP address of the SIP source (for example, the SIP PBX or the local SIP trunk endpoint), and set the other channels to Dynamic.
MAC Address: Map the MAC address of a VoIP device to a recorder channel using static channel mapping. Mutually exclusive with IP address.
RTP Ports: Map a set of ports on a device to a recorder channel using static channel mapping.
Signal Ports: Specifies the signaling ports when signaling is used (when Signal Protocol is set to a value other than Rtp Sig None). Like traditional telephone calls, VoIP calls offer full-duplex communication, which allows the connected parties or devices to communicate with each other in both directions at the same time. However, with VoIP, the full-duplex call is composed of two halves: a stream of audio packets that are transported from party A to party B and a stream of audio packets that are transported from party B to party A.
It is typical to record the combined conversation rather than each side separately. Mixing options allow you to merge both halves of the conversation into one channel, or to record each party on separate channels.
Each channel is associated with a MAC or IP address (or is dynamically assigned). Traffic to this address is considered inbound and traffic from it is considered outbound.
RTP Mixing Mode: Specifies the type of audio stream mixing for the recording. Valid values include:
Rtp Mux None: (default) No mixing is performed. The channel must be set up to receive only a single RTP stream at any given time.
Rtp Mux Dir: Mix inbound and outbound audio streams belonging to a VoIP device (that is, mix traffic going in both directions). Direction mixing is typically used with the PCAP method, because the audio streams could be coming in from any port in the range.
Rtp Mux Port: Mix audio streams from multiple ports, where each port carries a separate audio stream. Port mixing is typically used with the UDP method.
Rtp Mux Ip Port: Mix audio streams from a destination IP address and port. IP Port mixing is used with the UDP method or SIP Trunk signaling.
Rtp Mux Ip Ssrc: Mix audio streams by detecting which stream a packet belongs to using the RTP packet’s SSRC field. Only recommended in case where IP_PORT cannot be used due to multiple streams received on the same port
Signal Protocol: Specifies the type of signaling used. We recommend leaving it as set by the template used.
RTP packets contain information in their headers identifying the sources of the RTP data stream. This includes the following identifiers:
Synchronization Source (SSRC): A unique numeric ID for a unidirectional stream of RTP packets. The synchronization source within the same RTP session is unique.
Contributing Source (CSRC): A unique numeric ID identifying a contributing source for a mixed stream of RTP packets (a stream that has been generated from multiple sources). In some situations, it is used to identify a previous origin of a stream of RTP packets (that is, a previous SSRC).
These data are used to identify audio streams, and hence, the audio that belongs to a VoIP call.
In addition, the SSRC is also used to aid in identifying call termination. When the SSRC changes, it is an indicator that the audio stream from one party has ended. However, there may be cases where the SSRC changes briefly but does not indicate a separate call. This can result in a call being broken inappropriately into two parts or in a spurious call with a very short call length (e.g., 0 seconds). The following parameter is used to control call breaks for these different situations.
Break on SSRC: Controls how to handle SSRC changes in determining call termination. Valid values are as follows:
Rtp Ssrc Nobreak: When the SSRC changes, do not “break” the call.
Rtp Ssrc Break: (default) When the SSRC changes, “break” the call (that is, treat it as a new call).
Rtp Ssrc Fuzzy: When the SSRC changes, “break” the call. However, if the new SSRC is numerically close to the current SSRC, do not break the call. This setting is used with some VoIP implementations that have atypical SSRC changes, such as with certain configurations of Cisco Call Manager.
Jitter Buffer: Jitter Buffer Size in microseconds. Default: 2000000 (2 seconds). Range: 0 to 5000000 (5 seconds). The recorder uses a jitter buffer to enable proper synchronization and a smoother flow of data. The larger the jitter buffer, the higher the recorder memory usage, as well as the higher the load on the recorder CPU when jitter is encountered.
CallID Field Name: If this value is set to the name of a text metadata field that has been added to the recorder’s database, and the signaling protocol from the PBX includes CallID information (a unique identifier assigned to the call by the PBX), then the CallID for the call will be attached to each call record by placing the CallID in this field.
RFC2833 Codec: Enables out-of-band digits when signaling is used.
-1: Disabled (default), no out-of-band digits.
<codec-number>: Enabled to receive out-of-band digits using the specified codec number used by the particular IP phone system (PBX and phones). Example: 128. The codec number is application-specific and can be obtained by checking with the manufacturer of the system or by analyzing the signaling data.