Good day Team.
i need your assistance, first time configuring a freePBX.
so I have configured a sip trunk as per below:
so the issue is when the upstream service provider receives the registration request the contact on the request is Contact:sip:[email protected]:26213 instead of Contact:sip:[email protected]:5060.
where in freePBX can I change this of fix it ?
The 26213 will reflect the port number from you sent the request. You would only get that if you had explicitly configured that, or if a router is translating the port number. Although it is common advice not to use anything similar to 5060, to reduce toll fraud attempts, 26213 is so strange that, is unlikely that you chose this value, and I, therefore, think that problem lies with your router.
If the ITSP cares about the user part of the Contact header, their SIP implementation is broken. They should return it as is. It is configurable in Asterisk, and I’m pretty sure it is configurable in FreePBX, but you need to make a corresponding change in the dialplan, as the important requirement is that it match what is in the dialplan, not anything that the ITSP knows about you.
Firstly you shouldn’t be using chan_sip for new installations.
You can set the port number using
NB this is in the general section.
And you set the user part as detailed here:
Changing the first, if the router is actually changing the port (which you should stop it doing) will result in incoming calls not arriving and may result in outgoing calls dropping after varying amounts of time. In any case, it should only be manipulated through the GUI when using FreePBX.
Changing the latter, without a coordinated dialplan change may result in incoming calls failing saying that the extension wasn’t found, or change FreePBXes DID identification. Again it is something that should be changed using FreePBX, not Asterisk.
Then fix your register string. 1) type=peer means no REGISTER. You’re peering via IP. 2) You’re still sending a REGISTER which is dealt with in the REGISTER string, you’re missing the /contact portion of it and that is why your REGISTER location is s vs the actual user. You’re not specifying the user.
Also, you should be using Chan_PJSIP for this stuff.
; Asterisk can register as a SIP user agent to a SIP proxy (provider)
; Format for the register statement is:
; register => [peer?][transport://]user[@domain][:secret[:authuser]]@host[:port][/extension][~expiry]
type=peer has no effect on registration. It means don’t match the other party by from user name on incoming requests other than register. It has no impact at all on incoming registers, which always match on the section name, and it is irrelevant for outgoing registers which are controlled by the register => line.
Most trunks and extensions should be type=peer. The only exception is where the same source IP address can be associated with multiple end point. Most suggested configurations are poor in this respect.
I’m going to be honest, having this discussion in 2021 when Chan_SIP is deprecated, requires extra steps to be installed/compiled in versions 17+ and the fact it gets removed in the next Standard release of 21…is a waste of our time.
As I understand it, this option will have no effect when not using host=dynamic. It is however, possible, that you need fromuser set to the same value, but this won’t affect the registration step.
I agree that first time users of FreePBX should only use chan_pjsip, even if the ITSP claims not to support it. I would advise against mechanically translating provider provided chan_sip configurations.
The weird port number may be the result of trying to use chan_sip on FreePBX with both drivers enabled. It will use 5060 for chan_pjsip, and a different port for chan_sip, although still a lowish numbered one. The router may be being very clever, recognizing that the port isn’t being forwarded, and creating a dynamic port number and forwarding rule, but also noticing that the content is SIP, so rewriting the SIP headers to match.
Again the fix for that is to disable chan_sip and do a purely chan_pjsip configuration. You should also look to disabling intelligent handling of SIP in the router, as application level gateways reportedly break things more often than they help.