[jim@itstod.se]

Hi,

I would like to see original caller ID on my mobile phone when call has been forwarded from pbx. This is also a very common request from our customers.

I am no expert in SIP but I suppose that support for "Call Diversion" might solve this? The two VoIP providers that we work with both say that we have to use Call Diversion to be able to keep the original caller ID when sending out a call to an external number.

Support for Call Diversion headers would also be useful for incoming calls from some SIP Trunk providers. For details on this, see this post: did-problem-9220.html

Thanks,

Jim

[jim@itstod.se]

Isn't anybody else interested in this ?

I think everybody expects to see caller ID on their phone (also if the call has been forwarded from pbx).

Made a quick search in the forum and found many posts about this topic that points out that Call Diversion may be the solution:

caller-from-id-on-divert-forward-4271.html
support-for-advanced-sip-features-4523.html
call-diversion-to-external-line-2807.html
caller-id-passthrough-on-forward-1381.html

Regards

[jungwirth]

This is not possible.
You can't call out with a number you don't own.

[zensoftware]

Hi Jim,

I dont think this is possible either as your mobile isnt making that leg of the call, 3CX is.

Regards,

Emmet.

[matictec]

This is not possible.
You can't call out with a number you don't own.

This is not correct...but this demands on configuration of your provider. I can set any german number as outgoing caller id, but not mobile numbers. this is limited by the provider. so it would be possible. and also if i use 3cx assistant to make a call...the outbound caller id is not the caller id i have set to the extension.

[jim@itstod.se]

Yes, I am sure that it's possible with ISDN and VoIP providers but of course the gateway or provider must support it. The two Swedish VoIP providers we resell (Tele2 and Telavox) both say they support it (and many of our competitors claim they provide this feature...).

Snom has a good explanation on this on their wiki: http://wiki.snom.com/Call_Diversion.

To me it's basic - you don't want to see the same number for all incoming calls on the cellphone, you want to see who's calling.

Regards

[o.mascia]

This is not possible.
You can't call out with a number you don't own.

This is NOT the request. And this is not how it works using ISDN lines.

Here's the typical schema.
One customer calls my office number. The call is directed to my extension. My extension rules say to "forward" the call to my portable telephone, I get the phone call and it is says my office is calling me, not the customer. This is the problem.

Choose and plug the most ugliest and cheap standalone ISDN PBX and it will support that correctly, actually requesting a Divert on the public network instead of setting up a distinct call and "forwarding" by itself. Actually you can even only have *one* ISDN line and *one* ISDN telephone and no PBX of any sort and this will work nicely over ISDN.

A calls Office.
Office sees the call should be "forwarded" to B.
Office sees the call can be diverted because the underlying ISDN allows for that.
Office triggers the ISDN Diversion.
A gets connected to B at the public exchange level, both channels of the ISDN line are free for other calls.
Of course B probably pays for a comm from Office to B.
But technically the call is connected from A to B and B sees A is calling (not Office).

Okay, these are street words for it, but at least it describes it correctly.
Devices like Patton ISDN gateways can handle ISDN diverts.
What's missing is glue code for getting 3cx to instruct the gateway to do the right thing, instead of having 3cx opens up a distinct outgoing call and connect both either at 3cx level or at the patton level. It has to happen at the public exchange level.

[archie]

Please, understand that we're trying to keep our code as generic as possible. And we do not produce ISDN PBX, we're making VoIP PBX which works with variety of VoIP devices including analogue PSTN gateways. I agree we need to extend support of ISDN devices, but it takes time. It is not just add another 10 - 100 lines of code. We need more or less standard way to query capabilities from devices. So far we do not have any. There's no way to know (programmatically) if PSTN device has Call Divertion functionality or not. Another complications is that PBX will need to decide if the call can be diverted, or it requires a routing by outbound rule. If you have more that one connection to PSTN and complex outbound rules - it might be really big problem for PBX to decide. And for you to properly configure this decision. And a number of angry customers who paid incredible sum, because their calls to local number has been (silently) diverted to international numbers and charged accordingly.

[matictec]

i think archie is right. but there could be another possibility. we use the voip provider sipgate. and here it is possible to set any german national number as outgoing caller id in the format 49 40 414 310 445 for example. i think to know that some isdn provider support this feature as well as sipgate. a limitation is that only national numbers are possible, but in most cases this would be enough. but the next cradle is to define the format of outgoing caller-id. the settings for the e.164 number-format get close to the necessary settings, but must be separated from them.

offtopic
there is also a "bug" in "make call" calls i do over the 3cx assistant. if i define an outgoing number for an extension and i do a call with 3cx assistant, my outgoing number is not this one from my settings for outgoing caller id.

[zensoftware]

I also have to back Archie on this.

There are many, many things that both I and the other people in the Partner Channel would like to see before this. I dont think it's anywhere like as simple as saying all thats missing is the "glue code" when any code must be device specific. The knock on effect would be huge, we can't expect Archie and the other guys on the dev team to code every feature on every gateway.

It's also surely not their job to code for ISDN specfic features. Lets not forget 3CX is s SIP based system, what Archie and the guys need from us is some consensus on what we want going forward and how we can help them make a stronger product. Really we should restrict comments to SIP based features such as the addition of a call diversion header, which is the point Jim was making in the first place.

It has to happen at the public exchange level.

[/quote]

I'm also not sure what you expect Archie to do about something that is supposed to take place at the exchange level? Or am I getting that wrong?

Emmet.

[o.mascia]

Please, understand that we're trying to keep our code as generic as possible. And we do not produce ISDN PBX, we're making VoIP PBX which works with variety of VoIP devices including analogue PSTN gateways. I agree we need to extend support of ISDN devices, but it takes time. It is not just add another 10 - 100 lines of code. We need more or less standard way to query capabilities from devices. So far we do not have any. There's no way to know (programmatically) if PSTN device has Call Divertion functionality or not. Another complications is that PBX will need to decide if the call can be diverted, or it requires a routing by outbound rule. If you have more that one connection to PSTN and complex outbound rules - it might be really big problem for PBX to decide. And for you to properly configure this decision. And a number of angry customers who paid incredible sum, because their calls to local number has been (silently) diverted to international numbers and charged accordingly.

Archie, to clear out any possible misunderstanding, I am *NOT* complaining or asking for an urgent solution. I tried to make the problem as clear as possible for users who don't seem to get the idea of what this is all about and who by their posts might then give a false sense to the request. Sure, comparison with dumb isdn pbx which is not fair outside of context might have been rude to read.

I really understand 3CX is a voip PBX, which also works with various pstn and isdn gateways.

To overcome the difficulties to know if the device has Call Diversion or not, I would suggest to clearly offer "Divert to" in addition to "Forward to" in extensions rules. That would be sufficient for me. If the outbound rules then target this or that device and that device is ISDN based, ask it to Divert since this is what was asked by the user in his/her settings (if that fail or if the device is not ISDN move on next possible route). Maybe a technician configurable flag in the device configuration (3cx side) could tell wether the device has call diversion or not enabled.

Just a rough suggestion, I know.

[o.mascia]

It has to happen at the public exchange level.

I'm also not sure what you expect Archie to do about something that is supposed to take place at the exchange level? Or am I getting that wrong?
Emmet.[/quote]
You're getting it wrong indeed.
Let me rewrite it again slightly simpler than in my earlier post.

'A' calls 'B'.
'B' gets the call signal, and decides it has to (and can) be diverted to 'C'.
'B' asks for Diversion on the network (public exchange).
'A' is connected straight to 'C' (it happens at the public exchange level).
No line (or isdn channel) is consumed at 'B' once the divert has been setup (else it would cost 2 channels, one IN and one OUT, here none other calls can take place).
On a billing side, the isdn network operator will probably charge 'B' for a pseudo connection from 'B' to 'C' for the duration of the call from 'A' to 'C'.

I hope the concept is clearer. This is no rocket science when you have only isdn. Yet I understand it might be complex to offer these isdn specific capabilities in a generic voip product as 3cx. I wouldn't be paying for 3cx if i didn't appreciate it by some other angles. This is a dark area where I'd love improvement, when it'll come.

[jim@itstod.se]

Thanks everybody for commenting on this.

Just a question to you resellers out there - do your clients (and prospects) accept not seeing who is calling? Ours certainly do not and this is the biggest problem that prevents us to sell more systems at the moment.

There's no way to know (programmatically) if PSTN device has Call Divertion functionality or not.

I would suggest you make this an option on the VoIP Provider/PSTN Device - "Supports Call Diversion on/off". Then it's up to the administrator of the system to choose.

Another complications is that PBX will need to decide if the call can be diverted, or it requires a routing by outbound rule.

Also this would be great for the administrator to be able to choose. If you use ISDN lines, you probably want to use the same line as the call came in through to make this available for new calls but if you use VoIP providers you may want to send the call out another way (since you don't have any limitation on concurrent calls).

Thanks,

[garethb_83]

Are there any sip providers which allow you to send the callering partys cli when diverting via sip provider? Is this rpid?

Any help would be great as this is a must for my client they must see the incoming cli 3cx gets when the call is diverted by 3cx. They used feature line from bt previoulsy and now have delved into voip and like. This so far seems to be the only hurdle.

They don't mind signing a disclaimer but need to know if any voip provider offers this facility.

[jim@itstod.se]

Are there any sip providers which allow you to send the callering partys cli when diverting via sip provider?

I know that Tele2 supports this and I've read that CBeyond supports it too if you use Diversion header.