I am currently doing some testing with a PJSIP trunk on FreePBX 13/Asterisk 13. The connection is against a SIP provider. I have also configured the server of this provider in another Asterisk where I keep a trunk using chan_sip and in this case I do not lose connectivity. I’m not sure why it happens with PJSIP.
The messages I see on the Asterisk CLI are the following:
[2016-08-06 13:08:01] WARNING[32331]: res_pjsip_outbound_registration.c:761 schedule_retry: No response received from 'sip:sip01.xxxxxxxxxx.com:5060' on registration attempt to 'sip:[email protected]:5060', retrying in '60'
[2016-08-06 13:09:33] WARNING[32331]: res_pjsip_outbound_registration.c:761 schedule_retry: No response received from 'sip:sip01.xxxxxxxxxx.com:5060' on registration attempt to 'sip:[email protected]:5060', retrying in '60'
[2016-08-06 13:11:05] WARNING[32331]: res_pjsip_outbound_registration.c:761 schedule_retry: No response received from 'sip:sip01.xxxxxxxxxx.com:5060' on registration attempt to 'sip:[email protected]:5060', retrying in '60'
[2016-08-06 13:12:37] WARNING[32331]: res_pjsip_outbound_registration.c:761 schedule_retry: No response received from 'sip:sip01.xxxxxxxxxx.com:5060' on registration attempt to 'sip:[email protected]:5060', retrying in '60'
[2016-08-06 13:14:09] WARNING[32331]: res_pjsip_outbound_registration.c:761 schedule_retry: No response received from 'sip:sip01.xxxxxxxxxx.com:5060' on registration attempt to 'sip:[email protected]:5060', retrying in '60'
[2016-08-06 13:15:41] WARNING[32331]: res_pjsip_outbound_registration.c:761 schedule_retry: No response received from 'sip:sip01.xxxxxxxxxx.com:5060' on registration attempt to 'sip:[email protected]:5060', retrying in '60'
[2016-08-06 13:17:13] WARNING[32331]: res_pjsip_outbound_registration.c:761 schedule_retry: No response received from 'sip:sip01.xxxxxxxxxx.com:5060' on registration attempt to 'sip:[email protected]:5060', retrying in '60'
[2016-08-06 13:18:45] WARNING[32331]: res_pjsip_outbound_registration.c:761 schedule_retry: No response received from 'sip:sip01.xxxxxxxxxx.com:5060' on registration attempt to 'sip:[email protected]:5060', retrying in '60'
[2016-08-06 13:20:17] WARNING[32331]: res_pjsip_outbound_registration.c:761 schedule_retry: No response received from 'sip:sip01.xxxxxxxxxx.com:5060' on registration attempt to 'sip:[email protected]:5060', retrying in '60'
[2016-08-06 13:21:49] WARNING[32331]: res_pjsip_outbound_registration.c:761 schedule_retry: No response received from 'sip:sip01.xxxxxxxxxx.com:5060' on registration attempt to 'sip:[email protected]:5060', retrying in '60'
[2016-08-06 13:23:21] WARNING[32331]: res_pjsip_outbound_registration.c:849 handle_registration_response: Maximum retries reached when attempting outbound registration to 'sip:sip01.xxxxxxxxxx.com:5060' with client 'sip:[email protected]:5060', stopping registration attempt
Any clues where about might be the problem? The server seems to be resolving correctly by making a test using dig
As you can see in the logs of the previous message, the connection is against the port 5060 of the SIP server for this provider. At first the connection is established, but after some time it was lost.
This catches my attention because I have another Asterisk having a trunk against the same server and it is strange that when comparing the same time window, the trunk with chan_sip has no problem but the trunk with chan_pjsip loses connection. The server using chan_sip is running on a KVM virtual machine. The FreePBX/Asterisk using chan_pjsip with this problem is running on a LXC container. I’m not sure if this might have to do with the problem.
Now the connection has been reestablished again without having made any changes. But instability worries me.
Another thing I’m not clear is why when seeing the graph on the dashboard of FreePBX, the trunk is shown in online state. But on the CLI I get a status of “Rejected”.
I suggest to enable pjsip logs with “pjsip set logger on” in Asterisk CLI, and then see when your server send registration request, what reply it receives?!
Right now I have the trunk down but actually it seems to be a problem with the provider. Chan_pjsip apparently tried to connect several times and then stopped at a maximum of 10 attempts.
[2016-08-14 12:04:22] WARNING[910]: res_pjsip_outbound_registration.c:849 handle_registration_response: Maximum retries reached when attempting outbound registration to 'sip:sip01.xxxxx.com:5060' with client 'sip:[email protected]:5060', stopping registration attempt
I see that this is a set on the trunk itself rather than the general SIP configuration: pjsip Settings tab -> Advanced tab -> Max Retries.
Is there any way to set the amount of attempts to infinity? In the Settings -> Asterisk SIP Settings menu of the general SIP configuration, chan SIP have the option: Registration Settings -> Registration Attempts, where a value of 0 means keep trying forever. But I have not seen anything like that in the Chan PJSIP Settings tab, and <trunk_name> -> pjsip Settings -> Advanced -> Max Retries does not specify whether a value of zero leads to the attempts are forever.
I tried to put this to zero, but seems to generate an error when applying the configuration and immediately after that error again shows the message about reached the maximum number of attempts:
[2016-08-14 12:13:47] WARNING[909]: pjproject:0 <?>: tsx0x7f90c4000 .Error sending Request msg OPTIONS/cseq=55797 (tdta0x7f90c4029060): Transport not available for use (PJSIP_ETPNOTAVAIL)
[2016-08-14 12:13:47] WARNING[909]: pjproject:0 <?>: tsx0x7f90c4000 .Transport error, terminating transaction. Err=171065 (Transport not available for use (PJSIP_ETPNOTAVAIL))
[2016-08-14 12:14:28] WARNING[910]: res_pjsip_outbound_registration.c:849 handle_registration_response: Maximum retries reached when attempting outbound registration to 'sip:sip01.xxxxx.com:5060' with client 'sip:[email protected]:5060', stopping registration attempt
Now I see such messages in the test LXC container with Asterisk 13 / FreePBX 13 (PJSIP trunk):
-- Contact Provider_Trunk1/sip:[email protected]:5060 is now Unreachable. RTT: 0.000 msec
== Endpoint Provider_Trunk1 is now Unreachable
-- Contact Provider_Trunk1/sip:[email protected]:5060 is now Reachable. RTT: 57.200 msec
== Endpoint Provider_Trunk1 is now Reachable
-- Contact Provider_Trunk1/sip:[email protected]:5060 is now Unreachable. RTT: 0.000 msec
== Endpoint Provider_Trunk1 is now Unreachable
-- Contact Provider_Trunk1/sip:[email protected]:5060 is now Reachable. RTT: 58.098 msec
== Endpoint Provider_Trunk1 is now Reachable
-- Contact Provider_Trunk1/sip:[email protected]:5060 is now Unreachable. RTT: 0.000 msec
== Endpoint Provider_Trunk1 is now Unreachable
-- Contact Provider_Trunk1/sip:[email protected]:5060 is now Reachable. RTT: 56.288 msec
== Endpoint Provider_Trunk1 is now Reachable
-- Contact Provider_Trunk1/sip:[email protected]:5060 is now Unreachable. RTT: 0.000 msec
== Endpoint Provider_Trunk1 is now Unreachable
-- Contact Provider_Trunk1/sip:[email protected]:5060 is now Reachable. RTT: 740.379 msec
== Endpoint Provider_Trunk1 is now Reachable
-- Contact Provider_Trunk1/sip:[email protected]:5060 is now Unreachable. RTT: 0.000 msec
== Endpoint Provider_Trunk1 is now Unreachable
-- Contact Provider_Trunk1/sip:[email protected]:5060 is now Reachable. RTT: 63.928 msec
== Endpoint Provider_Trunk1 is now Reachable
-- Contact Provider_Trunk1/sip:[email protected]:5060 is now Unreachable. RTT: 0.000 msec
== Endpoint Provider_Trunk1 is now Unreachable
-- Contact Provider_Trunk1/sip:[email protected]:5060 is now Reachable. RTT: 57.345 msec
== Endpoint Provider_Trunk1 is now Reachable
This caught my attention because I have a KVM virtual machine with a trunk using chan_sip against the same SIP provider and I’m not observing these disconnections (in this case I’m using Asterisk 11).
hi, i was wondering if you ever got any more info on this problem. i am starting to see similar issues using pjsip with phones (not trunks) and i am seeing this error when i apply config changes
[2017-07-15 11:26:35] WARNING[12778]: pjproject:0 <?>: tsx0x7fe538026888 .Error sending Request msg OPTIONS/cseq=54594 (tdta0x7fe55529e9c8): Transport not available for use (PJSIP_ETPNOTAVAIL)
[2017-07-15 11:26:35] WARNING[12778]: pjproject:0 <?>: tsx0x7fe538026888 .Transport error, terminating transaction. Err=171065 (Transport not available for use (PJSIP_ETPNOTAVAIL))
It’s been a while and I am currently having this problem. It started out as described at the beginning of this chain of messages. I was able to minimize the problem by going into connectivity/trunks//pjsip settings/advanced and setting permanent auth rejection to “NO” and setting Max Retries to “1000000” which seems to be the max value. I still lose the trunk occasionally, and I see multiple errors in my log:
“res_pjsip_outbound_registration.c: Temporal response ‘401’ received from ‘sip::5060’ on registration attempt to ‘sip:[email protected]:5060’, retrying in ‘60’”.
I have also turned on “pjsip set logger on”, but haven’t had another Temporal error in the last couple of hours and haven’t had the occasional total failure where it goes down permanently which I normally just reboot the system to resolve. I can see the time that it failed by going to the log at my provider, which helps. And I can see “Temporal” errors in the log.
I’ve heard that I can resolve this by switching back to chansip rather than pjsip. but thought I’d play with it, since it’s a small non-critical system.
There are some “cats and dogs” situations where doing the easy thing (switching back to Chan-SIP for your trunk) is actually the right answer. This could easily be one of them.
While Chan-SIP and PJ-SIP “should be” the same in the transport, they do have some subtle differences that make it easier in the short term to go back to Chan-SIP and troubleshoot from there.
OK so first, you’re always going to get 401 replies when you attempt to register. It’s part of the auth process. So it doesn’t matter if it’s Chan_SIP or Chan_PJSIP, you’re still going to see those.
You’re going to send a REGISTER, which will have ZERO auth details in it, they are going to send a 401 will the auth challenge, you’re going to send back another REGISTER with auth details.
At this point if the auth is right, you’ll get back a 200 OK. If not you’ll get back either another 401, triggering the process again or a 403 which means they don’t want you to try anymore. So now you need to determine what is actually happening in this process. You should be talking to your provider as they will have logs.
