After quite a bit of tinkering we managed to get a multicast dial-peer working so that a call into a specific DN is then sent out to a specified multicast group. However there's a few moving parts to be considered, apart from the obvious enabling of multicast end to end between source & destinations. The Cisco Configure Land Mobile Radio (LMR) / Hoot and Holler Over IP on IOS-XE Voice Gateways document is very useful & includes various troubleshooting steps.
Summary of Steps
An analogue port has to be used to source the audio, attempting to use a SIP dial-peer to connect to the multicast dial-peer results in a 404 back from the gateway & a voice IEC syslog messsage about incompatible protocols:
%VOICE_IEC-3-GW: C SCRIPTS: Internal Error (Incompatible protocols): IEC=1.1.47.11.23.0 on callID
To get around this an FXS port was connected back to back with an FXO port, which is configured for PLAR to automatically dial the multicast dial-peer. So the call flow is: DN associated with FXS -> FXO -> multicast.
The multicast dial-peer must be set to a single specific CODEC, because there's no call control to negotiate CODECs.
A Vif interface is required with a /31 or larger mask to source the multicast from. Otherwise the source IP address will end up as nonsense like 0.0.0.1 or 255.255.255.255, resulting in downstream routers dropping the multicast traffic due to it failing the RPF check. The source IP address is actually the Vif interface IP address minus 1, e.g. .2 interface IP = .1 multicast source IP. It does appear to loop around so .1 interface IP = .255 multicast source IP with a /24 subnet mask.
On 4300/4400 series routers ip pim sparse-mode must be enabled on the Service-Engine interface that corresponds to the voice-port, e.g. voice-port 0/1/0 = service-engine0/1/0. Otherwise the audio won't be forwarded over the router's backplane & then out the egress interface.
4300/4400 series routers also have a bug CSCvk02072 that means the multicast RTP stream has DSCP BE (0) instead of EF (46). This can be re-marked via a suitable policy-map applied to the gateway's egress interface.
Lastly at least on IOS XE 16.3.5, for show rtp connection detail & show call active voice brief the transmit packet counters never increment, staying at zero & giving the impression that the audio isn't being sent when it actually is.
Config Snipppets
ip multicast-routing
!
ip access-list extended VOICE-RTP
permit udp any host 239.1.1.1 range 8000 48198
!
class-map match-any VOICE
match access-group name VOICE-RTP
!
policy-map MCAST-QOS
class VOICE
set dscp ef
!
interface Service-Engine0/1/0
description voice-port 0/1/0 backplane
ip pim sparse-mode
!
interface GigabitEthernet0/0/0
description Egress Interface
ip address 192.168.1.1 255.255.255.0
ip pim sparse-mode
service-policy output MCAST-QOS
!
interface Vif1
description Multicast Source Interface
ip address 172.16.0.255 255.255.255.254
ip pim sparse-mode
!
voice-port 0/1/0
connection plar 12345
!
dial-peer voice 100 voip
destination-pattern 12345
session protocol multicast
session target ipv4:239.1.1.1:16384
codec g711ulaw
vad aggressive
!
dial-peer voice 200 pots
incoming called-number .T
direct-inward-dial
port 0/1/0
Hi, that was a very interesting post.
ReplyDeleteI got here through searching for a solution to get a cisco router to subscribe to a multicast RTP stream, then pass the voice payload (G.711) to a DS0 channel of an installed E1 HWIC.
This would allow us to record the voice streams to a legacy voice recorder bridging IP to TDM.
Do you think that voice dial-peers could be used to do this with the LMR idea?
Multicast dial-peers are only for sending RTP to a multicast address, they don't send call control messages & can't answer calls. Using connection trunk requires a call to be established via H323 or SIP & then its pinned up out a specified port (https://www.cisco.com/c/en/us/support/docs/voice/h323/12432-trunk-config.html)
DeleteI think (& this is hypothetical, needs some labbing) you'd need to find a way to get the router to subscribe to the multicast RTP & play it out to a port with a connected call that's pinned up.
Possibilities include fudging with multicast music on hold, getting the router to connect the call, put it on hold so that it joins the multicast group for MoH & plays it out to the port. Alternatively H323/SIP messages can setup the call & directly specify one way audio with the multicast group as the IP address & port for incoming RTP.