Max_contacts in pjsip trunk

FreePBX Endpoints
1

When creating a pjsip trunk, it does not include the max_contacts value in pjsip.aor.conf.

I’m configuring an goip9 gsm-to-sip gateway. It tries to register to freepbx. But Asterisk rejects the registration with the error:

WARNING[31744]: res_pjsip_registrar.c:1012 registrar_on_rx_request: AOR ‘goip1’ has no configured max_contacts. Endpoint ‘goip1’ unable to register

Any solution?

2

Because max_contacts is about how many contacts can register to the endpoint not how many contacts the outbound register has. That would be a limit imposed by your provider, not the trunk settings.

3

You say you are creating a trunk, but the error message implies to me you are connecting to an extension. They are different - you need to decide which one you are actually doing.

4

I had exactly the same warning when configuring a PJSIP trunk (not an extension) to an FXO Gateway, with Freepbx trying to register (send) on the Gateway. The warning was appearing several times a second!

Everything seemed to work, incoming and outgoing calls, and it looked like Freepbx had registered but it still produced the warning.

In the end, I had to set the trunk up as a Chan_SIP trunk instead, which resolved the error.

There are quite a few cases of this I have seen looking around, it would be good to get a fix, other than manually editing the config files. Since I would rather use PJSIP if I could.

5

Because the PBX does NOT REGISTER TO THE GATEWAY. The GOIP9 is what REGISTERS TO THE PBX. You have this backwards and that is part of your problem.

FXS/GSM gateways like this do not accept registers, they do the registration.

6

I have set up many gateways and never use registration in either direction. Is there an actual use case where registration is required?

2 Likes
7

I’m with you on that. Unless it’s remote, it just peers.

8

Maybe but mine is FXO not FXS and Freepbx shows that it was registered to it. Registration just makes it easier to know when the trunk is down.

9

My cloud PBX has two remote FXO devices; both are behind NAT and on dynamic IPs, so registration is obviously required. However, I recommend it even for local gateways:

  1. It simplifies debugging, e.g. “Does the device show it’s registered?”, “Is the FXO port indicator light solid blue?”, etc.
  2. It’s a simpler setup – you don’t need to hard code the device IP address and port numbers into the PBX.
  3. Outbound call failover e.g. to a SIP trunk is more robust.
  4. For troubleshooting or to replace a failed unit, you can power off the old one and connect the new device using the same credentials, without having to change any PBX settings.
  5. Better info about intermittent problems can be found in the Asterisk logs.

I’m aware of only one downside: After restoration of a LAN failure that caused ‘lost registration’, there is an additional delay of up to two minutes (assuming 120 seconds expiry), before the trunk becomes operational again. However, IMO the vast majority of such failures would also affect endpoints and other trunks, so there would likely be other delays affecting the system.

1 Like
10

OK so let us clear up some misnomers about registrations. When a REGISTER occurs it takes the Contact URI and stores it in a User Location memory. Then the PBX will try to qualify that location based on the Qualify settings. The PBX will keep that location in memory until the Expiry timer is hit or it cannot get replies from the qualify after X attempts.

This is not a real-time active showing. The device could loss connectivity and until it either expires or the PBX considers it a time out, the PBX will show it REGISTERED. So right there this is a false flag because the device is obviously down, it has no connectivity.

So at this point, it doesn’t matter if it’s a Peer or a registered Location. The PBX will attempt to qualify it (as long as that is turned on) and will make it unavailable once it can’t. Or it will drop it when it expires.

This is no way to indicate if the device is 100% up or not since the device can have an Expiry time of an hour and it would take the PBX about 2-3 minutes to consider it dead when qualifying it because it lost connectivity.

11

Okay, having been convinced that a possible use case exists, I have created a PJSIP trunk to accept incoming REGISTER requests with authentication. Testing with core 14.0.28.14, and it works just fine for me:

lorne14-pro*CLI> pjsip show aor test_registration

      Aor:  <Aor..............................................>  <MaxContact>
    Contact:  <Aor/ContactUri............................> <Hash....> <Status> <RTT(ms)..>
==========================================================================================

      Aor:  test_registration                                    1
    Contact:  test_registration/sip:[email protected] 796ec3958c Avail       109.057


 ParameterName        : ParameterValue
 =============================================================
 authenticate_qualify : false
 contact              : sip:[email protected]:5060
 default_expiration   : 3600
 mailboxes            :
 max_contacts         : 1
 maximum_expiration   : 7200
 minimum_expiration   : 60
 outbound_proxy       :
 qualify_frequency    : 60
 qualify_timeout      : 3.000000
 remove_existing      : false
 support_path         : false
 voicemail_extension  :
12

Some of these gateways have an issue with PJSIP, which I believe has been corrected in recent versions, but I’ve not determined robust settings, so I’m still recommending chan_sip for these applications.

The issue arises because on an incoming call to an FXO port, many of these devices including Grandstream HT503 and HT813, Linksys SPA3000 and SPA3102, and Obihai OBi110 and OBi212, can use only the From header to transmit caller ID. So if you want caller ID, endpoint identification by username is out. And if you also want to use the FXS port, identification by IP address is also out. One should be able to identify by auth ID, but I ran into problems and gave up, since chan_sip was a quick fix. I’ll revisit that if a get a chance while in one of the locations with a gateway.

13

How? The gateway doesn’t care that it’s PJSIP or Chan_SIP or Sophia or SIP-B, it’s all SIP. I am interested to know what specific issues PJSIP, a more SIP RFC compliant and style driver, has over Chan_SIP which has very poor SIP RFC compliance compared to PJSIP.

14

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.