Unable see DID called

Hello,

We are trying to implement a FoIP software solution for a client using an EMR with many different fax inboxes. The FoIP software is installed on a dedicated fax server. We have been able to register the software as a FreePBX extension and have confirmed we’re able to send and receive faxes.

Since there are many different fax inboxes, the software needs to see which fax number is called in order to route properly. The issue that the FoIP software is not seeing fax number called.

We’ve run a few wireshark captures from the fax server and the logs look like this:

From: “[CNAM]” sip:[mycallerID]@[freepbx_local_IPtag=…

To: sip:faxserver_IP
SIP to address: sip:[faxserver_IP]
Contact: sip:asterisk@freepbx_local_IP:5060

We’re hoping there’s a way to include the called number in the “To:” section. It seems odd that the captures don’t even see the extension number, but show asterisk where we’d expect it to be. We are on FreePBX 16.0.40.3. The inbound routes are configured individually and all send directly to our fax extension.

We’ve played around with the sip trunk settings, tried different contexts, and adding a CID prefix on the routes amongst other things.

We can see this information in the asterisk logfiles and CDR reports on the PBX, but it’s not passing to our fax server. Is there any way to include the called number in these logs?

You should set it up as a trunk, with Registration: Receive.

However, I’m surprised that you aren’t seeing the extension number in the To header.

Also, why didn’t the CID prefix work? Did the FoIP software not recognize it?

You haven’t said what the request URI was, or is that what you mean by SIP to address. However, if they are registering with you, the reason for not having a user part in the To header would be that they are not including it in their Contact header. chan_psjip will set To header to the same value as the request URI, and will use the Contact value, from the registration, as the request URI, when dealing with extensions. (I think it may substitute the user part when dealing with trunks.)

Ideally you would want IP based operation, not registration.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.