Incoming Call DID Diversion

FPBXUser2016 · 2020-12-18 15:21:10 UTC

Hi guys,

We use: FreePBX 15.0.17.5 - Asterisk Version: 16.15.0

I have the Voice Operator Panel installed on my computer and setup as an pjsip extension. Trust RPID is enabled and Send RPID is Send P-Asserted-Id. Diversion is activated in Advanced Settings.

I’m wanting to setup VOP as multi-line. Now for this to work, the TO field on the incoming call screen needs to display the incoming DID as per the Inbound Route DID set.

There is only ONE trunk. The trunk has a dedicated DID assigned to it as per the VOIP provider.
We have a block of 10 DID’s.
Each DID has it’s own Inbound Route with NO Caller ID number set. ONLY the DID number is set.
The destination for each Inbound Route is to the VOP extension

Issue:
On the incoming call screen FROM shows the persons callings number. However, the TO field shows the VOP extension number that is setup instead of the Incoming DID number as per Inbound Route.

As per VOP FAQ:

Our application relies on the IP PBX to put the called phone number in the SIP “To” or “Diversion” (RFC5806) or “P-Called-Party-ID” (RFC3455) fields of the INVITE.

For example, using Asterisk, you need to add the “Diversion” or “P-Called-Party-ID” fields using SIPAddHeader() before issuing the Dial() to the VOP extension.

I have searched and read up on quite a number of posts already but haven’t actually come across anything that helped. I’m not very clued up on how to get this done.

Your assistance would greatly be appreciated. Should you require any further information ie. logs etc please feel free to treat me like a total newby and guide me so I can supply the correct information first time around.

Thanks!

Stewart1 · 2020-12-18 20:32:20 UTC

Assuming that your trunking provider puts the called number into the To header and the context for your trunk is from-pstn-toheader, change it to from-yourtrunk and add this to /etc/asterisk/extensions_custom.conf

[from-yourtrunk]
exten => _.,1,Set(CALLERID(rdnis)=${CUT(CUT(PJSIP_HEADER(read,To),@,1),:,2)})
exten => _.,n,Gosub(func-set-sipheader,s,1(Diversion,<sip:${CALLERID(rdnis)}@1.2.3.4>))
exten => _.,n,goto(from-pstn-toheader,${EXTEN},1)

or

[from-yourtrunk]
exten => _.,1,Set(CALLERID(rdnis)=${CUT(CUT(SIP_HEADER(To),@,1),:,2)})
exten => _.,n,Gosub(func-set-sipheader,s,1(Diversion,<sip:${CALLERID(rdnis)}@1.2.3.4>))
exten => _.,n,goto(from-pstn-toheader,${EXTEN},1)

according to pjsip or chan_sip trunk.

Stewart1 · 2020-12-18 20:49:20 UTC

If your trunking provider sends the called number in the SIP URI (trunk context set to from-trunk or from-pstn), you can probably get away with just

[from-yourtrunk]
exten => _.,1,Gosub(func-set-sipheader,s,1(Diversion, <sip:${EXTEN}@1.2.3.4>))
exten => _.,n,goto(from-trunk,${EXTEN},1)

Stewart1 · 2020-12-19 05:18:14 UTC

Another thought:

Instead of custom dial plan, just try setting up VOP as a trunk (Registration Receive, Authentication Inbound). One downside is that you won’t be able to use voicemail, forwarding, etc.

FPBXUser2016 · 2020-12-22 02:22:31 UTC

Thanks Stewart1

Will definitely give your suggestions a shot and let you know what happens.

Unfortunately I won’t be able to setup VOP as a trunk because we still need to transfer to extensions as well as transfer to cellphone. So basically we do need the PBX capabilities.

I’ll let you know if I run into issues.

Stewart1 · 2020-12-22 02:52:38 UTC

There are a number of subtleties here. Can you please explain your application?

I assume that you are answering calls on behalf of several organizations. But you’re not just an ‘answering service’; otherwise all your transfers would be external. If you are a call center that provides sales / customer service / support for multiple organizations, then you probably need the caller ID on outbound calls (including attended transfer) to show a number for the client organization. If VOP is an extension, you would have to use ‘trunk access codes’ or similar to select the outbound caller ID. On blind transfer, FreePBX normally passes the number of the original caller, which may not be desirable for your workflow.

FPBXUser2016 · 2020-12-22 08:24:22 UTC

Hi Stewart,

We are looking at providing a Virtual Receptionist type of service to new and small businesses. Obviously it would work for medium sized business as well. Especially in today’s time with lockdowns happening.

One part of your explanation is correct.

Ultimately we would provide a company signing up with us with a DID, we would purchase in bulk so price is low. In the event that they already have an onsite HARD landline then we would use ie 2 port type of ATA to answer and forward to extension or the like.

The rest of the process is basically either IVR or send to operator type of scenario.

We would then answer calls and take messages OR we would forward calls to either external numbers OR extensions. All this would obviously depend on IF the client has any current setup or if everything is new. Ultimately instead of forwarding to external numbers (which are cellphones) we would suggest to the client to use a softphone which we would white label.

Obviously it is perfectly fine if it transfers the original caller ID to the external call. That’s not an issue at this stage at least.

FPBXUser2016 · 2020-12-22 09:30:14 UTC

Hi,

Sorry man. I’m going to go completely air head on you now. I think I’m just having lack of sleep at the moment so I’m sure I’m missing something. Here’s my trunk details:

OUTGOING:

Trunk Name: lqi-trunk

Peer Details:

username=0213006140
type=peer
secret=XXXXXXXXXXXX
host=sip.switchtel.co.za
dtmfmode=rfc2833
canreinvite=no
qualify=yes

INCOMING:

User Context: lqi-trunk-in

User Details:

username=0213006140
type=user
secret=xxxxxxxx

As I said, I’m sure I’m missing something. Do advise if you see anything wrong with the above as well.

Stewart1 · 2020-12-22 17:02:36 UTC

I don’t know how the separate Peer and User interact with custom contexts, so please try this:

First, in Peer Details, change type=peer to type=friend and add context=from-trunk. In the Incoming section, make User Context and the User Details section completely blank (but leave the Register String alone). Confirm that incoming and outgoing calls work as before.

If the above is successful, then put this in extensions_custom.conf

[from-lqi-trunk]
exten => _.,1,Gosub(func-set-sipheader,s,1(Diversion, <sip:${EXTEN}@1.2.3.4>))
exten => _.,n,goto(from-trunk,${EXTEN},1)

and in the Peer Details, change
context=from-trunk
to
context=from-lqi-trunk
and test that the called number propagates to VOP.

FPBXUser2016 · 2020-12-22 18:12:55 UTC

Hi Stewart,

Thanks for the guidance. Followed your instructions. Step one works when I make those changes. Then adding the ext conf and making the context change makes no difference. It sill passes through the extension number it’s sending the call to instead of the incoming DID number.

Stewart1 · 2020-12-22 18:16:41 UTC

At the Asterisk command prompt, type
pjsip set logger on
sip set debug on
make a test incoming call, paste the Asterisk log for the call (which will include SIP traces for both trunk and extension) at pastebin.freepbx.org and post the link here.

FPBXUser2016 · 2020-12-22 18:56:25 UTC

Here we go:

https://pastebin.freepbx.org/view/00bcd08a

Stewart1 · 2020-12-22 20:46:52 UTC

Two problems preventing proper debugging:

The SIP traces are not present. When you Apply Config (or fwconsole reload), the trace commands are canceled. If that was your case, issue them again, just before making a test call. Otherwise, the trace commands may not have executed properly. When you issue sip set debug on at the Asterisk CLI, you should see SIP Debugging Enabled and when you do pjsip set logger on you should see PJSIP Logging enabled.

The other issue is weird. Line 3:
[2020-12-22 20:51:53] VERBOSE[5535][C-00000002] pbx.c: Executing [0213006140@from-trunk-sip-from-trunk:1] Set("SIP/from-trunk-00000000", "GROUP()=OUT_1") in new stack
implies that you somehow have a trunk named ‘from-trunk’ (without the quotes).

Confirm that on both the General tab and the sip Settings tab for your trunk, Trunk Name is set to lqi-trunk (or whatever you want to call it). And, check that on the main Connectivity -> Trunks page, you don’t have a trunk with a strange name. Then, the Peer Details should include
context=from-lqi-trunk
matching the name of the context you added to extensions_custom.conf

If no luck, make a new failing call and paste the log.

FPBXUser2016 · 2020-12-22 21:18:00 UTC

Ok. I’ve checked all when you said and made changes accordingly. I redid the logging.

https://pastebin.freepbx.org/view/80c20ad8

Stewart1 · 2020-12-22 21:37:18 UTC

OK, so now we have chan_sip debugging but no pjsip logging. Did you get the expected response when you set pjsip logger on?

But the incoming call matched anbt-trunk, which we hadn’t discussed before. How is that related to lqi-trunk? And, it appears that anbt-trunk does not have a custom context= parameter, so the code in extensions_custom.conf did not get executed.

FPBXUser2016 · 2020-12-22 23:21:12 UTC

We have 2 trunks by the same provider. Obviously the only things that are different with the setup of the trunks are:

username
password
context
trunk name

As you noted there wasn’t a context parameter in the other trunk. I added the context and it seems that now the lqi trunk works. But now the 2nd trunk is registered but says “your call cannot be completed due to a temporary error”. I’ve run into this before and it’s been very frustrating to get them to work. Both were setup as SIP trunks.

I removed the 2nd trunk and set it up as a PJSIP and it now seems to be working fine as well as the DID number is being passed to VOP for the 1st trunk.

I’ve been struggling this whole time since you posted your last post an hour ago to get this to work. Did a number of things but the above seemed to get it to work.

Thank you so much for your help! I think in future I’ll just setup PJSIP trunks instead. Might be easier?

Stewart1 · 2020-12-23 00:00:20 UTC

chan_sip has problems with multiple trunks registered to the same server on the same provider. There are usually workarounds but unless you have an insurmountable problem with pjsip, IMO you should migrate away from chan_sip.

pjsip has an option in the Advanced trunk settings called Send Line in Registration. It’s off by default but if you turn it on and nothing breaks, multiple trunks on the same server should be correctly distinguished.

If you still have the “temporary error” issue, we can debug that separately.

I also noticed that Asterisk was set to prefer g729. IMO that results in a significant voice quality degradation (especially when calls are further forwarded off site) and should be avoided if possible. If you have a good reason for it (limited internet bandwidth, high cost of bandwidth, etc.) please explain.

FPBXUser2016 · 2020-12-23 00:19:30 UTC

Yeah. I think that’s what I will be doing in future and use pjsip instead. The “temporary” issue is resolved now as well.

As for g729. I haven’t totally done configurations yet. Kind of just did the basics in the meantime. Will be doing all those changes now that it’s working the way I required it to.

Thank you for all your assistance. Greatly appreciated!