SIP P-Asserted-Identity of Other SIP Trunk's NATed Address

[Michael Mertens]

Hello All,

I'm looking to understand some mechanics of SIP and PAI here, as I don't think my problem is a Cisco/CUBE configuration but rather something with the FW doing NAT and needing Application Bypass configuration(s). 

Topology: Inside VoIP network<-> Cisco SBC CUBE <-> PAN FW doing NAT <-> AT&T IPBEs (See attached JPG diagram).

Background: CUBE/firewall has existing, working trunk terminating on CUBE from AT&T. We are attempting to add a 2nd AT&T SIP trunk through the same FW and terminating on the same CUBE. FW is configured to translate to AT&T assigned outside address for traffic destined/sourced from trunk A IPBEs, and configured to translate to a different, AT&T assinged outside address for traffic destined/sourced from trunk B IPBEs. We are using a test DID for circuit validation. 

Symptom: On new trunk "B", outgoing calls work. Incoming calls complete but disconnect after ~ 20 seconds, though both called and caller can hear each other. CUBE logs a SIP Timeout error message; debug ccsip message shows (Call coming into Trunk B test DID)

Carrier -> INVITE -> CUBE

CUBE-> TRYING -> Carrier

CUBE -> RINGING -> Carrier

CUBE-> SIP 200 OK -> Carrier

(no SIP ACK received from carrier)

(no SIP ACK received from carrier)...

SIP Timeout on CUBE/Call disconnects...

Details: PCAP (from AT&T) shows that AT&T sends the SIP ACK to the NATed/outside address of Trunk A!! However, further, deeper analysis of the PCAP shows that we send our SIP 200 OK with a P-Asserted-Identity with "Contact: <sip: 8455926502@Trunk_ A Outside Address". So the thought is AT&T is responding to this and sending the SIP ACK on Trunk A's assigned customer address.

As the SBC CUBE is not aware of the AT&T assigned media/control IP addresses (NATed by the firewall), I believe it is the PA firewall doing some type of application fix-up and am trying to get Application Bypass configured on the firewall. However, I'm hoping to get A) Some review of my thoughts and direction B) some understanding of SIP PAI's typical use C) Whether I can modify the SIP header/profile to cure the probability of the FW inserting the PAI of the trunk A address?

Any direction/help/input would be appreciated- Right now I'm over my skis in SIP...THANKS!

[b.winter]

Where is the configuration for SIP Trunk B?
How do you distinguish between 2 NAT IP adress on the FW, if you only have 1 IP pointing to external on the CUBE.
How should the FW know, which NAT IP adress and rules to apply? The FW doesn't know anything about SIP trunks.

And in most FW, you have SIP ALG config. This should be disabled.
But then, you need to manipulate the IP-adresses in the SIP headers on the CUBE with SIP profiles. Because the FW will only NAT Layer 3 IP, and not above.

In your case, CUBE will always use the same IP adress in all the SIP headers, because it's the only IP he knows of (GigabitEthernet0/0/1)

[Michael Mertens]

B.Winter,

Trunk A has two different IPBEs from Trunk B. In the FW, its NAT rule states: "if destined to Trunk A IPBEs, use NAT address 32.253.23.162. If the packet is destined to trunk B IPBEs, then use NAT address 32.253.59.194.

"The configuration for SIP Trunk B" is only in matching the same dialpeers (for inbound calls) as SIP trunk A. For outbound calls, I do have a dial-peer that points the 10-digit destination-pattern to the trunk B IPBEs.

At the last is seems A) Have the SIP ALG disabled/Application Bypass enabled. B) Create a dial-peer for the incoming called-number matching the Trunk B test-DID and apply a new SIP Profile which will modify the P-Inserted-Identify of the Trunk B outside IP address? I'm confused on the mechanics of the SIP header modifications. If the INVITE comes in from the carrier, then I would want to configure as a response to the INVITE: "response ANY sip-header contact MODIFY "<sip:(.*)@TRUNK_B_IPADDRESS:5060?"

Thank you for the input!!!

[b.winter]

How do you route anything to the provider in the first place? There is no dial-peer with the destinations of any of the provider IP address.

E.g. DP 200:
- where is the outgoing dial-peer matching pattern?
- Where is the session-target or session-server group to point the SIP messages to?
- It only has an incoming dial-peer matching pattern (incoming called-number).

My recommendation:
Use 1 set of dial-peers for Provider A and another set of dial-peers for provider B.
Then you have the control, on how to manipulate messages for each provider indepentently.
And if you have already SIP activated on the router, also use SIP between the router and CUCM. H.323 is an old protocol.

Another question:
How would you distinguish, which outgoing call should go to provider A or B in the first place? (so from CUCM --> Router --> Provider).
Either you don't care, then my question for DP 200 still apply. Or you didn't think about it.

Honest opinion:
Your whole setup has not been thought about and prepared carefully.
I don't see, what you are trying to achieve with 2 SIP trunks in the first place. For redundancy? Different number ranges? ... This has to be clarified first, and only after that also this weird network setup.

[Michael Mertens]

B. Winter, 

I left the outgoing calls outgoing-leg out of the config I posted because outgoing works. Please see below for the outgoing dial-peer. NOTE: This is only to test/validate the functionality for outgoing calls.

!
dial-peer voice 299 voip
description Outgoing to AT&T -AT&T Call Trunk B
translation-profile outgoing pstn-out
preference 4
destination-pattern 915189254753
no modem passthrough
session protocol sipv2
session target ipv4:12.253.103.134
voice-class codec 1
voice-class sip asymmetric payload full
voice-class sip asserted-id pai
voice-class sip privacy-policy passthru
voice-class sip profiles 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
fax rate 14400
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
ip qos dscp cs3 signaling
no vad
!

The reason for the dual trunks (perhaps I should have explained): This site was divested/sold. Prior to the sale, we used Trunk A for production calls. Part of the divestiture agreement was that we would provision another trunk (Trunk B) on the same equipment (CUBE) so the buyer didn't have to purchase new hardware. After testing Trunk B, we would port the DIDs from Trunk A to Trunk B, and decomm trunk B. We cannot do a Transfer of Service agreement with the carrier(s) to change a circuit's ownership, however, we can do that with DIDs.

Once we validate outgoing and incoming calls work on the 2nd trunk using test DIDs (for incoming calls) and test destination-patterns to specific PSTN DNISs for outgoing calls, I'll just have to change the session target to the new IPBEs on outgoing peers, and have AT&T port the DIDs to Trunk B. Please see below for our current dialpeers for outgoing calls on Trunk A:

!
dial-peer voice 201 voip
description Outgoing to AT&T -AT&T Call Leg Primary IPBE
translation-profile outgoing pstn-out
preference 1
destination-pattern 9T
no modem passthrough
session protocol sipv2
session target ipv4:12.253.1.102
voice-class codec 1
voice-class sip asymmetric payload full
voice-class sip asserted-id pai
voice-class sip privacy-policy passthru
voice-class sip early-offer forced
voice-class sip profiles 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
fax rate 14400
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
ip qos dscp cs3 signaling
no vad
!
dial-peer voice 202 voip
description Outgoing to AT&T -AT&T Call Leg Secondary IPBE
translation-profile outgoing pstn-out
preference 2
destination-pattern 9T
no modem passthrough
session protocol sipv2
session target ipv4:12.194.107.142
voice-class codec 1
voice-class sip asymmetric payload full
voice-class sip asserted-id pai
voice-class sip privacy-policy passthru
voice-class sip profiles 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
fax rate 14400
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
ip qos dscp cs3 signaling
no vad
!
dial-peer voice 203 voip
description Outgoing to AT&T -AT&T Call Leg Tertiary IPBE
translation-profile outgoing pstn-out
preference 3
destination-pattern 9T
no modem passthrough
session protocol sipv2
session target ipv4:12.253.102.86
voice-class codec 1
voice-class sip asymmetric payload full
voice-class sip asserted-id pai
voice-class sip privacy-policy passthru
voice-class sip profiles 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
fax rate 14400
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
ip qos dscp cs3 signaling
no vad
!
dial-peer voice 204 voip
description Outgoing to AT&T -AT&T Call Leg Quarternary IPBE
translation-profile outgoing pstn-out
preference 4
destination-pattern 9T
no modem passthrough
session protocol sipv2
session target ipv4:12.253.103.134
voice-class codec 1
voice-class sip asymmetric payload full
voice-class sip asserted-id pai
voice-class sip privacy-policy passthru
voice-class sip profiles 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
fax rate 14400
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
ip qos dscp cs3 signaling
no vad
!

I hope this helps to explain things. Thank you for your continued input.

Mike

[Scott Leport]

Hi,

Generally, you're better off disabling SIP ALG / Inspection on your PAN altogether and using SIP profiles to modify the IP addressing from private to public. Some examples of how to do that listed here:

https://afterthenumber.com/2018/12/21/supporting-cube-nat-integrations-without-firewall-alg/

I would also suggest enabling sip early-offer in your global SIP config on the CUBE. There was an example of how to enable that in the link I previously shared. That's more for outbound calls (as in your CUBE sends an INVITE with SDP to your carrier) though, so unlikely to be related to your issue, but considered a best practice.

As b.winter mentioned, you should consider changing your configuration from CUCM to CUBE from H.323 to SIP all the way. From previous experience, mixing the two can lead to strange issues. Worth also mentioning that H.323 is on its way out:
https://www.cisco.com/c/en/us/products/collateral/unified-communications/unified-border-element/bulletin-c25-2479306.html

I would suggest you need a second link between your CUBE and Firewall to do the NATing for calls going out the second trunk (trunk B). Similar question to what was asked before, but how does the firewall distinguish what NAT address to use if you only have one interface connected from your CUBE?

Finally, the dial-peers look like they need a bit of work. Ideally you should have 2 incoming DPs, matching on the via header of SIP signaling endpoint. One DP for trunk A & one DP for trunk B and the appropriate SIP profiles applied in the inbound direction of these. If you're working with a consultant, they should be able to help you out with this. If the responsibility for this is on you, please do have a read of this doc as you should be trying to leverage the best of some of these techniques:

https://www.cisco.com/c/en/us/support/docs/voice/ip-telephony-voice-over-ip-voip/211306-In-Depth-Explanation-of-Cisco-IOS-and-IO.html