Control of Voice Flows with Gates Overview
This topic describes how the virtual BGF controls voice flow with gates:
Using Gates for Voice Flows
The BGF uses gates to control voice flows in the transport plane. Gates are created through signaling instructions that the gateway controller provides to the BGF. Using the signaling instructions, the BGF defines gates to allow, drop, or manipulate voice flows as they traverse the router.
Each gate provides a unidirectional voice flow. A pair of gates provides a bidirectional voice flow. Figure 1 shows a unidirectional gate.
Figure 1: Unidirectional Gate
Gate Addressing
Gates are defined by their local source and destination addresses and their remote source and destination addresses.
Figure 2 shows a gate pair, which represents a bidirectional voice flow. The local destination address of Gate 1 is equal to the local source address of Gate 2, and the local source address of Gate 1 is equal to the local destination address of Gate 2.
Figure 2: Addressing of Gate Pairs
Gate Opening, Closing, and Modification Overview
Based on information acquired through VoIP signaling, the gateway controller instructs the BGF through H.248 commands which gates to create and which actions to associate with them. Each gate can have many actions associated with it; for example, NAT, Differentiated Services (DiffServ) code point (DSCP) marking, and latching. The pgcpd process decodes H.248 commands that it receives from the gateway controller and uses IPC messages to instruct the PIC or DPC to create, delete, or modify gates and apply required actions to each gate.
The following IPC messages are exchanged between the pgcpd process and the PIC or DPC:
- Gate open request
- Gate close request
- Gate audit request
- Gate modify request
- Gate open reply
- Gate close reply
- Gate audit reply
- Gate modify reply
- Gate notification reply
Gate Identification
When a gate is created, it is assigned an identifier. You can use this identifier with the show services pgcp gates commands to monitor specific gates.
Forward and Drop Operations for RTP and RTCP Gates
You can use the StreamMode property in the LocalControl Descriptor of H.248 messages to change the mode of Realtime Transport Protocol (RTP) gates without affecting the mode of Real-Time Control Protocol (RTCP) gates. That is, you can put RTP gates in drop mode while leaving RTCP gates in forward mode.
To view whether RTP and RTCP gates are in drop mode or forward mode, use the show services pgcp flows command. The following example shows a gate in which the RTP stream is in drop mode, and the RTCP stream is in forward mode.
user@host> show services pgcp flows
gateway bgf-1Gate id: 4295033089
UDP 20.50.170.110:0 -> 20.50.170.2:1024 Drop I 0
NAT source 20.50.170.110:0 -> 10.50.170.1:1024
NAT dest 20.50.170.2:1024 -> 10.50.170.110:20000
Gate id: 4295033089
UDP 20.50.170.110:0 -> 20.50.170.2:1025 Forward I 0
NAT source 20.50.170.110:0 -> 10.50.170.1:1025
NAT dest 20.50.170.2:1025 -> 10.50.170.110:20001 Latch Deadlock and Media Inactivity Detection and Reporting
You can configure the parameters that a virtual BGF uses to detect and report latch deadlocks.
Detection
The virtual BGF uses an inactivity timer to detect a latch deadlock or other media inactivity on a gate. The timer tracks the receipt of media packets during a specified time interval.
When a latching signal exists for a termination, the BGF places the termination in a Drop state. All incoming traffic to the relevant gate egressing the termination is dropped until the first IP traffic datagram enters the termination (ingress). At this point the remote descriptor on the termination and egress gate is updated to forward traffic to the newly acquired source. The latch signal is removed from the gate when the gateway controller receives an H.248 Notify message containing the newly acquired IP address. Deadlock occurs when an error occurs regarding the source IP address and port that prevents the endpoint from returning data to the source address.
The detection process is activated in one of the following ways:
- The gateway controller requests quality (QUA) alerts.
- The gateway controller requests application data inactivity detection (ADID) alerts.
- The CLI is used to configure a forced service change when media inactivity occurs.
The inactivity timer tracks the receipt of media packets during a specified interval of time (inactivity duration). If no media packets are received during this time interval, the virtual BGF reports the inactivity to the gateway controller.
Reporting
Reporting of the media inactivity occurs in one of the following ways:
- If the virtual BGF detects a latch deadlock or media inactivity and you have configured the virtual BGF to force a service change, the virtual BGF stops service on the gate and sends the gateway controller a ServiceChange message using either error code 906 (Loss of Lower Layer Connectivity) or 910 (Media Capability Failure). The virtual BGF then takes the affected termination out of service, but does not subtract the termination.
- If you have not configured the virtual BGF to force a service change, the virtual BGF sends a QUA or ADID notification message, depending on which type of notification was requested by the gateway controller.
