RTP IPv4 full duplex endpoint filter

Provides an entry and exit point for a duplex voice over IPv4 data stream (data that includes RTP headers within UDP packets) at the data network interface. For information about RTP IPv4 endpoint parameters, refer to RTP IPv4 endpoint address structure and RTP IPv4 endpoint parameter structure.

Filter ID

MSP_ENDPOINT_RTPFDX

Initialization structure

RTPRTCP_ENDPOINT_PARMS

Restrictions

Used in the voice processing connections.

Channel connections

Can connect to full duplex voice channels.

Commands

RTP IPv4 full duplex endpoint filters respond to the following commands:

RTP IPv4 FDX endpoints can receive commands any time after the endpoint is created, with the exception of the  MSP_CMD_RTPFDX_CONFIG command. The RTP FDX endpoint must be disabled to receive MSP_CMD_RTPFDX_CONFIG commands.

When sending MSP_CMD_RTPFDX_CONFIG commands, applications provide a pointer to an msp_ENDPOINT_RTFDX_CONFIG structure. This structure contains all of the parameters used to configure the RTP endpoint when the application created it.

When using the MSP_CMD_RTPFDX_CONFIG command, applications can specify a value of 0xFFFF for 16-bit parameters or 0xFFFFFFFF for 32-bit parameters (or -1 in decimal format) to retain the existing settings for any endpoint parameters. Otherwise the MSPP service expects a new value for every parameter in the msp_ENDPOINT_RTFDX_CONFIG structure.

For a list of command IDs and their associated structures, refer to the mspcmd.h or mspinit.h header files.

Queries

RTP IPv4 full duplex endpoint filters respond to the following query any time after the endpoint is created:

Sending an MSP_QRY_RTPFDX_STATUS query returns the following structure:

typedef struct tag_msp_ENDPOINT_RTPFDX_STATUS {

   // RTP Data
   DWORD        FilterId;
   DWORD        ipFilterState;
   IPADDRESS    localIPAddr;
   DWORD        localPort;
   IPADDRESS    remoteIPAddr;
   DWORD        remotePort;
   DWORD        rtcpEvents;
   DWORD        linkEvents;

   // RTP Stats
   DWORD        rxDrop;
   DWORD        rxPkts;
   DWORD        rxBytes;
   DWORD        txDrop;
   DWORD        txFail;
   DWORD        txPkts;
   DWORD        txBytes;

   // RTP Assembler Data
   DWORD        frame_quota;
   DWORD        assemble_dtmfFrames;

   // RTP Disassembler Data
   DWORD        last_pid_rcvd;
   DWORD        mismatches;
   DWORD        last_map_vocoder;
   DWORD        last_map_pid;
   DWORD        disassemble_dtmfFrames;
   DWORD        dtmf_event_control;

} msp_ENDPOINT_RTPFDX_STATUS;

The returned query structure provides the following information:

Unsolicited events

RTP IPv4 full duplex endpoints can return the following unsolicited events:

For more information about RTP endpoint unsolicited events or inband DTMF carriage, refer to the Fusion Developer's Manual.

Details

RTP payloads can contain more than one frame of encoded media referred to as compound payloads, or more generically, compound packets. For example, the G.723.1 vocoder produces frames that are 30 ms long. An RTP payload, or compound packet, can contain more than one of these frames. If it contained two, there are 60 ms of encoded information (two 30 ms segments packed sequentially).

Receiving data

Packets that the RTP IPv4 endpoint receives from the IPv4 network can contain a variable number of media frames. The endpoint adapts to the type of payload it receives. The frames in one compound packet may contain data from one type of encoder, while frames in the next compound packet contain data from a different type of encoder. RTP IPv4 endpoints separate frames into packets according to the characteristics of the detected encoder and transfers the frames in the same order in which the frames were assembled.

The RTP IPv4 endpoint timestamps output data for all but the first packet from a compound payload. These timestamps are derived from the timestamp in the compound packet's RTP header. The header timestamp is used for the first frame in the input payload.

The RTP header from the IPv4 network specifies the type of encoding in the payload through the payload_id field. The range of values for this field is static and is defined in the audio/video profile for RTP, RFC 1890 (draft 8). Unless otherwise notified, the filter expects these values for the vocoders Dialogic supports. For example, the static payload type value for G723.1 is 4. If the filter receives a value of 4 in the payload_id field, it assumes the payload encoding is G723.1. Applications can reassign payload_ids at any time.

Applications can assign G723.1 a different payload type value from the dynamic range 96 - 127. When this happens, the application must inform the RTP endpoint of the change (using the MSP_CMD_RTPFDX_MAP command) so that the endpoint accepts data associated with a different payload ID. Any vocoder can be assigned a dynamic payload type. If the RTP IPv4 endpoint receives compound packets (that is, packets with multiple frames per packet), the jitter filter depth must be set to a value greater than or equal to the number of frames per packet.

Sending data

The frame_quota parameter specifies the maximum number of media frames the endpoint includes in each payload. This quota should be set to the maximum number of frames that the encoding algorithm allows per payload. Applications can use the MSP_CMD_RTPFDX_CHG_QUOTA filter command to configure the RTP endpoint's frame quota.

The RTP endpoint transfers sequences of packets containing a media header and profile, and a payload containing one or more media frames. The header represents the first frame in the payload.

The following illustration shows an RTP IPv4 full duplex endpoint filter:

See also

DS0 full duplex endpoint filter, Jitter channel filter, RTP switching channel filter, Voice decoder and encoder channel filters