407 Authentication on IP based sip trunk

[alexko]

I have set up a sip trunk and at Type of Authentication I have choose Do not require - IP based.
Underneath I have filled the username and password and not enable the 3 way authentication.

I have fill out the username and password because making an outbound call 3cx is challenged and needs these credentials to successfully make the call.
When I am trying to making an inbound call 3cx challenges the invite from the provider with a 407 message but the provider doesn't support something like, it sends an ACK response but the call stays there not ringing inside.

Why the 3cx challenges for a username/password when it shouldn't because of the Type of Authentication setting?
Also is there a way to fix this issue?

 

[YiannisH_3CX]

Hello @alexko

Please note that the PBX challenges the Invite because there is an source identification issue with your trunk. That can be caused because your either have multiple trunks with the same DIDs or because the number sent by the provider does not match the DID as they are set in your PBX.
Check the Activity log of the PBX for the incoming Invite from your provider and see the number format they are using to send the number to your system. Then adjust your DIDs to match that format.
Alternatively try to use the * in front of your numbers to let the PBX know that you need it to match only the numbers after the *.

For example if your DID is 0123456789 they setting it as *456789. Make sure that you DID is at least 6 digits long

 

[YiannisH_3CX]

Also if you are using a provider that is not supported you need to know from which SIP field you need the system to read the number from and you may need wireshark to determine that.
That is why we always recommend using a supported provider, as the settings are already pre-configured in the provided template so no guessing work is required.

 

[alexko]

The provider is not supported, I have already used wireshark and specified the exact headers that deliver the called number and the caller's number/name but the problem occurs again.

The DID value of the SIP trunk is the same value that the original invite has but I have tried also your suggestions but nothing works.

I have only one SIP trunk with this provider.

Finally I am using Call Source Identification. I have the following values in the two fields,
To: User Part (this is where the dialed number is delivered from the provider)
"Line Number" external number of line (I am guessing this is the value marked as DID through out the 3cx web interface)

Any suggestions are welcomed.

 

[YiannisH_3CX]

Finally I am using Call Source Identification. I have the following values in the two fields,
To: User Part (this is where the dialed number is delivered from the provider)
"Line Number" external number of line (I am guessing this is the value marked as DID through out the 3cx web interface)

Source identification value should be something constant that is always the same during an Invite. By using To: User part and line number means that if a different DID is called then source identification will fail.
Search for a constant in the Invite like the IP of the provider where the Invite originates or a User Agent if a unique user agent exists.
Finally check your inbound parameters and see if the sip field of the "CalledNum" matches the field the provider sends the number to.

 

[alexko]

CalledNum uses the To User part which is where the provider delivers the called number as I mentioned earlier.
I changed the source identification to match the ip received on the to header which will be in all cases the same but nothing works.

I have also two sip trunk to an isdn gateway and an pots gateway.
The isdn gateway uses inbound authentication, maybe 3cx confuses this trunk with the one that the calls are received on and keeps asking for a password.
All three trunks have different ips as resistrar/server/gateway ip.

 

[YiannisH_3CX]

The PBX will only confuse the trunks only if the same DIDs are in multiple trunks. If that is the case then you need to make sure that each trunk has unique DID's.

If the source ID matches and the DIDs match the incoming numbers then i see no reason why this would fail. Unfortunately since the trunk is not supported we cannot really know how it works so the advice we can give is limited.

 

[alexko]

I had a inbound rule and a DID on one of the trunks that had as target the * symbol.
I removed but I keep having problem.