Call Deflection (302)

[GaSo]

Hi All,

We're trying to let 3cx use 302 call deflection (using extention status "away"), so that an incoming call is redirected to a mobile number, without the call still going trough the 3cx PBX.
However what we see and in our PCAP files is that 3cx always creates a new call, instead of sending the SIP 302. The provider PCAP never receives a 302.
The original caller's number is shown correctly and all is working as expected, except that the call stays going trough the PBX and the new call is being billed by the trunk provider.

Is any one else getting it to work in the latest 3CX version with full SIP 302 redirection? or is it truly limited to creating a new call all the time?
Or any suggestions on how to get this to work?

Thanks in advance!

 

[Evolute IT]

Hi All,

We're trying to let 3cx use 302 call deflection (using extention status "away"), so that an incoming call is redirected to a mobile number, without the call still going trough the 3cx PBX.
However what we see and in our PCAP files is that 3cx always creates a new call, instead of sending the SIP 302. The provider PCAP never receives a 302.
The original caller's number is shown correctly and all is working as expected, except that the call stays going trough the PBX and the new call is being billed by the trunk provider.

Is any one else getting it to work in the latest 3CX version with full SIP 302 redirection? or is it truly limited to creating a new call all the time?
Or any suggestions on how to get this to work?

Thanks in advance!

We use it and it works perfectly.

Does your provider supports it?

 

[GaSo]

Thanks for your reply Frederick.
They do, but they don't receive the 302 redirection SIP request. Only the source number is reused by 3CX ("Clip No Screening Support "is also supported by the provider). It gives the right result for the end user, except that it still goes trough the PBX and billed as a new call.

Could you verify on your end that when you make a redirected call that it truly dissapears while calling from the 3cx active calls page at #/app/system_status/active_calls as here it makes a second line and never verified in the backend with the provider when capturing the SIP pcap if it supports or trying 302. I read all other topics on this forum mentioning the deflection and all seem to refer to that it opens a second line.

 

[AWS2P]

@GaSo , I think you are right on target, It seems to me this is the way to do a 302 redirection with 3CX.

 

[GaSo]

@aws2p, thanks. But I hope that 302 on SIP level is truly supported as it suggest, but does not do, because a second line keeps charging the customers.

We have customers that forward their calls to their mobile phone, costing them a lot. A redirect would save a lot of money.

 

[AWS2P]

We have customers that forward their calls to their mobile phone, costing them a lot. A redirect would save a lot of money.

and use some trunk channel and licence seat too

 

[ivan.antic]

GaSo,

Here, 3CX Server had to answer the channel first, and figures out that the extension is in "away" status. 3CX Server then simply makes an outbound call.

From provider's perspective it's an outbound call with PAI and/or PPI inserted, that's why you see originator caller-id number.

3CX Server in your case works fine, it's not Session Border Controller (*Not to confuse it with 3cx sbc).

As soon as external call lends to your 3CX Server where the DID is configured that's it.

The only party which can do true re-direct, or Diversion 302, is the one how owns the number. And in your case it's provider.

 

[GaSo]

@ivan.antic thank you for your reply.
Do I understand you correctly that in this case it will always be routed still trough the 3CX PBX with a second call?

Or can the 3CX still somehow communicate with the provider to share the 302 wish (not the number, but truly rerouting the call) trough its sip messages / headers?

 

[ivan.antic]

GaSo,

Yes, as soon as external call kicks in at 3CX, the call is yours.

There's no way in 3CX to bounce back an external call on DID trunk level with "Diversion" header 302 back to provider.

It would take the 3CX Server to handle external call in such a way, not to route the call downstream in any kind of a way but to immediately reply with 302 back to provider's INVITE.

But then again in your case the call was actually forwarded to outside number, mobile operator, and has nothing to do to with one which was originally dialed by external caller.

It's impossible

 

[GaSo]

@ivan.antic thank you, that's what we feared... it's confusing as they give it the 302 description and list it on their supported trunk page separately from the "no clip screening support" as "302 Diversion Support" as if the provider can handle 302 redirect.

 

[JohnS_3CX]

If you do not see 3CX sending a 302 then it is probably not configured in such a way that 302 is triggered.

A typical scenario would be to set DID in inbound rules to route a call directly to an extension (no IVRs or anything in the middle as this would not qualify for 302 since the call is already answered) and then that extension being set to Away with 302 Deflection enabled.

 

[ivan.antic]

"Use call Deflection (302)" as suggested by JohnS_3CX is at extension level
3CX has to make an outbound call anyways. So it will stay in path.

Use Call Deflection (302) is simply unconditional forwarding on 3CX Server (extension level). So you don't have to do it on deskphone itself.

 

[GaSo]

Yes, we really hoped for 302 on provider level. I.e. when away directly to mobile phone without still routed trough the PBX. But it's good to know, that we don't have to keep searching.

 

[leejor]

Having a provider do the Call Deflection, is not a small ask. They would have to make use of a second, outgoing channel, of theirs, to complete the call. So while you would save, not having to use any channels, for that forwarded call, they would not. If they are billing you by the minute/second used, then they are probably going to want to pass that cost on to you. There is also the matter of billing for any forwarded calls not included in your "normal" dialling plan... international, and the like. Because the call did not pass through 3CX, you'd have to track down (or there would have to be an option to record the call) the person that set-up the forward, if the call were allowed to complete.