Unable to Forward Calls to External Numbers

Our parking lot is being resurfaced & the people in one building are working out of the other. They want to forward all their calls to their cell phones and did so using the Call Forward All feature on their Cisco 7960 IP phones running SIP firmware. (I also tried Lorne’s pay-it-fwd script to bypass the Cisco hardware, but get the same results.) If I call from another internal IP phone, the calls are forwarded fine. However, if an external caller is transferred to their extension or if I call one of their DIDs directly, the calls fail, receiving a SIP code 604 from our trunk provider.

I contacted our SIP trunk provider & they set our trunk to allow the P-Asserted-ID SIP header to allow the caller’s caller ID to flow through to the cell phone, but it still fails as PBXact is not setting this field. There’s lots of chatter about this type of thing on the forums & internet as a whole, but I’ve been able to find nothing to help me fix the issue.

Does anyone know how I can configure PBXact 13 to send our store’s caller ID in the From field (which the provider requires) and the P-Asserted-ID field to that of the caller being transferred without breaking anything?

Are you using Chan-SIP or PJ-SIP? The answer will vary depending on your implementation details.

Instead of CFW, you try using Find Me Follow Me and just turn the phones off. This will forward the calls directly instead of running through the CFW logic. I don’t know that it will help your specific P-Asserted-ID problem, but it is another avenue to try.

There are lots of examples in the forum on setting up both Chan-SIP and PJ-SIP for using P-Asserted-ID. Look for ones from @Stewart1 in particular. He’s very thorough in his explanations and usually gives excellent explanations on these advanced topics.

The Cisco phones need Chan-SIP - won’t work with PJ-Sip as the NAT/never option doesn’t function right. Remember fighting with it when first setting up the phones - wanted to use PJ-Sip as it was newer, but could not make the Cisco phones work with it. Setting them up with Chan-Sip was trivial, so just went with that.

I tried the Find Me Follow Me yesterday, but got the exact same results. Tried using the number as the forwarded destination & the number# as well - only worked when using just the number itself.

I’ll look up Stewart’s posts on the subject & see if I can’t glean enough to solve this issue - thanks @cynjut . Probably don’t need to tell you, but stuff like this is outside my realm of expertise and I really don’t know what I’m doing… Give me a coding task to complete using a a variety of languages over trying to figure out how to change a system someone else made any day. :laughing:

Assuming a chan_sip trunk, add to your config
fromuser=(Store's caller ID)
sendrpid=pai

If you still have trouble, it’s likely that the caller ID is not in the format that the provider expects.
At the Asterisk command prompt, type
sip set debug on
make a failing test call, paste the Asterisk log for the call at pastebin.freepbx.org and post the link here.

If your trunk is pjsip, use
From User: (Store's caller ID)
Send RPID/PAI: Send P-Asserted-Identity header
and for the log, use
pjsip set logger on

Thank you for the input @Stewart1… I’ve been tearing my hair out all afternoon looking at old forum posts, information online, etc, trying to figure out how to make this work. Tried sendpai=yes and send_pai=yes in the trunk setup, but neither had any impact. Put the main number in the Extension details under Outbound CID thinking that might do it, but also no luck. Going to try the two lines you mentioned now.

One question about them. We have an off-site location with 2 phones at it. These two phones are set to broadcast a different caller ID so that 911 knows that calls aren’t coming from our main location. Will the fromuser= line override this?

Partial success!

Added those two lines & tried calling a forwarded line to my cell phone and it rang through! I had no audio either way, but that’s at least a good first step. :slight_smile:

Telco told me that the P-Asserted-Identity header should be the number of the person calling/being forwarded & a packet capture during my test call reveals it’s set to the number it’s being forwarded to instead - that of my cell in the case of my test call. Maybe that has something to do with there not being audio on the call??? :question: :confused: :thinking:

Please understand that a SIP connection is only the first part of a call, any resulting negotiated SDP session will carry the media but that ‘pair of ports’ needs to be ‘transported’ appropriately to the other endpoint.

I would encourage you to start off with sngrep to ‘debug’

Thanks for the info @dicko … looked into sngrep & it appears to be an easier way to do a packet capture and display it in a prettier way than tcpdump, similar to how wireshark breaks apart a SIP conversation only for command line. Planning on installing that & seeing what it shows. Having it would prevent me from having egg on my face here; the P-Asserted-Identity is correct when being sent to telco. (I was looking at the wrong packet… :frowning: )

Any ideas of how to troubleshoot the ports transporting the audio? And, this is interesting, I changed nothing - my desk phone is still forwarded to my cell & the trunk set up with the two lines @Stewart1 provided that worked the first time I called only without audio - only subsequent test calls have failed to ring on my cell. Packet capture shows the call going out… just gets lost before it hits my cell phone. :confounded: (I hate being so out of my element and not knowing what I’m doing!)

Again sngrep will expose the negotiated media port and codec, how your network handles that further is another story

1 Like

The most common cause of no audio on a forwarded call is lack of proper port forwarding.
In your router/firewall, you must forward the RTP port range (default is UDP 10000-20000) to the PBX LAN address.

For troubleshooting the failure to ring, at the Asterisk command prompt, type
sip set debug on
make a failing test call, paste the Asterisk log for the call at pastebin.freepbx.org and post the link here. Also, report what the caller hears.

Chasing RTP works better if you start with

rtp set debug {on,ip}

ideally you will see two streams of packets going bidirectionally between the two endpoints (one the two sequential ports of the A leg, the other the two sequential ports of the B leg), they should be interleaved nicely and without drops or ‘out of sequence’ packets, any asymmetry is both suspect and easily spotted.

Figured out the cause of the 1-way audio…

Our Meraki edge device has a fiber (primary) and cable (secondary) line on it. There are flow preferences set up in it to direct all traffic intended for our provider’s SIP server IP out our cable line. The RTP streams for the forwarded call are being sent to the IP of the fiber though. No clue why, other than this kind of garbage seems to happen every time they update the Meraki…

Our Meraki is confused again, stuck sending traffic to our telco out the wrong interface even though it’s programmed to send it out the secondary. The interface connected to the fiber is deactivated, yet SIP registrations are still coming into our provider from our fiber line IP. :angry:

This is not the first time this has happened since the last firmware update & I’m ashamed I didn’t think to check it as soon as the no-audio situation became clear. :frowning_face:

Thank you for the ideas & help getting the forwarding issue with setting the P-Asserted-Identity header set to send correctly.

Again, investigate the native negotiation of the the SPD port and IP address as Asterisk sees it , sngrep is your friend here (there are other more complicated tools like tcpdump and wireshark)

Your router is involved in that negotiation as it can rewrite/announce routes that might be inappropriate for your multi-homed network, but not necessarily route that traffic appropriately. asterisk will use whatever your router tells it to.

After fixing the Meraki edge device & verifying it’s functioning properly again, the problem remains much the same. I’ve worked extensively with telco and they’re saying that it seems like the PBX is not connecting the inbound/outbound RTP streams for calls that are directly forwarded out to an external number. I did a bunch of testing this morning:

If I forward extension A to an internal extension, it works fine.
If I forward extension A to a cell phone and call it from an internal extension, it works fine.
If I forward extension A to a cell phone and call our main number, then have them transfer me to extension A, it works fine.
If I forward extension A to a cell phone and call extension A’s DID from another cell phone, the call rings through but there’s no audio.

I’ve done packet captures from the server command line during all of these calls and wireshark is unable to find the RTP streams for calls being forwarded directly out, so I am unable to refute telco’s hypothesis. I set up a network tap on the internet line all calls are traversing & wireshark cannot find the RTP streams for these calls in those captures either. The call recordings (‘forced’ on all calls) on the server, is a blank 44 byte wave header for both the incoming & outgoing recordings, so they might be right.


I did find the following in the ‘full’ log when it’s setting up the outbound / forwarded call, the cell number the extension is forwarded to has been redacted as FWDNUM for the destination number:

[2021-07-26 11:09:12] VERBOSE[4335][C-00050578] pbx_builtins.c: Goto (from-internal,FWDNUM,7)
[2021-07-26 11:09:12] VERBOSE[4335][C-00050578] pbx.c: Executing [FWDNUM@from-internal:7] GotoIf(“Local/FWDNUM@from-internal-005bd7e5;2”, “1?restrictedroute-453e406dcee4d18174d4ff623f52dcd8,FWDNUM,2:outbound-allroutes,FWDNUM,2”) in new stack
[2021-07-26 11:09:12] VERBOSE[4335][C-00050578] pbx_builtins.c: Goto (restrictedroute-453e406dcee4d18174d4ff623f52dcd8,FWDNUM,2)
[2021-07-26 11:09:12] VERBOSE[4335][C-00050578] pbx.c: Executing [FWDNUM@restrictedroute-453e406dcee4d18174d4ff623f52dcd8:2] Gosub(“Local/FWDNUM@from-internal-005bd7e5;2”, “sub-record-check,s,1(out,FWDNUM,force)”) in new stack
[2021-07-26 11:09:12] VERBOSE[4335][C-00050578] pbx.c: Executing [s@sub-record-check:1] GotoIf(“Local/FWDNUM@from-internal-005bd7e5;2”, “0?initialized”) in new stack

Don’t know what ‘restricted route’ means or if it’s pertinent to the issue at hand as the call does go out & reach the cell phone being called - there’s just no audio after it’s answered. AFAIK, I did not set up any restrictions in the system, cannot find any restrictions in the outbound route configuration, and the extension is able to dial the cell number it’s forwarding to, so am at a loss. :thinking: (I’ve tried going to the outbound routes configuration examples as suggested by other threads I’ve found on this topic, but get nothing but an error 503 back.)

To see the rtp traffic streams as Asterisk sees and generates them

rtp set debug {on,IP}

That’s a LOT of scroll generated by that command! :smiley: I see the inbound RTP stream, but there is no setup for the outbound call. (As regular calls are, prefixed with ‘sangomacrm.agi’ before the details.)


Interestingly, if I set the phone to use find me/follow me instead of an unconditional forward and make a test call, if the user picks up the call forwarded to their cell phone, there’s no audio. If they do not pick up and the PBX pulls the call back to send it to their work voice mail, it’s fine.

For working bidirectional audio you will see two streams for each leg (generally four streams) they will have IP addresses and timestamps and direction, thus two ‘from’ Asterisk and two ‘to’ asterisk, missing streams can thus be identified.

https://wiki.xcallymotion.com/plugins/servlet/mobile?contentId=327942#AsteriskCLIusefulcommands-RTPDebugging

If restrictedroute appears in your log, it almost certainly means that the call was rejected.

By default, a forwarded call attempts to send the number of the original caller as caller ID on the outbound leg. If you are using Extension Routes, Class of Service or Custom Contexts to restrict Outbound Routes to particular extensions or groups, it’s likely that the original caller’s number will not match any of them and the call will be rejected.

I can see that the outgoing RTP stream is not showing up in the RTP debug output… what I don’t understand is how I go about figuring out why?

I’ve tried that link to xcallymotion from 3 PCs and my cell phone spanning linux, different versions of windows, wired, wifi, and cellular data. All I get is a basic page framework (blue bar at the top) and a white box instead of any content. Does one need an account / be logged in / etc???


The wiki seems to be operational again & I’ve gone through what it says about restricted routes and I don’t have what they refer to. I have 2 SIP trunks - one to a local overhead pager and one to telco. There are 3 outbound routes - emergency, pager, and default. There are some dialing patterns in the Default route to redirect calls to 900 numbers to our operator, but nothing restricted.

Class of Service was enabled by default, but there are no rules defined in it. According to the help text on the page, this means that everything is allowed. (“Extensions that are not assigned to a Class of Service have full access”.)

I feel the restricted route message is the clue of what’s wrong, but I’m not knowledgeable enough about the PBX to figure out why. :worried: Plus, the call is making it to the cell phone when forwarded… really scratching my head on this one.