The voice feature uses gates to control voice flows in the transport plane. Gates are created through signaling instructions that the PGC provides to the PG. Using the signaling instructions, the PG 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 15 shows a unidirectional gate.
Figure 15: Unidirectional Gate
Gates are defined by their local source and destination addresses and their remote source and destination addresses.
Figure 16 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 16: Addressing of Gate Pairs
Based on information acquired through VoIP signaling, the PGC instructs the packet gateway through PGCP 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 PGCP commands that it receives from the PGC and uses IPC messages to instruct the PIC 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:
When a gate is created, it is assigned an identifier. You can use this identifier with the PGCP show commands to monitor specific 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 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
Gate 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
To detect a latch deadlock on a gate, the packet gateway uses a timer for the interval between when the packet gateway requests a latch and when it receives a latch event from the PGC. If the packet gateway does not detect a latch event within this time period, it notifies the PGC using error code 910 (Media Capability Failure) in a ServiceChange message. The PG then disables the affected termination, but does not subtract the termination. The latch deadlock is applied only on RTP streams; that is, RTCP activity is not used to detect latch deadlocks.
To configure the timer, include the latch-deadlock-duration statement at the [edit services pgcp gateway gateway-name] hierarchy level. You cannot use the timer along with the gate inactivity delay and the gate inactivity duration timer.
To troubleshoot latching deadlock reporting, use the following command:
user@host> show log pgcp match “received
gate latch deadlock”
Nov 11 11:11:11 GATE: Manager received gate latch deadlock Gate Id = 4295033089