Cause = 41 Network error, but who's network?

[lowfell]

I'm trying to troubleshoot Failed calls to certian mobile numbers over sip and from the cube debugs I see 

Q850 #Cause = 41

According to Cisco it says " 

Temporary failure. The call was disconnected due to a network failure. This code appears for some long distance providers if the hunt sequence is incorrect. PRI lines must be set up for a flex hunt sequence (not a float hunt sequence).
Who's network though? This is a Remote site with CUCM at main sites and Cubes connecting to the SIP network, so when it says Cause 41, which part of the network are we talking about here?

[Sadav Ansari]

Check you local connectivity between cm and gateway and check ISDN layer status.

[Nithin Eluvathingal]

is there a firewall between the remote site CUCM and the gateway ?  if yes check from firewall if  it dropping.

[lowfell]

The CM is at a central site along with the CUBES. The issue originates FROM a remote site coming over some type of ipvpn or MIA type of thing, I'm not sure if there is a firewall inbetween, though there might be! is this what you think?

[Nithin Eluvathingal]

I have faced many issues when there is a firewall between CUCM and gateway/Phones. if you take traces from both  CUCM and Gateway you can narrow down the problem. 

[lowfell]

I've asked my customer to confirm the setup, i'll wait to see what they say. Thanks for your help, i'll keep you posted.

[lowfell · Accepted solution]

Here is my CUCM trace, to me this doesn't look like the CAncel is coming from CUCM, can someone confirm this?

2021/04/24 14:55:31.694|CC|SETUP|56603423|56603424|XXXXX@XXXXX|+447XXXX64418|+447XXX264418|1630298200105000a00000562b62ecf5|*
2021/04/24 14:55:31.701|SIPT|56603424|TCP|OUT|10.6.211.5|5060|CUBE-SIP-Trunk1|10.6.211.20|5060|3,100,251,1.54510165^*^*|1585614838|ba559100-1ec1c307-2ce63ff-5d3060a@10.6.211.5^1630298200105000a00000562b62ecf5^*|INVITE
2021/04/24 14:55:31.701|CC|OFFERED|56603423|56603424|+44167050XXX5|+447982XXX18|+447982264418|SEP00562B62ECF5|CUBE-SIP-Trunk1|1630298200105000a00000562b62ecf5|*
2021/04/24 14:55:31.715|SIPT|56603424|TCP|IN|10.6.211.5|5060|CUBE-SIP-Trunk1|10.6.211.20|5060|3,100,251,1655076.215076^10.6.211.20^*|1585614843|ba559100-1ec1c307-2ce63ff-5d3060a@10.6.211.5^00000000000000000000000000000000^*|100 Trying
2021/04/24 14:55:31.751|SIPT|56603422|TCP|IN|10.6.211.5|5060|CUBE-SIP-Trunk1|10.6.211.20|5060|3,100,251,1655076.215077^10.6.211.20^*|1585614844|ba559100-1ec1c307-2ce63ed-5d3060a@10.6.211.5^69d0d19fffd45a04997649ee00c06923^0645d1b7037f5f3691a44dac10f8f06c|183 Session Progress
2021/04/24 14:55:31.760|SIPT|56603422|TCP|OUT|10.6.211.5|5060|CUBE-SIP-Trunk1|10.6.211.20|5060|3,100,251,1655076.215077^10.6.211.20^*|1585614845|ba559100-1ec1c307-2ce63ed-5d3060a@10.6.211.5^*^*|PRACK
2021/04/24 14:55:31.762|SIPT|56603422|TCP|OUT|10.6.211.5|5060|CUBE-SIP-Trunk1|10.6.211.20|5060|3,100,251,1655076.215077^10.6.211.20^*|1585614846|ba559100-1ec1c307-2ce63ed-5d3060a@10.6.211.5^*^*|SUBSCRIBE
2021/04/24 14:55:31.764|SIPT|56603421|TCP|OUT|10.6.211.5|5060|CUBE-SIP-Trunk1|10.6.211.20|55897|3,100,251,1655076.215077^10.6.211.20^*|1585614851|918041AA-A43B11EB-99B0DB29-8C017ACA@10.6.211.20^*^*|183 Session Progress
2021/04/24 14:55:31.766|SIPT|56603421|TCP|OUT|10.6.211.5|5060|CUBE-SIP-Trunk1|10.6.211.20|5060|3,100,251,1655076.215077^10.6.211.20^*|1585614853|918041AA-A43B11EB-99B0DB29-8C017ACA@10.6.211.20^*^*|SUBSCRIBE
2021/04/24 14:55:31.769|SIPT|56603422|TCP|IN|10.6.211.5|5060|CUBE-SIP-Trunk1|10.6.211.20|5060|3,100,251,1655076.215078^10.6.211.20^*|1585614855|ba559100-1ec1c307-2ce63ed-5d3060a@10.6.211.5^69d0d19fffd45a04997649ee00c06923^0645d1b7037f5f3691a44dac10f8f06c|200 OK
2021/04/24 14:55:31.775|SIPT|56603421|TCP|IN|10.6.211.5|5060|CUBE-SIP-Trunk1|10.6.211.20|55897|3,100,251,1659858.59592^10.6.211.20^*|1585614856|918041AA-A43B11EB-99B0DB29-8C017ACA@10.6.211.20^0645d1b7037f5f3691a44dac10f8f06c^fd19f3d6f13a593a8e5ea67e21bc62e1|PRACK
2021/04/24 14:55:31.775|SIPT|56603421|TCP|OUT|10.6.211.5|5060|CUBE-SIP-Trunk1|10.6.211.20|55897|3,100,251,1659858.59592^10.6.211.20^*|1585614857|918041AA-A43B11EB-99B0DB29-8C017ACA@10.6.211.20^*^*|200 OK
2021/04/24 14:55:31.776|SIPT|56603422|TCP|IN|10.6.211.5|5060|CUBE-SIP-Trunk1|10.6.211.20|5060|3,100,251,1655076.215079^10.6.211.20^*|1585614858|ba559100-1ec1c307-2ce63ed-5d3060a@10.6.211.5^*^*|200 OK
2021/04/24 14:55:31.776|SIPT|56603422|TCP|IN|10.6.211.5|5060|CUBE-SIP-Trunk1|10.6.211.20|55897|3,100,251,1659858.59593^10.6.211.20^*|1585614859|ba559100-1ec1c307-2ce63ed-5d3060a@10.6.211.5^*^*|NOTIFY
2021/04/24 14:55:31.776|SIPT|56603422|TCP|OUT|10.6.211.5|5060|CUBE-SIP-Trunk1|10.6.211.20|55897|3,100,251,1659858.59593^10.6.211.20^*|1585614860|ba559100-1ec1c307-2ce63ed-5d3060a@10.6.211.5^*^*|200 OK
2021/04/24 14:55:31.779|SIPT|56603421|TCP|IN|10.6.211.5|5060|CUBE-SIP-Trunk1|10.6.211.20|5060|3,100,251,1655076.215080^10.6.211.20^*|1585614862|918041AA-A43B11EB-99B0DB29-8C017ACA@10.6.211.20^*^*|200 OK
2021/04/24 14:55:31.779|SIPT|56603421|TCP|IN|10.6.211.5|5060|CUBE-SIP-Trunk1|10.6.211.20|55897|3,100,251,1659858.59594^10.6.211.20^*|1585614863|918041AA-A43B11EB-99B0DB29-8C017ACA@10.6.211.20^*^*|NOTIFY
2021/04/24 14:55:31.780|SIPT|56603421|TCP|OUT|10.6.211.5|5060|CUBE-SIP-Trunk1|10.6.211.20|55897|3,100,251,1659858.59594^10.6.211.20^*|1585614864|918041AA-A43B11EB-99B0DB29-8C017ACA@10.6.211.20^*^*|200 OK

[lowfell]

In the end, all we did was rest the phones from CUCM & they then started working correctly. Remembe this was a change from an IPVPN wan to SD-Wan, so ultimately everything needed rebooting to make it work.

Thanks everyone for your help.