There are some important things to understand about forwarding and transferring calls in a system, like sipXecs, that is based on a SIP proxy:

Forwarding and Transferring are different operations in SIP; they don't work the same way, so be careful which term you use to describe what you're doing.

Forwarding is what happens before a call has been answered by any phone or any service in the PBX. Essentially, when a call comes into sipXecs, the system determines a sequence of targets for the call. Typically this sequence starts with any phones registered to the number, and continues through the forwarding destinations either "at the same time" or "if no answer" until something answers the call. In systems that use voicemail, it is configured as the target of last resort (it would be pointless to make any other target a lower priority, since voicemail should always answer).

Transferring is what happens when a call has been answered, but now one party on the call wants to send the call to some other destination. This can be done in one of two ways:
- Blind Transfer sends a signal to the party to be transferred that says, in effect, "Please try to call this other destination and successful connect to them and disconnect from me".
- Consultative Transfer (sometimes called Attended Transfer) in which the party doing the transfer (called the Transfer Controller) calls the target, establishing a new call; the controller now has separate calls with each of two parties: the transferee and the transfer target. The controller then sends one or the other a SIP signal that says, in effect, "Here is the information about another active call: please contact the other party on that call and connect to it and disconnect from me".

It doesn't matter whether the call is answered by a person or by a service. If, for example, the caller reaches an auto-attendant or voicemail system and presses some DTMF keys to be sent to somewhere else - the call was answered by the service, so what is happening is a transfer. There are cases where this is difficult to determine by just listening to what's happening on the phone - sometimes you have to look at the SIP signalling to see what is really happening.

In theory, any endpoint in a SIP system can do forwarding: a phone or gateway or service can respond to a call request with a signal called a redirect response that means "Please try this call at this other address I am giving you". Most SIP phones can be configured to do this in the phone - return a redirect to some other destination after some number of rings or seconds, or if the call is busy, or if the user has set some "do not disturb" mode. Unfortunately, the security provided by the protocol for these redirect responses is not very good, so they represent a potential source of security problems. Essentially, the sipXecs system cannot "trust" that the response has really be authorized by the user, and so it cannot use the permissions assigned to that user to make the requested call to the forwarding destination, and so the call may fail. To avoid this problem, do not use forwarding features in phones or other SIP endpoints; instead, use the forwarding and dial plan features of sipXecs to control the call sequences.

Forwarding to external destination fails

I included an external number in my forwarding, but the call skips that number and goes to voicemail

Make sure you're not using forwarding on the phone - only forwarding from within sipXecs can make an external call.

If you can call a number from your SIP phone, you should be able to forward or transfer to it, so make sure that you can make the call from your phone, and that you enter the forwarding number in exactly the same way in the forwarding target box.

See How to configure User Call Forwarding

Forwarding to a sequence stops at an external destination

I included an external number in my forwarding and told it to ring for 30 seconds, and then I want it to fall back to my sipXecs voicemail, but it rings for 3 minutes on the external number and never goes to voicemail

There are two ways this can happen: either your PSTN gateway is actually answering the call (usually the case if you are using an old-fashioned analog circuit), or the PSTN is returning an in-progress indication that prevents the fallback...

There are two ways for a gateway to indicate that a PSTN call is 'ringing': it can send a '180' response, which normally has no SDP, or it can send a '183' response with SDP to establish an 'early dialog' and then forward audio from the PSTN to the caller (essentially, play the audio ringing or busy or whatever and let the human interpret it). For most purposes these two are interchangeable, but there is one important difference:

Some telephony services use an ISDN signalling 'trick' to put the caller into an IVR before actually doing the final call setup. Prompts are played to the user, and DTMF is sent to the service, but no actual call has been created yet. Since no call has been created on the ISDN side, the gateway does not send a 200 Ok - it sends 183 and uses the early dialog on the SIP side.

In order to interwork with such systems, the proxy has been modified to treat a 183 with SDP as essentially equivalent to a 200 Ok for the purposes of expiring a fork. If it did not do this, then some telephony services (past examples have included American Airlines reservations and the United States IRS taxpayer information hotline) are not usable because after 30 seconds the proxy cancels the early dialog.

The gateway should be set to interpret the PSTN side signalling and send 180 ringing rather than 183 Session Progress if possible. This probably involves getting the localized settings correct for the PSTN network it is connected to.

Browser not supported