FreePBX version 15.0.17.34, asterisk version 16.17.0
I have multiple DIDs at voip.ms with most of the complexity also hosted there
including IVR and voicemail. My goal is to implement some old style distinctive
ringing where call comes in at single DID, IVR says “press 1 for Dick, press 2 for Jane”
then invokes some ring groups that include separate extensions for Dick & Jane
at an on-prem server. Those extensions actually ring the same analog phones
by DAHDI/3r2 or DAHDI/3r3.
I can set up 2 trunks using subaccounts and route the calls fine. As numerous
other posters have reported, all the inbound traffic ends up the first trunk and with
same DID, even if I register the trunks to different ports (1 on 5060, 2 on alternate 42872).
So I cannot distinguish the calls; the DID is the same and if I had a custom context on
trunk #2 it is never invoked (i.e. simply rewrite DID with something unique).
What does work is putting one trunk on chan_sip and one on chan_pjsip.
And it works fine if I register each to different POPs (with some kludgy forwarding
to virtual DID to get calls routed between POPs). That ends up sending a different
DID which I can use directly.
Why am I doing it this way? The overall system is much more complex as Dick & Jane
travel between multiple locations and their calls need to ring several places… Some of
those places have newer multi-line IP phones that each register separately (to voip.ms)
so don’t have this problem, but one location they want to keep their old analog phones.
Is there a better way, ideally using chan_pjsip with both trunks to same POP.?
VoIP.ms does not implement port 42872 properly – they just forward it in their firewall to 5060. The incoming INVITE still shows 5060 in its Contact header, so using an alternate port is useless for this application.
pjsip has a feature Send Line in Registration, specifically intended to distinguish incoming calls to multiple trunks registered to the same server. Assuming that you have it on and are not overriding it with Match (Permit), I don’t know why it isn’t working and we could perhaps troubleshoot that.
However, unless you need other information that VoIP.ms is sending in the SIP URI, just set Contact User to e.g. 3425 for Dick’s trunk and 5263 for Jane’s. If Context for both is [from-trunk] or [from-pstn], then calls for Dick will show 3425 as the DID and calls for Jane will show 5263. Route those with separate Inbound Routes as desired.
I’m open to different hardware, just trying to adapt a server that has existed for 10+ years.
The FreePBX system used to host all kinds of other functionality that was desirable to
have in house when it was installed, but most has moved upstream to voip.ms and
other cloud services. It happens to still have a few other extensions/devices in addition
to the main house phone (a security system, multiple door phones) and all of that
should be possible to replace with simple(er) ATA hardware. The trick would be how to
configure an ATA to register 2 lines (the subaccounts), with inbound calls to single user
(fxs) and with appropriate ring cadences. The few basic ATAs I have used don’t have
the programmability to say ‘inbound SIP on channel2 forward to user1 with alert-info=r2’.
If that exists in a black box I’d probably take it, otherwise the future is likely going to
be replace analog phones with IP phones as was already done at the other locations.
Changed port back to 5060 for both trunks, verified both have Send Line in Registration.
Not using Match, it has the default (blank). Added different Contact User values.
Example of resulting entry in pjsip.registration.conf and pjsip.endpoint.conf below.
The 2nd trunk is subaccount _004 instead of _003.
Nothing appears to have changed on inbound calls. CDR still shows the original DID
and not the Contact User values. Log shows both inbound calls arrive on the first trunk
only. Context from-pstn or from-trunk made no difference.
Something seems very wrong here. Look at Reports -> Asterisk Info -> Registries and confirm that you see only the two expected VoIP.ms entries and they both show Registered.
At the Asterisk command prompt, type pjsip set logger on
make a test call in and look in the Asterisk log (or on the console) at the incoming INVITE, especially the URI and To header. I’m not a VoIP.ms customer, but believe that you should see the 2222 in the URI and the DID in the To header.
If you don’t see the 2222, look for outgoing REGISTER requests (your expiration is 120, so you shouldn’t have to wait more than a minute for them to appear) and confirm that the contact header for each is correct.
In the incoming INVITE, does 100000_003 or 100000_004 appear anywhere? If so and all else fails, we could extract that and use it for routing.
If you still have trouble, paste the log including SIP trace for REGISTER and INVITE at pastebin.freepbx.org and post the link here. Redact as desired, but make it clear what each changed value represents.
Invite does not have the contact. The invites have almost everything the same
except obvious call record IDs and this:
X-Dest-User: 100000_003
Or _004 when coming through the other trunk. I assume there is something
I can put in a custom context on either of the trunks to probe X-Dest-User
with PJSIP_HEADER and overwrite DID then simply pass to from-pstn
and the dog can see the rabbit.
Do something analogous to the from-pstn-toheader context you will find in /etc/asterisk/extensions.conf
Not tested, but should be close (put in extensions_custom.conf):
[from-voipms-destuser] exten => _.,1,NoOp(Attempting to extract pseudo-DID from SIP X-Dest-User header) exten => _.,n,Goto(from-pstn,${CUT(PJSIP_HEADER(read,X-Dest-User),_,2)},1)
Set the Context for both trunks to from-voipms-destuser and this should result in DID being 003 or 004, which your Inbound Routes can process as desired.
If you’re happy with the workaround, great. Otherwise I’d suggest asking voip.ms about this behavior. It would be more normal to send the DID in the request URI, obeying the Contact header that you send them. Or even the To: header, which some providers use. I don’t know why they would expect people to extract custom headers out of call invites in order to properly route a call.
I understand this is being used to distinguish calls to the same DID that are first being pre-processed at voip.ms by an IVR before the INVITE hits FreePBX.
