Caller ID not delivered

Status
Not open for further replies.

Vincent1975

New Member
Jan 31, 2017
15
0
1
49
Hi guys,

I’m playing with the FusionPBX in the last several days and actually I have so far 2 major problems:

1. The carrier connected to the FusionPBX works with IP authentication (no registration) on port 5060. So, obviously I have to use the Internal SIP profile, but it is by default with registration. I set the Register=False within the Gateway setup and I added the IP address of the carrier in the Access Control/Domains to be allowed, also I added it to the acl.conf.xml file, restarted the server, still getting :

Rejected by acl "domains". Falling back to Digest auth

on the carrier's CDRs, the error shown is "407 proxy authorization required". So, the Fusion obviously still requests registration.

And cannot get the call delivered to the extension. Why ??? It should work, but it doesn’t.



2. The outgoing calls are OK, but the Caller ID is “Unknown”, regardless that there is a Caller ID name and number set for the extension (both for internal and externals calls). Actually the delivered to the carrier CID is: admin What could be the reason?

Thank you in advance!
 
Last edited:

DigitalDaz

Administrator
Staff member
Sep 29, 2016
3,044
565
113
Firstly when possible, route the inbound calls from the carrier to port 5080 when possible.

In order to diagnose the CID issue, you will need to provide more info on how you have configured the gateway. Have you put in a dummy username and password? This is required.
 

Vincent1975

New Member
Jan 31, 2017
15
0
1
49
Thank you, DigitalDaz!
What do you mean by "route the inbound calls from the carrier to port 5080"? The carrier cannot send me the calls to another port, only 5060. Do you mean to reroute using the iptables or the other OS features?
Several years ago I used to play with the FusionPBX. With earlier version of course. And there I was able to resolve this issue by adding the IP address of the carrier to the acl.conf.xml file. Why it doesn't work now? And actually the right way should be using the Access Control/Domains, to allow there the IP address. But it doesn't work either.

In regards of the CID:
Yes, there are a dummy user and pass in the gateway configuration. The gateway seems to be connected, I can dial out, just the CID is not delivered. Also on the extension I have "Effective Caller ID Name" and "Effective Caller ID Number" for both the internal and external calls. But when I take a look on the CDR of the carrier, I see there that the CID instead of the number in the "Effective Caller ID Number" field is just "admin". BTW, the dummy user in the gateway setup is also admin, but when I changed to admin1, the CID delivered to the carrier remains "admin". I did a SIP trace and inside of the SIP INVITE, the CID related info is: "SIP from address User Part: admin", while it should be the chosen CID number. The Name part of the CID is delivered well.

Please assist!

Thank you in advance!
 

DigitalDaz

Administrator
Staff member
Sep 29, 2016
3,044
565
113
Thank you, DigitalDaz!
What do you mean by "route the inbound calls from the carrier to port 5080"? The carrier cannot send me the calls to another port, only 5060. Do you mean to reroute using the iptables or the other OS features?
Several years ago I used to play with the FusionPBX. With earlier version of course. And there I was able to resolve this issue by adding the IP address of the carrier to the acl.conf.xml file. Why it doesn't work now? And actually the right way should be using the Access Control/Domains, to allow there the IP address. But it doesn't work either.

In regards of the CID:
Yes, there are a dummy user and pass in the gateway configuration. The gateway seems to be connected, I can dial out, just the CID is not delivered. Also on the extension I have "Effective Caller ID Name" and "Effective Caller ID Number" for both the internal and external calls. But when I take a look on the CDR of the carrier, I see there that the CID instead of the number in the "Effective Caller ID Number" field is just "admin". BTW, the dummy user in the gateway setup is also admin, but when I changed to admin1, the CID delivered to the carrier remains "admin". I did a SIP trace and inside of the SIP INVITE, the CID related info is: "SIP from address User Part: admin", while it should be the chosen CID number. The Name part of the CID is delivered well.

Please assist!

Thank you in advance!

In the gateway settings advanced, there is an option caller id in from, try that, it should work.

If the carrier can only send to 5060, then yes, add them to the domains acl in the access control list from the GUI. Once you have done that, make sure to flush memcache and reloadacl. Both of these can be done on the SIP Status page
 

Vincent1975

New Member
Jan 31, 2017
15
0
1
49
Unfortunately it doesn't work. Neither the Dial In, nor the CID. It's possible to have relation between the two issues...

In the SIP status I see in the data field of the gateway: sip:admin@88.88.88.88 where 88.88.88.88 is the IP of the carrier. and I'm getting 'admin' as a CID, should be related. But the biggest problem is that obviously the PBX doesn't respect the 'allow' settings in the Access Control/Domains
 

DigitalDaz

Administrator
Staff member
Sep 29, 2016
3,044
565
113
Unfortunately it doesn't work. Neither the Dial In, nor the CID. It's possible to have relation between the two issues...

In the SIP status I see in the data field of the gateway: sip:admin@88.88.88.88 where 88.88.88.88 is the IP of the carrier. and I'm getting 'admin' as a CID, should be related. But the biggest problem is that obviously the PBX doesn't respect the 'allow' settings in the Access Control/Domains

Could you please screenshot the settings of both the gateway and the ACL.
 

Vincent1975

New Member
Jan 31, 2017
15
0
1
49
upload_2017-2-2_8-7-1.png
upload_2017-2-2_8-7-12.png

upload_2017-2-2_8-7-21.png

Where 88.88.88.88 is the IP of the Carrier and fusion.dom.com is the Fusion domain. fusion.dom.com is resolvable via the DNS of course.
 

DigitalDaz

Administrator
Staff member
Sep 29, 2016
3,044
565
113
Firstly, you do not put anything in the domain part, just leave that empty, secondly, you seem to be showing an IP not a CIDR, a CIDR would have /32 at the end.
 

Vincent1975

New Member
Jan 31, 2017
15
0
1
49
Thank you,
now it's OK. I've tried with /32, but with the info for the domain.

Well, the inbound is OK. Now to solve the issue with the CID :)

If I take a look on the SIP status, for the gateway data, there is: sip:admin@88.88.88.88 where the 88.88.88.88 is the IP address of the gateway. Well, it doesn't seem to be a coincidence, that on the SIP trace, I see "SIP from address: sip:admin@88.88.88.88", instead of to be the number, set in the extension's "Outbound Caller ID Number" field. This number, I can find only in the RPID part of the INVITE header. But the gateway expects it to be in the "SIP from address".

I'm sure you'll give me the right reason for this issue :)

Thank you in advance!
 

Vincent1975

New Member
Jan 31, 2017
15
0
1
49
Hi guys,
any ideas in regards of the Caller ID issue? Why it's delivering sip:admin@88.88.88.88 where 88.88.88.88 is the IP of the outgoing gateway instead of the number part of the caller ID?

From: "CallerID name" <sip:admin@88.88.88.88>;tag=8Qvvmm46SNQceg
SIP Display Info: "CallerID name"
SIP from address: admin@88.88.88.88
SIP from address User Part: admin
SIP from address Host Part: 88.88.88.88
SIP from tag: 8Qvvmm46SNQceg


in the Gateway setup I have "Caller ID In From=true". But regardless of the value in this field, the result is the same.
 
Last edited:

Vincent1975

New Member
Jan 31, 2017
15
0
1
49
A reboot was necessary after the set of "Caller ID In From=true". Regardless that I did 'Flush memcache", "Reload XML". Perhaps the information is not updated automatically.

Is it possible somehow to be informed if the operation requires a reboot?
 

DigitalDaz

Administrator
Staff member
Sep 29, 2016
3,044
565
113
There is absolutely nothing that needs a reboot. If you mod a gateway you do need to sip and start said gateway.
 

Vincent1975

New Member
Jan 31, 2017
15
0
1
49
Thank you, Daz!
Agree, to restart the gateway only was enough. But I didn't know that is necessary to be restarted. It's good to have kind of prompt for operations which require restart of the gateway or any other additional activities after the "Save" button.
 
Status
Not open for further replies.