I’m trying for two days to link my GoIP to my SIP server and can’t manage to find the right settings. So far I’ve managed to get it working by setting up a PJSIP trunk following the last part of this thread:
However later I realized that my trunk loses connectivity since these warnings kept popping up every minute or so.
res_pjsip_outbound_registration.c:841 schedule_retry: No response received from ‘sip:192.168.1.35:5060’ on registration attempt to ‘sip:[email protected]:5060’, retrying in '60
So I read a bit more and in the thread below was the recommendation to switch to a SIP trunk which I did.
insecure=very doesn’t appear to have been supported in any version of Asterisk later than 1.4! Even then, you would have got a deprecated warning. For current versions, you will get an undefined value warning and no options would be set. (The insecure=invite part would have had no effect, as there is no secret set. If it had worked, there would have been no point in defining a secret, for the registration.)
Your PJSIP error is because you have misconfigured it to attempt outbound registrations.
At the moment, I can’t think of any other cause that an incorrect password, for the inbound registration to fail, but the full SIP trace may give a clue.
You shouldn’t need separate incoming and outgoing sections, in this case.
The posting you took the sip.conf settings from, includes a solution for chan_pjsip.
I went back and changed the trunk back to PJSIP, configured it with the previous settings because I wanted to see if that warning will still be there after changing the authentication method or removing authentication completely. To my surprise the was no warning at all anymore so it looks like the GoIP is able to register without issues.
Having success with my already existing pjsip trunk I created a new one and wanted to connect it to another pjsip trunk located on another FreePBX unit. The difference is that my first pbx is behind a nat whereas the second one has a public IP. It looks like I haven’t configured something correctly because the errors that I’m getting are these:
PBX1:
WARNING[4646]: res_pjsip_outbound_authenticator_digest.c:551 digest_create_request_with_auth: Host: ‘xxxxy:5060’: Authentication credentials not accepted by server.
PBX2:
NOTICE[28732]: res_pjsip/pjsip_distributor.c:676 log_failed_request: Request ‘OPTIONS’ from ‘sip:[email protected]’ failed for ‘yyyy:5060’ (callid: 42f56ad8-e568-4292-bbbc-ad2b411996e6) - Failed to authenticate
“Both” is, in practice, a rather unusual setting, as it requires the peer to support both, which is unusual, if the peer isn’t Asterisk. However, the notice for the PBX2 case should not be a problem, except for consuming lots of log space. I suspect that there might be a problem for requests that need to produce more than just any response.
I’m not completely sure which direction the message relates to, but I think it might be that the GoIP has rejected the authentication, because it only supports FreePBX incoming authentication
For the PBX1 case, you are trying to register with the GoIP, which seems something it is unlikely to support, and is inconsistent with your original subject.
my impression is that it can only send authentication and can only send registrations, although the preferred option here would probably be the Trunk Gateway Mode, using IP authentication. However, not authenticating outbound to GSM seems worrying, as that is the direction that attackers will try to use.
Actually the GoIP is working fine now. I have no problem with it anymore as warning “res_pjsip_outbound_registration.c:841 schedule_retry: No response received from ‘sip:192.168.1.35:5060’ on registration attempt to ‘sip:[email protected]:5060’, retrying in '60” is completely gone after I removed the sip trunk and went back to pjsip.
The issue that I’m describing is related to two PBX’s that I’m trying to link together via pjsip trunks. Actually I’m not sure if I need to open another thread for this problem since the problem isn’t related (at least directly) to the GoIP gateway.
Either ask to have the topic split, or change the subject. Some people generate lots of subjects for the same problem, but, on balance, this is a case where a new subject won’t lead to loss of contextual information.
If possible, you should have authentication both on both and registration none on both and supply the address of the of the respective other one in each ones configuration. If not possible, please explain the constraints of your system that require you to use registration.
Many may suggest that you don’t need authentication with IP based matching, and some would argue, that if you have authentication, you should use different secrets in each direction, although I’m not sure that the GUI supports the latter.
The subject was changed, I guess it’s the fastest way.
Actually since the second PBX which accepts registrations is reachable via a public address I would try to keep it safe as much as possible. The first PBX is behind a NAT and it’s not directly exposed.
The problem with this scenario is that the first PBX doesn’t have a static IP and I can’t use DDNS for it. It may not even be possible to link the PBX’s like this but I wanted to know for sure before I try something else as it’s the most direct way.
Actually the thing that led me to try this option was a post by @lgaetz in this thread
Configure the PBX with the dynamic IP to register to the other, and config the static IP to accept the registration. Exactly the same as if it’s a phone.
It looks like the OPTIONS is being authenticated as outgoing, when incoming is expected. However, the error should not matter, as the forbidden response still confirms that connectivity is there.
There may be other ways, but you are probably best to make the trunk name the same at both ends.
I believe VPNs are a better solution in such cases.
There may be other ways, but you are probably best to make the trunk name the same at both ends.
I’ll try this next. Actually thought about it too.
However, the error should not matter, as the forbidden response still confirms that connectivity is there.
Exactly. I’m able to see the correct IPs logged inside the warning messages and the port is configured to 5060 in line with pjsip settings. Do I need to have some extension defined on the PBX that I’m trying to connect to and try to pass the credentials of that extension instead?
So I’ve set up the same trunk name ‘connect’ at both ends, the authentication is also set to BOTH and the Registration is set to SEND on the PBX with dynamic IP and RECEIVE on the PBX with a static IP.
Now the errors are as follows:
PBX dynamic IP
[2022-07-14 01:13:12] WARNING[9931]: res_pjsip_outbound_registration.c:1047 handle_registration_response: 403 Forbidden fatal response received from ‘sip:xxxx:5060’ on registration attempt to ‘sip:connect@xxxx:5060’, retrying in ‘30’ seconds
PBX static IP
[2022-07-14 01:14:42] WARNING[24225]: res_pjsip_registrar.c:672 register_aor_core: Registration attempt from endpoint ‘connect’ (yyyy:5060) to AOR ‘connect’ will exceed max contacts of 1
That probably means that the IP address or external port number is unstable as well as being dynamic. That’s never going to work well.
It is a relating to the AOR settings. The raw Asterisk settings allow you to replace the contact, if a new registration comes in. I’m not sure if that is supported by teh GUI and using a VPN is likely to be less hassle.
Note that, if you are only initiating calls from PBX1 to PBX2, you don’t need to register at all. Things will still break if things change mid-call.
I can’t find any options to change the number of contacts, or to set them to be automatically replaced, in the user guide in the wiki, but I don’t think that is always complete.
Using VPN is not so straightforward for my setup as I’m using a FreePBX on a raspberry Pi (RasPBX) and I can’t use the built-in VPN server as System Admin module can’t be installed on this architecture. So I need to use another client. Another complication is that the PBX will be located in a mobile network and VPN’s are known to be unstable in this kind of environment.
It is a relating to the AOR settings. The raw Asterisk settings allow you to replace the contact, if a new registration comes in. I’m not sure if that is supported by teh GUI and using a VPN is likely to be less hassle.
Yes, I saw this post you wrote earlier this year and I couldn’t find it to be supported by the GUI.
Note that, if you are only initiating calls from PBX1 to PBX2, you don’t need to register at all. Things will still break if things change mid-call.
I need the PBXs to pass calls in both directions.
Is there an extension missing in my configuration? Would the trunks need also some extensions to be defined in order to help the registration process? I remember that somebody proposed this in a post, it wasn’t the recommended way to do it.
FreePBX trunks and extensions are completely disjoint.
Any side that can make chargeable calls, or commit fraud, by making calls through the other side should be authenticating itself in some way.
To expand on your latest problem. It seems that PBX1 has registered itself with two different contact addresses. That may be an issue with the router thinking there are two different natted processes behind it. SIP has had NAT support bolted on and is still very uncomfortable with it, which is why a VPN is generally the best solution when you control both ends.
You probably want to do full pjsip set logger on traces on both sides, to see exactly what is happening, make sure that public addresses are being used in the correct places, and to check for any mangling by the router.
From domain is normally ignored for authentication, and matching.
From user isn’t affected by NAT. You will probably need to set it because it will be needed to match the call to an endpoint, but not for NAT reasons. (chan_sip matched against the contact address, after a registration, but chan_pjsip does not do this, so, by default, needs the From user to match against.)
For other purposes, setting the public signalling and media IDs and correctly setting the local networks should ensure that the request has addresses that are public. You can check this by capturing the dialogue on the non-NATted machine.
