Purpose of Multi User extension
Multi User extension is a term we use to distinguish regular extensions and trunking services. Although we all are familiar with Trunks on PBXware and what their purpose is, for some of us it is not clear enough what exactly Multi User extension is and why it is being used if we have regular trunks available. Main purpose of the Multi User extension is providing a trunking service. It allows connecting remote, asterisk based systems (via trunk) to PBXware (via Multi User extension) in order to make and/or receive calls. On the remote side (in our example, we will use FreePBX) we will have an SIP extension that can make or receive calls. There will also be a trunk through which the extension will send or receive calls. For regular users, that is the whole story. As far as the person knows, he/she is a dialing number and it goes out through the trunk to the end user (the person whose number was dialed). However, there is more to it, such as, the call gets routed through another asterisk system (in our case PBXware) and then goes out through the regular trunk. Main purpose of this setup is money saving. Let me explain that. Imagine a reseller who is responsible for many asterisk based systems. For each one of them, he needs to provide trunking service (Voipinnovations, Telnyx, etc), which means each system needs to have a trunk. If we put a PBXware system in between, we are allowing all remote systems to connect to one PBXware system (each remote asterisk-based system will have a dedicated Multi User extension). On that single PBXware system with multiple Multi User extensions, we can have one trunk through which we can send all calls through all asterisk based systems.
Authentication methods
Before creating this kind of setup, Multi User is a feature in the PBXware license, so an Administrator who wishes to use it, has to contact Account Manager to enable it in the License. Once we have that enabled we can now consider which authentication method will work the best for us.
Two authentication methods can be used for a Multi User extension:
1. Registration Method
2. IP Authentication Method
Please note that not all asterisk-based platforms support both methods, so we need to choose a proper authentication method.
IP Authentication Method - troubleshooting
When setting a Multi User extension by using an IP authentication method, an Administrator should enable Allow IP address authentication for Extensions option. Option is available on Multi Tenant as well as on single tenants systems (Contact Center and Business edition). For Multi Tenant system navigate to the ‘Master Tenant’ —> ‘Settings’ —> ‘Tenants’ —> Edit Tenant —> ‘Features’ section —> ‘Allow IP Authentication for Extensions’ —> Set to’ Yes’
For single tenant solutions: ‘Settings’ —> ‘Servers’ —> ‘Features’ section —> ‘Allow IP Authentication for Extensions’ —> Set to ‘Yes’.
REGISTER and OPTIONS packets
How to properly configure Multi User extension to uses registration method based on IP, we can check on two following screenshots:
In pjsip.conf:
localhost ~ # cat /opt/pbxware/pw/etc/asterisk/200/pjsip.conf
; Automatically generated
[200101](endpoint-tpl,endpoint-user-tpl)
type=endpoint
aors=200101
accountcode=101
subscribe_context=t-200
moh_suggest=default
notify_early_inuse_ringing=yes
refer_blind_progress=yes
direct_media=no
force_rport=yes
rtp_symmetric=yes
rewrite_contact=yes
dtmf_mode=rfc4733
context=t-200
trust_id_inbound=yes
send_rpid=yes
mailboxes=101@t-200
allow=ulaw,alaw,g729
callerid=IPAuthtrunk <101>
32identify_by=ip
deny=0.0.0.0/0.0.0.0
permit=192.168.1.11/255.255.255.255
[200101](aor-tpl)
type=aor
max_contacts=0
qualify_frequency=60
qualify_timeout=8
contact=sip:192.168.1.11:5060
[200101]
type=identify
endpoint=200101
match=192.168.1.11
Please note that 200101-auth should not be there and that is perfectly fine. Also, Trust Remote Party ID should be set to Yes as well as Send Remote-Party-ID should be selected.
On remote side, let us create trunk:
Here we can also set Trust Remote Party-ID to Yes and select to Send Remote-Party-ID.
Let us watch REGISTER packet on PBXware side:
Content of REGISTER packet:
2022/05/15 21:41:12.090202 192.168.1.11:5060 -> 192.168.1.13:5060 REGISTER sip:192.168.1.13 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.11:5060;rport;branch=z9hG4bKPj8f3e8a34-4c73-40c3-b7dc-ef926a9019a2 From: <sip:IP_Auth_Trunk@192.168.1.13>;tag=afca9202-f558-421a-a9e7-867ae38f46cf To: <sip:IP_Auth_Trunk@192.168.1.13> Call-ID: 7cf2380f-a9c0-42cc-9df1-6e4df3e3d5f6 CSeq: 22369 REGISTER Contact: <sip:s@192.168.1.11:5060;line=xrfzblu> Expires: 3600 Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER Max-Forwards: 70 User-Agent: FPBX-15.0.17.34(16.17.0) Content-Length: 0
IP_Auth_Trunk is the name of the trunk we set on the remote side.
Now, let’s check OPTIONS packet that PBXware receives from trunk’s side:
2022/05/15 21:41:33.124329 192.168.1.11:5060 -> 192.168.1.13:5060 OPTIONS sip:IP_Auth_Trunk@192.168.1.13 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.11:5060;rport;branch=z9hG4bKPjbbd7e3f0-8126-4ba4-a4fa-fcb23702b877 From: <sip:IP_Auth_Trunk@192.168.1.11>;tag=ba2d5943-536c-449c-90f7-bcb6364fce24 To: <sip:IP_Auth_Trunk@192.168.1.13> Contact: <sip:IP_Auth_Trunk@192.168.1.11:5060> Call-ID: a608f9cd-9fcd-4e08-9cb5-0fa3ea2658a9 CSeq: 25763 OPTIONS Max-Forwards: 70 User-Agent: FPBX-15.0.17.34(16.17.0) Content-Length: 0
Since we are receiving 404 for both, clearly something is wrong.
Let’s take a step back and check how we created trunk:
As we mentioned previously, authentication based on username and secret is not needed so for the Authentication we need to set None.
With these settings, REGISTER is not being sent which is perfectly fine so we will check OPTIONS packet:
This now looks OK.
IP Authentication method - calls
In order to see how this authentication method works and if it is different in terms of making calls, let’s do some tests.
Outgoing calls
Extension 101 from Remote system dials 12345678912
Call comes to PBXware system and via Multi User extension gets forwarded to outside world via regular trunk.
Immediately we see the difference, there is no leg of the call that will show From User. With the registration method, the first leg would have From User (200100) , but using IP Authentication method, we only see that caller id from the remote side is forwarded in From header.
This is how INVITE looks like:
2022/05/15 21:55:01.856474 192.168.1.11:5060 -> 192.168.1.13:5060 INVITE sip:12345678912@192.168.1.13 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.11:5060;rport;branch=z9hG4bKPj3483dadc-ac87-4e1e-85cf-3ca6e61f9787 From: <sip:061643936@192.168.1.11>;tag=c56917a1-1bb9-4f51-be3c-d17187de6ada To: <sip:12345678912@192.168.1.13> Contact: <sip:asterisk@192.168.1.11:5060> Call-ID: bc4db41e-0c85-43c5-8f4b-357fc7f77339 CSeq: 14328 INVITE Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER Supported: 100rel, timer, replaces, norefersub, histinfo Session-Expires: 1800 Min-SE: 90 Remote-Party-ID: <sip:061643936@192.168.1.11>;party=calling;privacy=off;screen=no 37Max-Forwards: 70 User-Agent: FPBX-15.0.17.34(16.17.0) Content-Type: application/sdp Content-Length: 337 v=0 o=- 249730953 249730953 IN IP4 192.168.1.11 s=Asterisk c=IN IP4 192.168.1.11 t=0 0 m=audio 11050 RTP/AVP 0 8 3 111 9 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:3 GSM/8000 a=rtpmap:111 G726-32/8000 a=rtpmap:9 G722/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=maxptime:150 a=sendrecv
This is what Multi User forwards to outside world through regular trunk:
Incoming calls
Outside user dialls DID 12345678998 on PBXware that is binded to Multi User extension. PBXware via Multi User extension sends call to a remote system (FreePBX in our case) and rings extension that is registered there.
First leg we see here is what PBXware gets from trunk (regular trunk) and second leg is what PBXware sends to the remote system via Multi User extension. Let’s break that into smaller pieces.
INVITE PBXware receives from trunk (regular trunk):
2022/05/15 22:02:52.200231 192.168.1.12:5060 -> 192.168.1.13:5060 INVITE sip:12345678998@192.168.1.13:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.12:5060;rport;branch=z9hG4bKPja7b99e79-0552-4cb5-bea7-9a69172c8960 From: <sip:062074996@192.168.1.12>;tag=d69c6d61-93fc-4d65-aed8-3fcb3bb1e2de To: <sip:12345678998@192.168.1.13> Contact: <sip:asterisk@192.168.1.12:5060> Call-ID: 4f4485ff-1fed-4609-a2f1-9cb6751d1813 CSeq: 28843 INVITE Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER Supported: 100rel, timer, replaces, norefersub Session-Expires: 1800 Min-SE: 90 Max-Forwards: 70 User-Agent: Asterisk Content-Type: application/sdp Content-Length: 259
INVITE PBXware sends through Multi User extension to remote system (FreePBX, where extension that receives call is registered):
2022/05/15 22:02:52.247507 192.168.1.13:5060 -> 192.168.1.11:5060 INVITE sip:12345678998@192.168.1.11:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.13:5060;rport;branch=z9hG4bKPj6dcc04b9-a6ba-4669-8d2e-c84afb80c828 From: <sip:062074996@192.168.1.13>;tag=dfe2dafe-a02e-418f-aa39-eb1eaec1080a To: <sip:12345678998@192.168.1.11> Contact: <sip:asterisk@192.168.1.13:5060> Call-ID: 499c59ae-e5e0-4829-8339-bf9e0738eefc CSeq: 31216 INVITE Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER Supported: 100rel, timer, replaces, norefersub, histinfo Session-Expires: 1800 Min-SE: 90 Remote-Party-ID: <sip:062074996@192.168.1.13>;party=calling;privacy=off;screen=no x-glocom-id: 1652644972.5.200101 Max-Forwards: 70 User-Agent: Asterisk Content-Type: application/sdp Content-Length: 306