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 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
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
You can configure the parameters that a VPG uses to detect and report latch deadlocks.
Detection—The VPG 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 PG 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 PGC 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 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 VPG reports the inactivity to the PGC.
Reporting—Reporting of the media inactivity occurs in one of the following ways:
 | Copyright © 2008, Juniper Networks, Inc. All rights reserved. Trademark Notice. | |