Did you update your trusted

nbspooney · ‎04-26-2017

I'm currently migrating to 4331 ISR's from 2800 series routers. Has anyone had issues with the

NAME: "NIM subslot 0/2", DESCR: "NIM-2FXS/4FXO Voice Analog Module"
PID: NIM-2FXS/4FXO , VID: V01, SN: FOC20375GE1

NAME: "PVDM subslot 0/4", DESCR: "PVDM4-32 Voice DSP Module"
PID: PVDM4-32 , VID: V02, SN: FOC2043447F

not passing voice traffic

cisco ISR4331/K9 (1RU) processor with 3696789K/6147K bytes of memory.
Processor board ID FLM2101W0AB
3 Gigabit Ethernet interfaces
1 Serial interface
1 Channelized T1/PRI port
4 Voice FXO interfaces
2 Voice FXS interfaces

Mohammed al Baqari · ‎04-26-2017

Hi,

During active call, please share 'show call active voice bri'. Also, is it CUCM or CME deployment and if CUCM how you are connected to CUCM.

Suresh Hudda · ‎04-26-2017

And, check routing as well..make sure you have correct ip route added.

Suresh

nbspooney · ‎04-27-2017

Suresh,

The only thing that has changed in the environment is the addition of the 4331 ISR. We have 2800's working fine in the environment but when we add the ISR 4k's calls to the FXS/FXO ports not working. The config is the same .

CiscoPro08 · ‎07-24-2017

Did you update your trusted ip address list on the 4331?

As a security measure, you have to add trusted IP addresses to a list in the config:

voice service voip
ip address trusted list

ipv4 10.11.12.13

ipv4 10.11.12.14

ipv4 10.11.12.15

Then to verify:

CUBE#sh ip address trusted list

b.winter · ‎03-02-2022

Just for someone, who may read this in the future:

The trust list has nothing to do with audio problems.

The trust list regulates, from which servers it is allowed to send SIP (also H.323?) requests to the CUBE.

If an IP of a server is not in the trust list, CUBE will discard any request.

Since audio is running via RTP (obviously not SIP), adding IP's to the trust list won't have an effect on any voice problems.

dtran · ‎10-25-2019

Hi, there

What was the final fix to your issue ?

I am experiencing the same problem after replacing my old Cisco 2901 with a new Cisco 4351. I am experiencing one-way audio on PSTN calls where the called party can here me but I can't hear the called party on my Cisco IP phone. The issue happens on both incoming and outgoing PSTN calls. Internal IP to IP calls are working fine. I basically replicate the config on old 2901 over to the new 4351, no other changes made on network infrastructure side.

Thanks in advance !!! I appreciate your feedback on this issue !!!

Danny

ajmlopez · ‎10-26-2021

Hi,

Somebody find any solution to this problem? I have the same problem now migrating from old voice gateway to isr 4431. Only one-way audio.

Thanks in advance!!

Antonio

resolveits · ‎03-01-2022

Hi,

I also have this issue, can you please let us know what your solution was?

resolveits · ‎03-02-2022

Hi Everyone,

Thank you for your replies.

The issue with my config is that if I bind the source interface to GigabitEthernet0/0/0.2 I can receive incoming calls with audio but not make outbound calls.

If I bind all to GigabitEthernet 0/0/1 I can make outbound calls but not receive incoming calls.

I do not know why incoming sip calls are blocked by the router. See config:

voice service voip
ip address trusted list
ipv4 54.172.60.0
ipv4 54.171.127.192
ipv4 54.65.63.192
ipv4 54.169.127.128
ipv4 54.252.254.64
ipv4 177.71.206.192
ipv4 54.169.127.129
ipv4 54.169.127.130
ipv4 54.169.127.131
ipv4 3.104.90.0 255.255.255.0
ipv4 54.252.254.64 255.255.255.192
ipv4 54.252.254.64 255.255.255.252
ipv4 103.75.151.64 255.255.255.192
ipv4 103.75.151.68
ipv4 103.75.151.69
ipv4 103.75.151.70
ipv4 10.0.0.0 255.255.255.0
ipv4 10.0.2.0 255.255.255.0
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
no supplementary-service sip moved-temporarily
no supplementary-service sip refer
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
sip
bind control source-interface GigabitEthernet0/0/0.2 or bind control source-interface GigabitEthernet0/0/1
bind media source-interface GigabitEthernet0/0/0.2 or bind media source-interface GigabitEthernet0/0/1

registrar server expires max 3600 min 600
midcall-signaling passthru media-change
no call service stop

===//====

interface GigabitEthernet0/0/0
description Arris CM8200 NBN
no ip address
ip nat outside
media-type rj45
negotiation auto
no mop enabled
ip virtual-reassembly
!
interface GigabitEthernet0/0/0.2
description WAN Connection VLAN 2 TPG
encapsulation dot1Q 2
ip nat inside
pppoe enable group global
pppoe-client dial-pool-number 1
!
interface GigabitEthernet0/0/1
ip address 10.0.0.1 255.255.255.0
ip nat inside
negotiation auto
no mop enabled
!
interface GigabitEthernet0/0/2
no ip address
shutdown
negotiation auto
!
interface GigabitEthernet0
vrf forwarding Mgmt-intf
no ip address
shutdown
negotiation auto
!
interface Dialer1
ip address negotiated
ip nat outside
encapsulation ppp
ip tcp adjust-mss 1452
dialer pool 1
ppp pap sent-username xxxxxx password 0 xxxxxx
!
ip default-gateway 10.0.0.1
ip forward-protocol nd
ip http server
ip http access-class 1
ip http authentication local
ip http secure-server
ip http client username cisco
ip http client password 0 cisco
ip http path flash:
ip tftp source-interface GigabitEthernet0/0/1
ip nat inside source list 1 interface Dialer1 overload
ip route 0.0.0.0 0.0.0.0 Dialer1
!
ip ssh version 2
!
access-list 1 permit any

b.winter · ‎03-02-2022

Then do not bind the source interfaces in global voice config (voice service voip --> sip), do the binding on dial-peer level.

Bind the "internal" interface on the internal facing dial-peers, and the "external" interface on the external facing dial-peers.

Also:

I wouldn't configure static routes pointing to the external side.

With PPP you will probably get a public IP and furthermore, the router will point the default route 0.0.0.0 0.0.0.0 towards the public gateway of this subnet automatically (will get it also via PPP).

Therefore, I would change the following config:

no ip route 0.0.0.0 0.0.0.0 Dialer1

ip route 10.0.0.0 255.0.0.0 [Default GW of 10.0.0.0/24 subnet]

ip route 172.16.0.0 255.240.0.0 [Default GW of 10.0.0.0/24 subnet]

ip route 192.168.0.0 255.255.0.0 [Default GW of 10.0.0.0/24 subnet]

Everything that is public will take the default route towards your provider.

Every private IP will be sent via the "internal" interface to inside

What do you use the NAT for?

If your router only acts as CUBE and you get a public IP for your Dialer1, you wouldn't need NAT for the calls.

resolveits · ‎03-02-2022

Hi b.winter,

Thanks for that.

I have now used the bind command on the dial peers as below and it works well.

I need the NAT as this ISR4331 is also a router for PC's on the internal network among other things. I will change the default routes and see if that resolves the DNS ping issue. Thank you.

dial-peer voice 200 voip
description **Twilio Outgoing Call SIP Trunk**
translation-profile outgoing twilio-out
destination-pattern 04........
session protocol sipv2
session target sip-server
voice-class codec 1
voice-class sip bind control source-interface GigabitEthernet0/0/1
voice-class sip bind media source-interface GigabitEthernet0/0/1
dtmf-relay rtp-nte
no vad
!
dial-peer voice 100 voip
translation-profile incoming twilio-in
session protocol sipv2
session target sip-server
incoming called-number .%
voice-class codec 1
voice-class sip bind control source-interface Dialer1
voice-class sip bind media source-interface Dialer1
dtmf-relay rtp-nte
no vad

Cisco ISR4331 one-way audio