Something odd about our From SIP Header

[UrbanPeasant]

I'm struggling to understand why the From in our outbound INVITE to our primary ITSP is using the IP address of our secondary ITSP, instead of the IP address of our CUBEs sending interface.

INVITE from Jabber to CUBE is fine:

Received:
INVITE sip:807814965714@10.42.18.100:5060 SIP/2.0
Via: SIP/2.0/TCP 10.42.26.72:5060;branch=z9hG4bK2f511c5fc4e9e0
From: "Millward" <sip:95219@10.42.26.72>;tag=663381693~d9be8f2a-9162-4e70-9659-e288f460aedf-126230228
To: <sip:807814965714@10.42.18.100>
Date: Wed, 24 Nov 2021 22:22:20 GMT

But as the new INVITE leaves the CUBE the From should reflect the IP address 217.114.51.211 (as in the Contact), but instead now shows the address of the remote end point at our backup ITSP (which is also connected to this CUBE). The call works fine, but there's no profile that says to manipulate this setting.....I don't think.

Sent:
INVITE sip:07814965714@88.215.61.194:5060 SIP/2.0
Via: SIP/2.0/UDP 217.114.51.211:5060;branch=z9hG4bK8A59513CF
From: "Millward" <sip:01524595219@87.224.0.66>;tag=FB6C20AD-2476
To: <sip:07814965714@88.215.61.194>
Date: Wed, 24 Nov 2021 22:22:20 GMT
Call-ID: D3259F13-4CAB11EC-9F83AB7A-400B5FC8@217.114.51.211
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 4226366336-0000065536-0000005983-1209674250
User-Agent: Cisco-SIPGateway/IOS-17.3.3
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1637792540
Contact: <sip:01524595219@217.114.51.211:5060>
Call-Info: <sip:217.114.51.211:5060>;method="NOTIFY;Event=telephone-event;Duration=2000"
Expires: 180
Allow-Events: kpml, telephone-event
Max-Forwards: 27
Session-ID: 0000476600105000a0000021706a089a;remote=00000000000000000000000000000000
Session-Expires: 1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 253
v=0
o=CiscoSystemsSIP-GW-UserAgent 3481 2776 IN IP4 217.114.51.211
s=SIP Call
c=IN IP4 217.114.51.211
t=0 0
m=audio 42070 RTP/AVP 8 101
c=IN IP4 217.114.51.211
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

There is a profile that modifies From for the backup ITSP and it's applied to the dial-peer that sends calls to that ITSP. It's not applied to the dial-peer facing the primary ITSP used here for this call, and it results in different output anyway, see below. So I don't know what's happening to this call.

request INVITE sip-header From modify "<sip:(.*)@87.224.0.66>" "<sip:441524567980@spitfiretsp.net>"

Anyone got any thoughts on this, and what else I need to investigate/share? (It can be full config, just trying to keep the amount of info succinct at the moment.)

Thanks

Nathan.

[Roger Kallberg]

At a minimum please share your dial peer and any SIP profiles configuration that you have. A full debug ccsip message and ccapi inout of the call would also be of help.

[UrbanPeasant]

Hi Roger,

Thanks for posting back. In order to write something understandable I've slowed myself down and picked-over what's going on again.
From the CUBE perspective all incoming traffic from CUCM is picked up on Dpeer 190, and sent to the PSTN (primary ITSP) via Dpeer 11. The Dpeer 11 path fails, Dpeer 13 is backup. 
0 : 2065741 51434368ms.1 (10:01:12.980 GMT Fri Nov 26 2021) +8270 pid:190 Answer 95219 active
0 : 2065742 51434378ms.1 (10:01:12.990 GMT Fri Nov 26 2021) +8260 pid:11 Originate 07814965714 active

Those Dpeers and all their elements are attached in the doc. I can't spot anything anything wrong in them.

The other doc is the ccsip messages and ccapi inout data for the call noted at 10:01 above. The first mention of the wrong From IP address is at line 302, and working back from there my eyes don't see anything that invokes that change. The call went out on the correct peer, had audio, and terminated from the called device.

The end of the Dpeer-and-Profiles doc shows profiles config for other elements on the CUBE that aren't invoked by the Dpeers mentioned here.

Profiles 1 and 2 are required by our backup ITSP. Profile 2 is the only one that mentions From, and includes the incorrect IP address, but in a way that sees the IP address being removed, not inserted (I think!). The rest of the profiles are all to do with MS Phone System.

Having had another careful look over this lot this morning, I'm still non-the-wiser, and simply don't know what I'm missing.

Thanks for looking

Nathan

[UrbanPeasant]

I thought a ladder diagram would perhaps be useful in trying to understand where this is going odd (same call as above, but with fresh debugs attached - lots of ccapi errors because there's a call transfer that's stuck open and the call clear commands can't get rid of it - reboot later)
It all looks good from this view until you see the BYE when terminating the call from the remote device. This is sent to the wrong destination, a completely different provider, that sends back an OK for a call that wasn't initiated to them to the other interface on the CUBE, which then closes down the actual call. And it's because of the From header, which I still can't get to the bottom of.

The call is made from the SIP client connected to the subscriber at 10.42.26.72 and hits our CUBE internal interface

The call is routed to the PSTN via the CUBE's external interface facing the primary ITSP 88.215.61.194. In this new INVITE the From is using the wrong address, but the call establishes fine.
When the call is terminated by the cell phone, the BYE message appears to be sent from the primary ITSP to the secondary ITSP at 87.224.0.66. And is then seen on our CUBE's internal interface being sent outwards to the subscriber before the OK is received from the secondary ITSP for a call that isn't established to it. 

Lost. If you can help to set me straight I'd love to know what I've got wrong.
Nathan.

 

[UrbanPeasant · Accepted solution]

The 'problem' here turned out to be the following:
Previously we've had 4 ISRs connecting to 4 end points at 2 ITSPs. 
One of the ITSPs required almost no config on our part, and no registration - this was our primary and holder of our number ranges.
The backup ITSP was there for resilience, rarely used, and required registration and normalisation.

When I moved to the CSR I moved one end point from each ITSP onto each of our CSRs, so each of our gateways now had one ITSP that required registration (configured in the sip-ua) and one that didn't. The result of this was that all messages sent by us were using info from the sip-ua regardless of whether an outward facing dial peer was connecting to the backup ITSP or the primary. So all the From headers in the INVITE, RE-INVITE, ACK, PRACK, 200 were being influenced. The primary ITSP didn't actually care about those fields, and was handling the calls anyway. But it made things look really confusing when looking at logs.

In order to get rid of the confusion I had to create a new sip profile and apply it to the Dpeers sending traffic to the primary ITSP:

voice class sip-profiles 3
  request INVITE sip-header From modify "<sip:(.*)@87.224.0.66>" "<sip:\1@217.114.51.211>"
  request REINVITE sip-header From modify "<sip:(.*)@87.224.0.66>" "<sip:\1@217.114.51.211>"
  request PRACK sip-header From modify "<sip:(.*)@87.224.0.66>" "<sip:\1@217.114.51.211>"
  request ACK sip-header From modify "<sip:(.*)@87.224.0.66>" "<sip:\1@217.114.51.211>"
  response 200 sip-header To modify "<sip:(.*)@87.224.0.66>" "<sip:\1@217.114.51.211>"

dial-peer voice 11 voip
  voice-class sip profiles 3

I didn't figure this out on my own, didn't have the understanding. Though outside the strictest terms of our contract, our break-fix support partner helped me out. Many thanks to Luke at ITGL (UK).