R2511-HP MSR Router Series Voice Configuration Guide(V5)

321
Configuring PSTN-dialed number
Ste
p
Command Remarks
1. Enter system view.
system-view N/A
2. Enter voice view.
voice-setup N/A
3. Enter voice dial program
view.
dial-program N/A
4. Enter VoFR entity view.
entity entity-number vofr N/A
5. Configure a PSTN-dialed
number in the FRF.11 trunk
mode.
trunk-id string
By default, no PSTN-dialed number
is configured in the FRF.11 trunk
mode.
Configuring call control protocol
Ste
p
Command Remarks
1. Enter system view.
system-view N/A
2. Enter serial interface view.
interface serial interface-number N/A
3. Specify the link layer protocol
for interface encapsulation as
frame relay.
link-protocol fr [ ietf |
nonstandard ]
By default, the link layer protocol
for interface encapsulation is PPP.
4. Enter interface DLCI view.
fr dlci dlci-number N/A
5. Configure a VoFR call control
protocol on DLCI.
vofr { huawei-compatible [ dce |
dte ] | nonstandard-compatible
signal-channel ccid-no
data-channel dcid-no
[ keepalive ] }
By default, no VoFR call control
protocol is supported.
In the FRF.11 trunk mode, if the VoFR call control protocol is Huawei-compatible, the cid-number of the
channel to the destination host cannot be 4 or 5 because these two CIDs are already occupied by the
system. If the call control protocol is nonstandard-compatible, the cid-number of the channel to the
destination host cannot conflict with any data sub-channel number or signaling sub-channel number. In
the FRF.11 trunk mode, the Motorola-compatible protocol is not supported.
In the FRF.11 trunk mode, two voice entities (one VoFR entity and one voice entity of any type) must be
configured at each end of the trunk. The PSTN-dialed number of the VoFR entity must be consistent with
the match-template of the other voice entity.
Configuring trunk timer length in FRF.11 trunk mode
No signaling is exchanged in the FRF.11 trunk mode. After the terminating voice gateway in idle state
receives a voice packet, it considers that a new call is arriving. When one party hangs up, the other party
is not notified of on-hook through signaling messages, but will still keep sending voice packets. In this
case, if the voice gateway on the side of the party who hung up does not discard these voice packets, but
considers that they come from a new call, then the party who just hung up will be alerted again so that
on-hook could never succeed.
You can configure the voice gateway to discard the received voice packets within the trunk wait timer
length after on-hook, so that the party concerned can hang up successfully.