3 posts / 0 new
Last post
schatnick
schatnick's picture
Joined: 2014/09/20
Points: 0

Having an issue where when our end user sets up forwarding on their Yealink T48S, the CallerID that shows on the final recipient's phone is the outbound CallerID of the forwarding extension instead of the original caller's CallerID. I have seen this issue in the forums before, but the suggested fix has not solved the problem.
https://www.thirdlane.com/forum/use-original-callers-caller-id-when-forw...

Default Values->Outbound Dialing "Allow use of original caller id in forwarded calls" is enabled.

"Allow tenant to manage CallerIDs" is enabled on the tenant.

Yealink's "Caller ID Source" option is set to "PAI-RPID-FROM"

sip.conf:

trustrpid=yes
sendrpid=pai

Have also tried leaving sip.conf with the default of "sendrpid=yes" and enabling PAI on the extention as below:
sip_peers.include:

sendrpid=pai

Our trunking provider allows PAI.

Thirdlane MT 9.1.4.14
Asterisk 13.27.0
Yealink T48S firmware 66.82.0.30

If I set up call forwarding via Find Me/Follow Me, the original CallerID does get sent, but only if the original caller is from outside our PBX. If I call from another extension on the same tenant to the extension in question, the outbound caller ID of the forwarding extension is sent instead of the tenant's default outbound CallerID.

Find Me/Follow Me is not a viable option for the end user. They need to be able to update the forwarding number from the desk phone because they don't have access to Communications Manager.

I can reproduce this behavior on a Polycom VVX 400.

Any help in solving this is greatly appreciated.
-Nick

schatnick
schatnick's picture
Joined: 2014/09/20
Points: 0

This forum post is where the PAI suggestion came from:
http://forum.yealink.com/forum/archive/index.php?thread-10807.html

eeman
eeman's picture
Joined: 2007/11/06
Points: 280

This wont work from a handset the way you think, because callerID gets established multiple times in the outbound routes script based on channel variables that get set during the call flow. A handset does not, not can it, create channel variables. A forward from a handset is a simple 486 Temporarily Moved message which triggers a dialplan redirect.

In order to send a call back out you would have to eliminate all callerID functions. Using your regular patterns is strongly discouraged as it will wreck havoc on normal calls as well as emergency calls. Instead you would want to create a unique custom pattern that invokes a callerid passthrough script. Your user would have to knowingly forward to a number that has been modified to utilize this feature.

Erik Smith
dCAP
Thirdlane/Asterisk Support available
esmith.bgnv@gmail.com