Freepbx 13.0.197.31 / Asterisk 13.19.1
I’ve used a CHAN_SIP Trunk config for years successfully, until my SIP trunk provider asked me to change my config so they could move me to their updated server. They are complaining about Asterisk resolving the URL in the Register String. To illustrate, this is my register string format:
Freepbx/Asterisk is resolving ‘gatewayserver.com’ to an IP address, which I can see in Reports/Asterisk Info/Peers. Registration is failing they say, because that resolved IP is not the address they want to direct the connection to for registration, They want Freepbx to NOT resolve he URL ‘gatewayserver.com’ and allow the ‘gatewayserver.com’ string sent as a unresolved URL, so the gateway server can direct the connection to the correct IP address of their registration server. How would I do this?
Try to switch to PJSIP and explicitly set an outbound proxy. On the other hand, handing over a resolvable name and demanding not to resolve it, sounds weird.
Trying PJSIP thanks. I thought it was weird as well, but the carrier says it’s common - for security - they use a Session Border Controller that redirects to the correct registration server.
I don’t have a fpbx box with this option, but in the end the PJSIP registration string should look something like this: outbound_proxy=sip:sip.telecomedians.net\;lr .
You can check the current settings in the Asterisk console with: pjsip show registration <that registration> .
I guess in FreePBX you define the trunk with this option, so you would enter sip:sip.telecomedians.net\;lr in the Connectivity/Trunks/pjsip Settings/Advanced/Outbound Proxy edit field.
What went wrong with the chan_sip register string I posted?
For pjsip, if you have trouble with Outbound Proxy set to sip:sip.telecomedians.net\;lr
try sip:sip.telecomedians.net\;lr\;hide
If you still have trouble, paste a SIP trace of a registration attempt and the resulting response(s) at pastebin.freepbx.org and post the link here.
At the Asterisk command prompt type pjsip set logger on
or sip set debug on
according to the driver you are using, wait for registration to be attempted then paste the relevant section of the Asterisk log.
As I explained, for Chan_SIP, the carrier does not allow an IP address (see original post)
In trying to get a new PJSIP trunk setup, pjsip commands like ‘pjsip set logger on’ are not workng.
Responds with ‘No such command ‘pjsip set logger on’’
I can set ‘sip set debug on’
I am getting:
WARNING: channel.c: No channel type registered for ‘PJSIP’
WARNING: app_dial.c: Unable to create channel of type ‘PJSIP’ (cause 66 - Channel not implemented)
(because it is not registering?)
This is my first attempt at PJSIP - I’ve always been successful with CHAN_SIP - I’m thinking PJSIP may not be setup correctly?
I’ve tried both suffixes in the outbound proxy setting: sip:sip.telecomedians.net\;lr sip:sip.telecomedians.net\;lr\;hide
Since pjsip aren’t working, I set verbose to 5 and set ‘sip set debug on’
tailing /var/log/asterisk/full | grep 5555555555 (user name) I don’t ever see a registration attempt
But with a Register String of 5555555555:[email protected]@1.2.3.4/5555555555
The value 1.2.3.4 should not appear in the SIP packet at all – it is simply the address to which the packet is sent.
FreePBX 13 has minimal support for pjsip; is it feasible to upgrade to 15 or 16, preferably by installing the Distro?
Possibly the retry interval is longer than you waited, or Asterisk gave up because of a ‘fatal’ error. Unfortunately, restart or reload cancels sip debug. An easy way to see the ‘first’ registration is starting sngrep, then restart Asterisk while sngrep is running. The Asterisk log should have info about the failed registration, while sngrep should show the SIP transactions. If you are new to sngrep but familiar with tcpdump, use that instead (save capture to file, move it to your workstation and examine it with Wireshark).
Hi Stewart: OK - Upgraded to FPBX 16. Set up a new PJSIP test trunk.
The carrier is saying “Authentication looks correct, but we would like to see sip:bwas.voice.onvoy.net:5077 in the Request URI line”.
Here’s a screenshot of the PJSIP Advanced GUI page:
Outbound Proxy sip:xxx.xxx.xxx.xxx:5077
User = Phone No
Contact User nnnnnnnnnn
From Domain bwas.voice.onvoy.net
From User nnnnnnnnnn
Client URI sip:[email protected]:5077
Server URI sip:bwas.voice.onvoy.net:5077\;lr\;hide
The suffix: \;lr\;hide does hide the Route: header (they like that)
They get the Request URI as Server URI sip:yyy.yyy.yyy.yyy:5077
I’d like to see a sample of a valid REGISTER request (with usernames, phone numbers and any other personal data redacted), or documentation from the carrier of their requirements, or a sample working configuration for another device or PBX.
If you want to keep taking potshots at the issue, try Outbound Proxy: sip:1.2.3.4:5077\;lr\;hide
or Outbound Proxy: sip:1.2.3.4:5077\;lr
(replace 1.2.3.4 with actual IP address where you should send the request)
But IMO it would be much better to have a working example that we could emulate.
The carrier gets the Request URI as an IP address: sip:yyy.yyy.yyy.yyy:5077. They need the uri in text format.
So it appears what is needed is to not resolve 'bwas.voice.onvoy.net’ to an IP address from the FPBX / PJSIP Trunk / Server URI field. They tell me this is a common thing with other carriers SIP registrations.
Here’s the log with ‘pjsip set logger on’
<— Received SIP response (409 bytes) from UDP:xxx.xxx.xxx.xxx:5077 —>
SIP/2.0 403 Authentication Failure
Via: SIP/2.0/UDP yyy.yyy.yyy.yyy:5077;received=yyy.yyy.yyy.yyy;branch=z9hG4bKPj1685c638-3d92-4481-b6a0-9d0a23e75a91;rport=5077
From: sip:[email protected];tag=ebb1535a-dee6-439f-a6ce-1b20702115ad
To: sip:[email protected];tag=1546144102-1643661599590
Call-ID: d5c244c8-881f-4c86-9a50-860cf43ef224
CSeq: 7005 REGISTER
Content-Length: 0
[2022-01-31 15:39:59] WARNING[10558]: res_pjsip_outbound_registration.c:1047 handle_registration_response: 403 Forbidden fatal response received from ‘sip:bwas.voice.onvoy.net:5077;lr;hide’ on registration attempt to ‘sip:[email protected]:5077’, retrying in ‘30’ seconds
