10-06-2021 07:47 AM
Hi,
I have one CUBE with IOS XE 16.12.5 with one SIP Trunk to PSTN with Redundant links.
When primary link goes down only incoming calls from PSTN are failing because CUBE as soon receives INVITE reply with SIP/2.0 488 Not Acceptable Media.
I have discovered that incoming calls were matching the Dial-peer that is binded with interface of primary link that is down and dial-peer are busyout. If i shutdown that dial-peers (1 and 2) call works. Any suggestion how to overcome this issue?
I have this config:
dial-peer voice 1 voip
description SIP Trunk SP SBC1 - Primary link.
preference 1
destination-pattern 0T
session protocol sipv2
session target ipv4:1.1.1.1
incoming called e164-pattern-map 1
voice-class codec 1
voice-class sip options-keepalive up-interval 10 down-interval 10 retry 3
voice-class sip bind control source-interface GigabitEthernet0/0/0
voice-class sip bind media source-interface GigabitEthernet0/0/0
dtmf-relay rtp-nte
no vad
!
dial-peer voice 2 voip
description SIP Trunk SP SBC2 - Primary link.
preference 2
destination-pattern 0T
session protocol sipv2
session target ipv4:2.2.2.2
incoming called e164-pattern-map 1
voice-class codec 1
voice-class sip options-keepalive up-interval 10 down-interval 10 retry 3
voice-class sip bind control source-interface GigabitEthernet0/0/0
voice-class sip bind media source-interface GigabitEthernet0/0/0
dtmf-relay rtp-nte
no vad
!
!
dial-peer voice 3 voip
description SIP Trunk SP SBC1 - Backup link
preference 3
destination-pattern 0T
session protocol sipv2
session target ipv4:1.1.1.1
incoming called e164-pattern-map 1
voice-class codec 1
voice-class sip options-keepalive up-interval 10 down-interval 10 retry 3
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 4 voip
description SIP Trunk SP SBC2 - Backup link
preference 4
destination-pattern 0T
session protocol sipv2
session target ipv4:2.2.2.2
incoming called e164-pattern-map 1
voice-class codec 1
voice-class sip options-keepalive up-interval 10 down-interval 10 retry 3
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
!
Regards,
10-06-2021 09:15 AM
in general i would recommend having separate inbound and outbound dial peers.
there is seldom, definitely not in your configuration, a need to have a preference assigned to an inbound dial peer.
10-06-2021 10:29 AM
Does you ISP accept call from both interfaces ? AFAIK they accept the calls from the interface connected to their device. Normally they provide you a 252 subnet IP.
In this case you can think of a BVI interface.
10-06-2021 10:33 AM
Hi,
I managed to solve using incoming uri request whit the two diferent ip address on CUBE instead of using incoming called e164-pattern-map.
10-06-2021 11:57 AM
In general using URI mapping is a much better option for inbound match of dial peer. And I do agree with other posts that it’s typically better to use different dial peers for each direction as that makes it much easier to differentiate between them.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide