Re: Assistance with CUBE SIP-Profile and Outbound Dialing Config FXS

mumbles202 · ‎06-07-2023

Working on a 4321 w/ a SIP trunk from an ITSP and a FXS card. Incoming calls should route to CUCM, unless it hits 1 of 2-3 numbers in which those numbers should get routed to a port on the on-board FXS card. As of right now I'm having 2 issues:

1.) Calls from the carrier inbound are ringing in w/ the correct called number appearing in the Diversion header, but not the To field in the Invite. The "To" field contains the number used for registration to the ITSP, which happens to be the BTN. So I call 1112223333, and the invite I receive looks like this:

From: "Test Caller" <sip:9294447777@172.25.101.8>;tag=A.B.C.D+1+4a4ff931+afb0bf49
To: <sip:9295556666@172.25.101.8>
Referred-By: <sip:1112223333@10.6.192.8>
Diversion: <sip:1112223333@10.6.192.8>;reason=unconditional

where 9295556666 is the BTN

2.) Outbound calls from the devices attached to the FXS card are failing.

To get around issue #1, until the carrier is able to advise why this is happening, I attempted to add this:

voice class sip-profiles 100
request INVITE sip-header Diversion copy "<sip:(.*)@.*" u01
request INVITE sip-header To copy ".*<sip:(.*)@.*" u02
request INVITE sip-header To modify "(.*)<sip:.*@(.*)" "\1<sip:\u01@\2"

But that seemed to have no impact (I added the profile to the incoming dial-peer).

With respect to issue #2, I have the following configured:

dial-peer voice 4724 pots
destination-pattern 4724
port 0/1/0
!
dial-peer voice 6924 pots
destination-pattern 6924
port 0/1/1

I suspect the issue w/ the outbound calls is I'm missing a dial-peer for the inbound side of the call from the FXS ports. My outgoing dial-peer to the ITSP is as follows:

dial-peer voice 5 voip
description Calls to PSTN
session protocol sipv2
session server-group 1000
destination e164-pattern-map 1000
voice-class codec 1
voice-class sip options-keepalive profile 1
voice-class sip bind control source-interface GigabitEthernet0/0/0
voice-class sip bind media source-interface GigabitEthernet0/0/0
dtmf-relay rtp-nte digit-drop
no vad

voice class e164-pattern-map 1000
description E164 Pattern Map for called number to ITSP
e164 0T
e164 [2-9]..[2-9]......
e164 [2-9]......
!

My incoming dial-peer is the following which might be part of the issue for #2:

dial-peer voice 1 voip
 description Incoming calls from PSTN
 translation-profile incoming PSTN-IN
 session protocol sipv2
 destination dpg 1
 incoming uri via ITSP
 voice-class codec 1  
 voice-class sip profiles 100
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte digit-drop
 no vad

Roger Kallberg · ‎06-07-2023

For question #1 it’s not the To field in the invite that is used for call routing, it’s the request URI.

For question #2 create a POTS dial peer that is used in the inbound direction. Your VoIP dial peers have nothing to do with this.

mumbles202 · ‎06-08-2023

I've added the following dial-peer:

dial-peer voice 2 pots
incoming called-number .
direct-inward-dial

but currently I'm still unable to make outbound calls. I'll try to gather some debugs.

With respect to issue #1, I'll see what I can do about this. I would've thought if I was calling a number it would appear as the number dialed in the invite but that doesn't seem to be the case w/ what I'm receiving.

mumbles202 · ‎06-08-2023

I tried adding the following

voice class sip-profiles 100
request INVITE sip-header Diversion copy "<sip:(.*)@.*" u01
 request INVITE sip-header SIP-Req-URI modify "(.*)<sip:.*@(.*)" "\1<sip:\u01@\2"

to the incoming dial-peer but that didn't seem to work to fix the issue.

Roger Kallberg · ‎06-08-2023

For inbound SIP profile you need to use specific configuration commands to enable it. For details about this see this document.

Use SIP Profiles on CUBE Enterprise Common Use Cases

mumbles202 · ‎06-08-2023

Thanks. So I enabled "sip-profiles inbound" under voice services voip, created the below profiles and applied them inbound on the dial-peer from the ITSP. I've confirmed that it's applied to the dial-peer call that is being selected on the inbound call leg from the ITSP. None of these seem to address the issue as the calls don't complete at that point

voice class sip-profiles 100
 request INVITE sip-header Diversion copy "<sip:(.*)@.*" u01 
 request INVITE sip-header SIP-Req-URI modify "(.*)<sip:.*@(.*)" "\1<sip:\u01@\2" 
!
voice class sip-profiles 1
 request INVITE sip-header Diversion copy "<sip:(.*)@.*" u01 
 request INVITE sip-header To modify "(.*)<sip:.*@(.*)" "\1<sip:\u01@\2" 
 request INVITE sip-header SIP-Req-URI modify "(.*) sip:.*@(.*)" "\1<sip:\u01@\2" 
!
voice class sip-profiles 10
 request INVITE sip-header Requested-By copy "sip:(.*)@" u01 
 request INVITE sip-header SIP-Req-URI modify ".*@(.*)" "INVITE sip:\u01@\1"

For the issue w/ the outgoing calls, I have the following 2 dial-peers which I thought would address the issue:

voice class dpg 2
 dial-peer 89999


dial-peer voice 2 pots
 destination dpg 2
 incoming called-number .
 direct-inward-dial
!
dial-peer voice 89999 voip
 destination-pattern .T
 session protocol sipv2
 session transport udp
 session server-group 2010
 codec g711alaw
 no vad

Roger Kallberg · ‎06-09-2023

You need to use a copy list on the inbound dial peer and then use it to copy the field that you want to carry over to the outbound dial peer. From what I know you can not modify the invite inbound to the inbound dial peer, as the processing order will not allow it.

mumbles202 · ‎06-09-2023

Ok, thanks for this. I'll have to find a good guide on processing order and the profiles to better understand what's causing the issue. In my Request-URI the ITSP is placing the BTN on all the inbound calls and placing the actual called-number in the referred-by and diversion headers. I'm trying to figure out a way for me to route the calls based on that header.

I had a dpg configured but based on some further reading this isn't a good option here since the destination pattern of the configured dial-peers in the group won't be considered for matching.

mumbles202 · ‎06-13-2023

So I worked with ITSP today and was able to get most of this working properly. The 2 real outstanding issues are below:

1.) Prior to going SIP, the 4 numbers that now point to the FXS ports were configured by the carrier to rollover to the next line if busy. Only 1 number is given out to the public. As users end up calling only the 1 number, the 2nd and 3rd calls fail as the port is in use.

2.) For outbound calling, if I use .T as the destination pattern, the call has a delay of 10 seconds before it actually dials out. If I make the destination pattern more specific the delay is only about 2 seconds, but then the dial-peer only covers a handful of possible outbound calls and doesn't cover international calls.

TechLvr · ‎06-14-2023

1. For FXS rollover, use example below.

trunk group FXS

voice-port 0/1/0
trunk-group FXS 1

voice-port 0/1/1
trunk-group FXS 2

voice-port 0/1/2
trunk-group FXS 3

voice-port 0/1/3
trunk-group FXS 4

dial-peer voice 1 pots
trunkgroup FXS
destination-pattern 123444 (replace 123444 with the actual number)

Note: If your fxs ports are controlled by mgcp, the above config won’t work. In that case, you should use the cucm method to accomplish this as you mentioned yourself.

2. To get around the inter-digit timeout issue on your outbound calls, the most effective method is to use e164-pattern-map since you use sip toward the carrier. I believe you should already be using this in some parts of your configs as you shared the below snippet in one of your previous posts.

voice class e164-pattern-map 1000
description E164 Pattern Map for called number to ITSP
e164 0T
e164 [2-9]..[2-9]......
e164 [2-9]......

dial-peer voice 5 voip
description Calls to PSTN
session protocol sipv2
session server-group 1000
destination e164-pattern-map 1000
voice-class codec 1
voice-class sip options-keepalive profile 1
voice-class sip bind control source-interface GigabitEthernet0/0/0
voice-class sip bind media source-interface GigabitEthernet0/0/0
dtmf-relay rtp-nte digit-drop
no vad

mumbles202 · ‎06-15-2023

Thanks for the this. That worked for the inbound calls and not having to roll them over to CUCM and back. I'll make sure this works w/ more testing but so far it's worked well and I've confirmed the rollover based on the voice ports on the 4321. I had created a 2nd outbound dial-peer w/ a destination-pattern of 1[2-9].........$ which solved that issue, but I can update the e164-pattern-map and remove that dial-peer. I'll give both a try in the morning.

mumbles202 · ‎06-14-2023

If I wanted to send the calls destined for the FXS ports to CUCM and then back to the Cube would this be the best guide to follow:

Analog FXS Port SIP Registration with CUCM (cisco.com)

I need the calls to roll from one port to another in the event the first "line" is in use. I think the best way to accomplish this would be to send the call to CUCM to a hunt pilot and then have the calls line sequentially.