RTP IPv6 full duplex endpoint filter

Provides entry and exit points for duplex voice over IPv6 data (data that includes RTP headers within UDP packets) at the IP interface. For information about RTP IPv6 endpoint parameters, refer to RTP IPv6 endpoint address structure and RTP IPv6 endpoint parameter structure.

Filter ID

MSP_ENDPOINT_RTPFDX_V6

Initialization structure

RTPRTCP_V6_ENDPOINT_PARMS

Restrictions

Used in the voice processing connections.

Channel connections

Can connect to full duplex voice channels.

Commands

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

RTP IPv6 FDX endpoints can receive commands any time after the endpoint is created with the exception of  MSP_CMD_RTPFDX_V6_CONFIG commands. The RTP IPv6 FDX endpoint must be disabled to receive  MSP_CMD_RTPFDX_V6_CONFIG commands.

When sending MSP_CMD_RTPFDX_V6_CONFIG commands, applications provide a pointer to an msp_ENDPOINT_RTPFDX_V6_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_V6_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 API expects a new value for every parameter in the msp_ENDPOINT_RTPFDX_V6_CONFIG structure.

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

Queries

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

Sending an MSP_QRY_RTPFDX_V6_STATUS query returns the following structure:

typedef struct tag_msp_ENDPOINT_RTPFDX_V6_STATUS {

   // RTP Data
   DWORD        FilterId;
   DWORD        ipFilterState;
   IPV6ADDR     localIPv6Addr;
   DWORD        localPort;
   IPV6ADDR     remoteIPv6Addr;
   DWORD        remotePort;
   DWORD        rtcpEvents;
   DWORD        linkEvents;
   DWORD        trafficClass;
   DWORD        flowLabel;
   DWORD        linkNum;

   // 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_V6_STATUS;

The returned query structure provides the following information:

Unsolicited events

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

For more information about RTP endpoint unsolicited events or inband DTMF carriage, refer to the Dialogic® NaturalAccess™ Fusion VoIP API 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. If it contained two, there are 60 ms of encoded information (two 30 ms segments packed sequentially).

Receiving data

Packets that the RTP IPv6 endpoint receives from the IP 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 can contain data from one type of encoder, while frames in the next compound packet contain data from a different type of encoder. RTP IPv6 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 IPv6 endpoint timestamps transfer 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 IP 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. However, applications can reassign payload_ids at any time.

You can assign G723.1 a different payload type value from the dynamic range 96 - 127. In this case, the RTP IPv6 endpoint must be informed of the change (through a MSP_CMD_RTPFDX_MAP command) so that it can accept data with a different payload ID. Any vocoder can be assigned a dynamic payload type. If the RTP IPv6 endpoint receives compound packets (that is, packets containing multiple frames per packet), the jitter filter depth value must be 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 IPv6 full duplex endpoint filter:

See also

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