1. Bicom Systems
  2. Solution home
  3. PBXware
  4. HOWTOs

General:: HOWTO Multiuser Extension - 'IP Auth' method

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