SIP Trunk Registration Failed - 405 Method Not Allowed

[Andyshawn]

Hi,

I am trying to setup a SIP trunk between a 3CX PBX and a SIP Trunk provider, but all my registration attempts failed with error message "405 Method Not Allowed ". The provider is recommending that I use an SBC(Cisco Cube) to terminate the SIP Trunk connection, but I wanted to know if the 3CX PBX could terminate this SIP trunk? I'm running version 15.5.

I contacted support and the response they provided was that "Please note Registration to the peer is not supported. We handle calls using only digest authentication", but I am not too sure how to proceed.

 

[Andyshawn]

This was taken from the Interface Specification Documentation that was provided to me:

"Authentication
The CPE/PBX must authenticate at each outbound call (INVITE request), through a digest challenge {38, 39, 126}. The username and password required for any given call depends on the trunk group selected to place the call {41}. Note that to avoid unnecessary challenges, the CPE/PBX can include its authentication credentials using the current “nonce” value in each request sent to us{100}. A given “nonce” value can only be reused within a certain time period, across dialogs"


I just need some help with figuring out if 3CX supports this?

 

[leejor]

What provider are you attempting to connect with? Someone else may have some experience with them and some settings.

 

[cobaltit]

So there's not really any undocumented knobs in 3CX for this scenario. Everything you can adjust is there on the trunk configuration. Either your provider isn't SIP standard compliant or there's some configuration issue going on. You can see if your provider will do IP authentication instead.

 

[Andyshawn]

What provider are you attempting to connect with? Someone else may have some experience with them and some settings.

I'm trying to do Interopt testing with Bell Canada.

 

[Andyshawn]

Here is some more information based on the Authentication requirements that i listed above.

38. SIP Application Servers MUST support both Option 1 and Option 2 in order to ensure interoperability with all PBX systems.

39. When processing an INVITE request from an unauthenticated PBX, the SIP Application Server MUST challenge the message, only accepting authentication credentials that are valid within its realm.

126. Authentication of the Enterprise by the Service Provider can be performed in one of two ways. PBX systems MUST implement Option 1 and MAY implement Option 2

I'm not getting much help from the service provider and they just want to sell me a an SBC along with professional services, but I want to see if I can get the 3CX PBX can successfully register a SIP Trunk directly without the need for a Cisco CUBE acting as an SBC.

 

[YiannisH_3CX]

"Authentication
The CPE/PBX must authenticate at each outbound call (INVITE request), through a digest challenge {38, 39, 126}. The username and password required for any given call depends on the trunk group selected to place the call {41}. Note that to avoid unnecessary challenges, the CPE/PBX can include its authentication credentials using the current “nonce” value in each request sent to us{100}. A given “nonce” value can only be reused within a certain time period, across dialogs"

If understand this correctly the provider wants the PBX to send the Initial Invite with the authentication details included. If that is the case then 3CX does not support this as it must receive a challenge to be able to send a re-invite with the authentication details.

 

[Andyshawn]

If understand this correctly the provider wants the PBX to send the Initial Invite with the authentication details included. If that is the case then 3CX does not support this as it must receive a challenge to be able to send a re-invite with the authentication details.

Thanks for providing that info YiannisH.

I got a response from the provider and they said "You will receive the challenge when sending the invite."

I'm still not too sure what this all means. Does this mean that the 3CX PBX will be able to successfully establish a SIP Trunk, because I am still getting that 405 error message above.

 

[YiannisH_3CX]

I am not sure what is needed to be able to successfully register the sip trunk but you could ask the provider what is the do not like with the register message of the PBX.
I would recommend using a supported provider which has been tested by us and we can ensure compatibility. https://www.3cx.com/partners/sip-trunks/

 

[leejor]

I 'm be surprised that a large company such as Bell Canada, is handling SIP trunking in a manner that is not consistent with the majority of other SIP providers.

 

[Andyshawn]

Well, I was hoping that someone of the forum or someone from 3CX would be able to help, but no luck so far, thanks anyways. Bell is not really providing much help and are insisting that I use an SBC, but I really don't understand why I must use an SBC(Cisco Cube).

So here is my other question then. Does the 3CX PBX have built in SBC functionality? Is the 3CX PBX capable of performing like function such as the Cisco CUBE?

I have been setting up SIP Trunks for over 8 years with countless providers and I have never had this issue before, so i'm a bit lost.

 

[cobaltit]

3CX has no built-in SBC functionality, and you don't need SBC functionality. They have no incentive to help you because they'd rather sell you the CUBE. I'm sure you could get it to work with assistance from them or enough trial and error. You could also try something like a Patton SBC or Edgewater between 3CX and Bell but if they don't want to work with you I don't see any reason to give them your business. You could also see if you can find guides for another PBX (like Asterisk) to work directly with Bell, capture some packets and then compare it with 3CX and turn some knobs there.

 

[Andyshawn]

3CX has no built-in SBC functionality, and you don't need SBC functionality.

Thanks for confirming that information. I'm going to pressure them some more for assistance because I have to get it working. If I was the sole decision maker, we would not be using Bell as the provider, but they are on the short list for this project as this is what the client has requested.