Expressway - SIP Header manipulation

[Bill]

I am trying to change a SIP header on an Expressway.

We are sending audio out an Expressway C/E pair to a phone carrier.
(this method was chosen since they already have Expressways but no Cube routers).

The carrier is seeing something they don’t like. But I don’t now how to fix it.

In the SIP Invite to the carrier, we are sending the IP Address of the Expressway-C in the Request-URI and the TO: field.
They expect to see their IP Address instead.

It looks like this:
INVITE sip:5551212@10.200.202.219:5060 SIP/2.0
To: sip:5551212@10.200.202.219

They want to see this: (public IP’s masked)
INVITE sip:5551212@2.2.171.56:5061 SIP/2.0
To: sip:5551212@2.2.171.56

10.200.202.219 is the Exp-C
2.2.171.56 is the Carrier

I have attached the complete Invite message.

Using a Transform, I am able to modify the Request-URI.
But not the TO: field.

But it gets complicated, because the carrier has two SBC's for redundancy.
My Transform only accounts for one of the Carrier's IP Addresses.

Thinking this through, I almost think I'd need two SIP Trunks from CUCM to the Expressways to account for each carrier IP.
Hoping there is a way to have the Expressway-E set the Header they way the carrier's want it.

Thanks

[Jonathan Schulenberg]

Did you misspeak above or is Exp-C really configured with a Neighbor zone toward the PSTN provider directly? I’d expect that to be happening Exp-E since -C is supposed to be behind the firewall/NAT.

Also, this seems like an incredibly expensive design since each call will need an RMS license. Exp-C to CUBE to the provider would seem far cheaper.

[Bill]

If I said that, that is not correct.
We do NOT have a neighbor zone on the C towards the carrier.
There is a neighbor zone on the E towards the carrier.
But we are sending the IP of the C in the invite.

RMS License is not an issue.
This is not a primary call path and will be used very little.