Chan_mobile works, but no callerid

I’ve gotten chan_mobile to work well for inbound and outbound calls on two cell phones, but I’m not getting caller-id information on the inbound calls. I just get the name of cell phone as listed in chan_mobile.conf.

Details:
I have two cell phones, and iPhone and an Android Moto X4. I have Asterisk 13.19.1 installed via FreePBX 14.0.1.36. For bluetooth adapters, I’m using a pair of Trendnet TBW-106UB bluetooth adapters, which use a Cambridge Silicon Radio CSR8510 A10 radio. Inbound and outbound calls all sound great. The only problem is that inbound calls to either phone are appearing on the Asterisk/FreePBX lines with the name of the phone (e.g. “iphone”, “moto-x4”) for the caller-ID, instead of the actual incoming caller-ID. The cell phones are receiving caller-ID properly, as it appears on the cell phone screen correctly. Here’s my chan_mobile.conf (with device addresses mangled for privacy/security).

[general]
interval = 30; number of seconds to connect to the device

[adapter]
id=hci0
address=aa:aa:aa:aa:aa:aa

[adapter]
id=hci1
address=bb:bb:bb:bb:bb:bb

[moto-x4]
address=cc:cc:cc:cc:cc:cc
port=3
context=incoming-mobile
adapter=hci0

[iphone]
address=dd:dd:dd:dd:dd:dd
port=8
context=incoming-mobile1
adapter=hci1

Any advice on how to get caller-id presented properly?

pleas check line port you callerid

Thank you for your response, tomiperdana49, but I don’t understand what you’re suggesting. I know that the incoming calls are providing caller-id info, as it appears on the cell phone screen.

I reran the asterisk “mobile scan” and received the following for the moto-x4 (again obscuring the device address):
Address Name Usable Type Port
cc:cc:cc:cc:cc:cc moto-x4 Yes Phone 3

So this confirms that the moto-x4 is on port 3, as shown in chan_mobile.conf above. Is that what you meant?

To answer my own question and ask another, I’ve found that this is currently a bug/limitation of chan_mobile.

First I looked at the FreePBX call reports and found that while the caller ID name was replaced by the name of my phone in chan_mobile.conf, the caller ID number was still intact. On my phones there’s only room for one display with preference going to the name, so on my phone it always lists the cell phone name (e.g. “iphone”) instead of the caller ID number. Still, replacing the caller ID name with my phone’s name is hardly useful. That would be like if I had a DAHDI trunk line and every incoming call was announced as “DAHDI/4-1” instead of the name of the caller.

I dug into the chan_mobile code to see why this happens, and found:

  1. The hfp_parse_clip routine parses out the caller-id number, but ignores the caller ID name. So, essentially it loses the caller ID name if the name was provided.
  2. Later, the ast_channel routine calls ast_channel_alloc to create the channel, and provides the cell phone name (e.g. “iphone”) as the fourth parameter, where the caller ID name should really belong.

In short, chan_mobile could capture and pass the caller ID name but doesn’t. I believe that it should pass the caller ID name if provided, or an empty name if none was provided so that the dial plan can come up with a substitute name however it wants (fill in the caller ID number, use a local dattabase, use a CID look-up service, etc.).

So now I need some guidance on where to file a bug report and perhaps assist with a patch. chan_mobile is distributed as part of the Asterisk source code, under the “addons” directory. Does this mean it is maintained through the normal Asterisk channels, or that it was contributed and is maintained elsewhere. Does anyone where the right place is for me to file a bug report or get in touch with the relevant developers?

It is in the tree but really has no active maintainer. It’s also extended support meaning that any issues are handled by the community, and as there is no active maintainer there is no telling when an issue would get looked into. If you provide a patch it can go through the normal review process and would get looked at.

Thank you, jcolp, for putting me on the right track. My C is rusty, but I’ll see what I can do. It doesn’t look like it should be too hard.