Follow-me fails on calls from a particular trunk

Hi, all. I have a FreePBX system (AsteriskNOW) with two SIP trunks, both from the same provider. Calls coming in on one trunk go to an IVR and calls from the other one go directly to my extension.

When someone accesses my extension (ext. 11) through the IVR but I don’t answer the call, my follow-me settings work properly and the call is forwarded to my mobile phone.

But if someone calls on the line that goes directly to my extension, they just hear a few rings and then silence. I don’t know why but it doesn’t seem to transfer to my mobile.

I opened the CLI and captured the data during one of the calls to my extension that didn’t make it to the mobile. It can be seen at

I also tried putting the log of a successful transfer (via the IVR) side-by-side with the one that failed, thinking I’d be able to figure out where it goes wrong. But I’m too much of a newbie and the data meant nothing to me.

Thanks for any and all help!

Thanks, Owl. To answer your questions, yes 1600 is a valid provider trunk. I named it with the last four digits of the phone number to distinguish it from my other, nearly identical trunk.

I have no idea what “customtrunk” is. I’m gonna have to look into that.

Yes, the cell phone destination is entered exactly as I would dial it from an extension - except for the pound symbol at the end, which is necessary for Follow Me (although I tried it without the pound sign, too.)

I started looking into the “CallerID” angle, and tried everything I could to match the ID of the outgoing call to what the provider was expecting, but I got nowhere. Another user suggested it might be a context issue and I started investigating that, too, but to no avail.

Finally, last night I did some more searching/reading online and found a post about RTP packets. It got me thinking about NAT issues and so I double checked my router configuration where I discovered that ports 10000 through 20000 were not open to the PBX box. Once I opened them up my forwarding started working perfectly. I feel a little foolish for the number of hours I (and others) spent trying to figure this out, only to have it be something simple, but I guess that’s how it goes sometimes.

The fact that the forwarding was working in one scenario and not the other was forcing me to think it couldn’t be a firewall issue. But in the working scenario the PBX is initiating the call (so the router sends the first RTP packet), whereas in the failing scenario it was just relaying RTP traffic from an outside call to another outside call, but not initiating either one. And that was the difference - if the PBX doesn’t initiate the call, the NAT router doesn’t allow RTP traffic.

Thank you for your reply and attention. I still want to find out what the “customtrunk” is, but as long as everything else seems to be working it’s not time critical.

I’m looking at these lines:
129. – Executing [s@macro-dialout-trunk:18] GotoIf(“SIP/xxxxxx1600-0971c070”, “0?customtrunk”) in new stack
130. – Executing [s@macro-dialout-trunk:19] Dial(“SIP/xxxxxx1600-0971c070”, “SIP/1600/xxxxxx7772|300|T”) in new stack
131. – Called 1600/xxxxxx7772

What is “1600” - is that a valid provider trunk? What’s “customtrunk” in line 129? I’m just wondering if your call is actually going out of the system on the trunk you think it is. When you configured the destination for your cell phone, did you enter the number exactly as you would dial it from an extension on your system?

The other possible problem might be if your provider refuses the call because it doesn’r recognize the caller’s CallerID as one that belongs to you. In that case you may have to override the outgoing CallerID in the trunk configuration.