Failover trunk skips


I have configured my outbound routes to failover to an alternative trunk. However the behaviour is odd and I’m trying to find a way of tracing the cause.

I have two Sipgate accounts and a PSTN line attached.
I set an unconditional forward on the destination to an external number. When an inbound call over Sipgate line#1 is routed to the extension to be forwarded, the extension successfully applies the forward.
However on the outbound route selection, the profile uses Sipgate line#1 first, then failover to Sipgate line#2, the failover to PSTN. Each of the Sipgate lines are set to a max concurrent calls of 8. According to the CDR, the outbound call is rejected by both of the Sipgate lines and defaults to PSTN.
Any idea how I can track the reasons for the apparent rejections?


were you able to address the problem?


Sadly, not yet been able to.
I did test to force an incoming sipgate call to be only diverted to a sipgate line, but this still rejected. Not sure whether the trace would give indication of why.


Is there a UCM in the setup?


Yes, it’s a UCM6102 running firmware


A network trace would should the error code associated with the rejection.

It could be the outbound number format is incorrect and the route does not it for SIP but the PSTN is agnostic as it takes any any all.

It could be that a diversion is not an acceptable method by SIpgate and there are other reasons.

Do a network capture, it certainly will not hurt,.


The trace showed a 403 Forbidden response from the server. It looks as if the CallerID preserved from the incoming call, causes the INVITE to fail because this is seen as the user identity. By removing this, the forwards worked as expected. However, the CallerID presented is the trunk ID, not the incoming CID, which doesn’t give me warning who is calling.
I presume making adjustments to the header might help, but this is now getting beyond my competence.
Could anyone please give me a steer in the right direction?


So it sounds like SIPgate won’t allow the call out without the correct CID on it of your facility.
I’d start by asking them if they can alter that setting.


The failover is dependent upon the response as some are consider a “final” response. The failover is generally assumed to be a condition that comes into play when a correctly configured trunk fails to respond. In your case, the trunk is not correctly configured and the response essentially told the UCM to quit trying.