External calls receveived on a mobile and forwarded automatically to 3CX are not processed

[it-department@sogimsyndic]

Hi everyone,

We discovered a strange behavior when a call is coming in from a mobile (classic mobile phone) that has received his call from another phone or mobile and has diverted it to a number on our sip trunk (automatic forwarding setup on the mobile phone trough network instructions as **61* (forwarding incoming calls when no answer) or **21* (unconditional forwarding all incoming calls).

Details (all numbers are fake) :
Land line or mobile : +3299121212
Mobile number : +32478232323
3CX line on sip trunk sip : +3299454545 with call flow (calls are received by voice mail message with recording).
Main trunk number : +3299787878

On the mobile there is a call diversion : all incoming calls on +32478232323 are forwarded to +3299454545.

Normally, the incoming calls on the mobile would be forwarded to the call flow behind +3299454545.

This is even not the case. The call comes in but the 3CX log shows that de DID number is wrong. Instead of the DID number +3299454545 the mobile number +32478232323 is registered. The call never reach the call flow and is turning around while the DID number is the same as the mobile number.

When a call is made directly to +3299454545 all is working perfectly. The call can be made by classic landline or by any mobile number, the call is reaching the call flow and the caller can let un message on the voice mail.

Example log 1 – call coming in directly:
Incoming call – call is made by +32478232323 to reach +3299454545 (with the call flow).
This is working perfectly.

Log :
2020/12/25 15:26:39.532|1011|0019|Verb|CHR: Adding event: 2020-12-25 15:26:18.025|
IncomingCall|000001769A4B0B25_225|ca048f225d28/Participant DN.10000/Line dn-name='+32478232323:SOSY_EMERGENCY'

epname='0032478232323@(Ln.10000@SOSY_OVH)'
>ca048f225d28/Participant DN.10000/Line dn-name='+32478232323:SOSY_EMERGENCY' epname='0032478232323@(Ln.10000@SOSY_OVH)'

did_number=003299454545
disp_name=+32478232323:SOSY_EMERGENCY
number=0032478232323
sip.contact=<sip:91.XXX.XXX.23:5060>
sip.from="+32478232323" <sip:[email protected];user=phone>;tag=03572-OC-5b6d9b9f-32c413580
sip.rl_uri=sip:[email protected]:5060;transport=udp;rinstance=ed3b3271874b54b1 (with XX = static IP of 3CX)
sip.src_addr=91.XXX.XXX.23:5060
sip.to=<sip:[email protected];user=phone>
sip.user_ag=Cirpack/v4.76 (gw_sip)
target=sosy_urg_20201102.Main

2020/12/25 15:26:39.532|1011|0019|Verb|CHR: Adding event: 2020-12-25 15:26:18.025|TargetAdded|000001769A4B0B25_225|f332422cd322/Target DN.sosy_urg_20201102.Main/ServiceCall dn-name='' epname='Ext.sosy_urg_20201102.Main'
>f332422cd322/Target DN.sosy_urg_20201102.Main/ServiceCall dn-name='' epname='Ext.sosy_urg_20201102.Main'
ep.dialing=
ep.originator.caller_num=
ep.originator.dial=
orig.dest=sosy_urg_20201102.Main
orig.party.id=ca048f225d28

Example log 2
Call from +3299121212 to +32478232323 (mobile) and than forwarded to 3CX +3299454545 with call flow.
This is not working :

Log :
2020/12/26 09:27:56.144|1011|0019|Verb|CHR: Adding event: 2020-12-26 09:27:56.123|

IncomingCall|000001769E294F52_229|9f09550e4b12/Participant DN.10000/Line dn-name='+3299121212' epname='003299121212@(Ln.10000@SOSY_OVH)'
>9f09550e4b12/Participant DN.10000/Line dn-name='+3299121212'

epname='003299121212@(Ln.10000@SOSY_OVH)'

did_number=0032478232323 --> we think this is wrong value, should be 003299454545
disp_name=+3299121212
number=003299121212
sip.contact=<sip:91.XXX.XXX.23:5060>
sip.from="+3299121212" <sip:[email protected];user=phone>;tag=32556-SR-5c6fe417-293d37206
sip.rl_uri=sip:[email protected]:5060;transport=udp;rinstance=ed3b3271874b54b1
sip.src_addr=91.XXX.XXX.23:5060
sip.to=<sip:[email protected];user=phone>
sip.user_ag=Cirpack/v4.76 (gw_sip)
target=

2020/12/26 09:27:56.144|1011|0019|Verb|CHR: Adding event: 2020-12-26 09:27:56.124|TargetFailed|000001769E294F52_229|2776d039f946/Target [TargetNotFound]
>2776d039f946/Target [TargetNotFound]

In the first log the incoming call is received by the call flow (target=sosy_urg_20201102.Main). But in the second log target=___ (empty)

We have made test with several mobiles on different mobile networks (different operators) and behavior is the same in all cases. All direct incoming calls are correctly processed, all diverted calls coming from the mobile are not processed.

We have searched on the 3CX forum but without success.

Please, if some one recognize this, thanks in advance for help.

 

[it-department@sogimsyndic]

Additional info : we use 3CX Enterprise Annual v.16.0.7.1078 installed on a OVH server

 

[Evolute IT]

If you are using the phone dialcodes to set forwarding, that's why it's not working properly.

Use statuses. Never use the phone built-in call forward.

 

[it-department@sogimsyndic]

Thanks Frederick for your reply.
The forwarding codes we use are sent (once) to mobile network with the mobile phone which line number will forward the calls (the so called "MMI" codes). So the forwarding code is received by the mobile network operator (example in Europe : MMI code = **21*+3299121212# means that all incoming calls on the mobile will be forwarded unconditionally to +2199121212).

 

[leejor]

Your (3CX) provider is going to pass on whatever DID number they are "given". And, 3CX (DID rules) can only work with what is sent. If it is incorrect because the original caller has been forwarded, then there may not be anything you can do to change this. You'd have to speak to your provider about this scenario. I doubt that the mobile provider, doing the forwarding, is going to be that interested in helping.

Have you tried adding a DID rule to deal with the actual DID number being sent?

 

[it-department@sogimsyndic]

Some feedback

It is not possible to register the "TO" number as a DID number in inbound rules. We have tried to set a CID rule on inbound call matching the "wrong" TO number received during SIP negociation. But the rule doesn't work (but we must analyze the Wireshark dumps to understand why the CID rule doesn't work).

At another level, we have studied the SIP protocols for forwarding calls and we think that our mobile provider (who the diverted call is coming from) doesn't respect SIP regulations. Normally, they must replace the initial callee number with de last callee number (the number were the call is diverted to) so the number will match with our incoming DID rule on 3CX.

We have found information about SIP regulations RFC 3261 and 5806 for forwarding and diversion calls. Our mobile provider is claiming that these rules are respected on their network. So we have sent an official demand to fix our problem.

Wait and see.

 

[cobaltit]

You are saying your mobile provider isn't respecting SIP regulations but I'm not sure why you think they would have to. If the forwarding is happening on the mobile network (which it sounds like it is) then I assume they are doing as they should be and being that it is the mobile network SIP regulations would not apply.. What you haven't mentioned is if your SIP provider is a 3CX supported provider. This may be playing a factor in why things are not working as they should. You may also want to look at a capture of your incoming SIP traffic as you may need to adjust where 3CX is looking for the the CID. You may find what you are looking for in one of the other fields. Or maybe it's just as simple as setting the default trunk route to your call flow destination. If all other inbound calls are matching rules then this might do the trick.

 

[leejor]

Normally, they must replace the initial callee number with de last callee number (the number were the call is diverted to) so the number will match with our incoming DID rule on 3CX.

Don't confuse Caller ID rules and DID rules.

The mobile provider is probably not concerned at all about any DID numbers, nor, I'm sure, do they feel obligated to pass them on. What you seem to be describing is how you want Caller ID to work, where the originators number (CID) is replaced with the number of the subscriber doing the forwarding so that you can use the CID information to direct the call. Most of the time, it is the originators number that is passed on to the final destination , that is what most people are concerned about , ignoring the fact that the call is forwarded.

If you forward your home phone to your mobile, would you not want the callers number to show and not your home number?

 

[it-department@sogimsyndic]

Thanks Cobaltit for reply and suggestions.
The mobile operator undertakes to comply with SIP regulations in accordance with the obligations towards the supervisory authorities. We have checkes this. As the diversion call is coming from the mobile network, they must respect certain SIP procedures. We believe they are not.
Our SIP provider is supported by 3CX (OVH).
Regarding the capture of incoming calls, see first post. During the diversion, the mobile provider returns the called number of the first segment and not of the second segment with the diversion number. Without the diversion number (final destination on our PBX with known DID number) the call can not be directed by 3CX so the call is catched by our main SIP trunk number.
We have not yet analyzed the captures with CID inbound rule but as indicated above, the inbound route with CID does not give any results (not yet, some tests must be done).
Adding an inbound route with the default trunk route redirected to the call flow could be a solution, certainly to try. But we believe that the mobile provider should communicate the correct DID number (final destination after diversion) which would be more comfortable and simpler.

 

[it-department@sogimsyndic]

Thanks to Leejor for reply and suggestions.

It's normal for the mobile operator to follow SIP procedures and to transmit the number called by the originator of the call or the number called for de diversion. This number (DID) will (must) be showed in the TO field.

We know difference between caller ID rules and DID. We just tried to use a CID rule based on the called number of the first segment (before diversion) as a work around to solve the problem.

The transmission of the origin number (the caller) is correct and must remain so. That's not the point in our problem.
The problem does not arise for the callers number, it is the one displayed (see SIP capture first post, FROM field). That's ok. It may be useful to remember that the problem only arises when a call received on our mobile is diverted to our PBX, to one of our DID numbers with call flow. When the call is coming in directly on our DID (without diversion), there is of course no problem, the call is correctly routed because the right DID number is set in the TO field.

May be we can give some more information about our goal. Our application actually concerns incoming "emergency" calls which arrive on a mobile number (this number is used for years now and we want to maintain this number for our customers). In the future, we want to divert all incoming calls on this mobile 24 hours a day 7/7 to our PBX which takes care of the call via a call flow with voice mail and forwarding the voice message attached to an e-mail to an "emergency" e-mail address. Thus, the person on duty can easily manage the incoming calls in the form of incoming e-mails (with attached voice mail messages). In addition, the incoming e-mail (with the voice mail attached) can easily be forwarded to our ticketing system for follow-up the next business day.

We have sent a request for information and of course a solution to our mobile operator. We hope that they will give a quick response.

 

[cobaltit]

Do you have a log with the full SIP readers? Something like this?

01/03/2021 2:58:02 PM - [CM500002]: Call(C:524): Info on incoming INVITE from Line:10002<<+13299121212:
INVITE sip:[email protected]:5060 SIP/2.0
To: <sip:[email protected]>
From: "+13299121212" <sip:[email protected]>;tag=gK0c568006
CSeq: 469708 INVITE
Accept: application/sdp
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS
Content-Disposition: session; handling=required
Content-Type: application/sdp
Supported: replaces
P-Asserted-Identity: <sip:[email protected]>
Content-Length: 282

The number you are looking for may be in P-Asserted-Identity (or another field).

But it seems like if this is supposed to be 24/7 then you should just port the mobile number to your VoIP provider and then you don't have to deal with any of this nonsense no?