FAQ
This section contains some of the most popular questions regarding SIP Trunks and how they work, along with the answer. Each answer also includes which document contains the answer.
- “Why is 3CX sending the SIP messages over TCP and not UDP?”
Most likely this is happening because the FQDN you have entered as “Registrar” and/or “Outbound Proxy” has an NAPTR that has the highest priority set to use TCP, and/or a TCP SRV entry. 3CX sees this and uses TCP. This is explained in section “DNS Resolution”.
- “My provider requires me to register to IP 2.2.2.2, but use ‘sip.contoso.com’ as the SIP Realm”
This can be done by setting the Outbound Proxy to 2.2.2.2 and the Registrar to ‘sip.contoso.com’. This is explained in section “Registration / Authentication”.
- “My provider requires the REGISTER message to contain both the main trunk number AND a username and password. How can I do that as 3CX has only one ‘Authentication ID’ field?”
This would require you to enable 3-way authentication. Then in 3CX you would need to enter your main trunk number as the ‘Authentication ID’, your password as ‘Authentication Password’ and your username as ‘3-way authentication password’. This is explained in section “Registration / Authentication”.
- “I have set the registration expiry in 3CX to 600 seconds, but I see 3CX re-registering every 120 seconds. Why?”
3CX may ‘suggest’ 600 seconds in the REGISTER message it initially sends, but if the provider sends a different ‘expires’ value in the 200 OK, 3CX will respect and use that value.
- “In the ‘Via’ header I need to send my Public IP instead of my local one. How can this be done?”
There is an option in the SIP Trunk Settings → ‘Options’ tab, that allows you to set whichever IP you want in the ‘Via’ header. This option is disabled by default.
- “Incoming calls to my 3CX immediately get rejected after I added some new DIDs to my SIP Trunk. Why?”
This may have to do with incorrect Source Identification options in 3CX. If the provider does not return the ‘rinstance’ parameter and “loose” Source Identification has not been set, it could be that you have added the same DID twice. In this case 3CX rejects the call. This is explained in section “Inbound Calls”.
- “I have checked and my provider, on incoming calls, sends the ‘rinstance’ parameter and value 3CX used to register with. What do I have to do for 3CX to use it?”
Nothing. 3CX automatically looks for the ‘rinstance’ parameter in incoming INVITES and if found, tries to match it with its existing trunks. This is explained in section “Inbound Calls”.
- “Incoming Calls, instead of being routed to the destination I have set in the Inbound Rules, are being sent to the Destination I have set in the SIP Trunk settings (catch all).”
It could be that you have inserted the DID numbers in the incorrect format. First you should check the ‘Inbound Parameters’ tab and check where you have set 3CX to read the ‘CalledNum’ from. Then, you should check the INVITE message the provider sends and check if the field you are reading the ‘CalledNum’ from, contains the number in the same format as you have entered your DIDs in 3CX. If there is a mismatch, then that is the reason.
- “My provider does a number lookup on incoming calls (CNAM), but when an incoming call rings an extension, I don’t see this.”
Usually the CNAM is sent in the ‘From : Display Name’. Check in the SIP Trunk Settings → Inbound Parameters if you have set the ‘CallerName’ to be read from the field you provider is sending the CNAM in.
- “When an incoming call is answered, 3CX is responding with port 0 in the SDP. Why is this?”
This happens when there is no common codec between what you have set in the 3CX SIP Trunk settings and the incoming INVITE from the provider.
Last Updated
This document was last updated on 25 July 2024
版权所有 三思客软件（深圳）有限公司