Solved SIP Trunk Provider Authentication - Encrypted Password

[carlosmarchi]

Hi Everyone!

I'm having some trouble to get a Generic SIP Trunk working with a brazilian SIP Trunk provider. I know, it would be better to use an official provider, but this one is reliable (I have already used it in the past) and much cheapier than the flagships listed for my country. The provider's name is GTGI (until not long ago, it was the provider for Skype in Brazil, I'm not sure if it still is).

They only require authentication for Outbound (inbound is IP based), but the authorization is failling and they say that the password is being sent 'encrypted' while it should be plain text. I've looked around and haven't found anything related, not even in the advanced parameters. Anyone knows about the SIP Trunk password being sent encrypted or not?

04/23/2020 3:24:08 PM - [CM504005]: Registration failed for: Lc:10000(@GTGi SIP[<sip:[email protected]:0/UDP>]); Cause: Cause: 401 Unauthorized/REGISTER from 45.166.192.15:5060

Thank you,

 

[craigreilly]

Is SRTP checked?
(Not sure if this would do it)

 

[carlosmarchi]

Is SRTP checked?
(Not sure if this would do it)

Nops, it's unchecked. I've also tried checking/unchecking and explicitly selecting UDP for transport.

 

[carlosmarchi]

Hi Everyone!

Just posting an update to see if anyone could have any other ideas. The Provider still insisted that 3CX was sending the password 'encyrpted', now they claim that they have changed the authorization to be based just on IP and that I should pass the calls using a tech prefix, which I have included to be prepend on the outbound rules. But, I'm still getting an unathorized error. Is there anything that could be infered just looking at the log from my side? Maybe some misplaced information that I could adjust at the outbound parameters. Here's a section of my log showing one of the call errors it:

Tech Prefix: 88887*
Proxy: 45.166.192.15
My PBX: 18.229.109.100
Number I'm calling to test: 5519993716767
CID that I've to send: 551940404344
Call format should be Tech Prefix + 55 + 2 digit area code + number
3CX running at AWS
Using Generic SIP Trunk template (also tried with Generic VoIP provider)

04/30/2020 10:05:10 AM - L:9.2[Line:10000>>39887*5519993716767] got Terminated Recv 401/INVITE from 45.166.192.15:5060 tid=05c2ed45f5615c1a Call-ID=pz3tktTwnuLPjiY60Lv6OA..:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 172.31.34.144:5060;rport=5060;received=18.229.109.100;branch=z9hG4bK-524287-1---05c2ed45f5615c1a
To: <sip:88887*[email protected]>;tag=z9hG4bK-524287-1---05c2ed45f5615c1a
From: "551940404344" <sip:[email protected]>;tag=f247ce39
Call-ID: pz3tktTwnuLPjiY60Lv6OA..
CSeq: 2 INVITE
Server: handphone
WWW-Authenticate: Digest realm="handphone",nonce="1588251910/145b2ce129d4f11f703d7fedca2663ed",opaque="6d4366417c86bc18",algorithm=md5,qop="auth"
Content-Length: 0

Thank you,

 

[JohnS_3CX]

Hi Carlos,

If you also changed your config to IP only, and you make a call, and the capture shows a 401 challenge with nonce, then clearly the provider is asking you to authenticate with encryption.

What they say does not add up in this case. Perhaps you should run a capture and then try to make a call which should show this behavior. You can use it as proof in case they disagree

 

[NickD_3CX]

...and to add to what John said, ask them if you need to enable any other SIP Headers in your Outgoing INVITE messages.
From experience, some providers e.g. may rejects a call attempt if you do not have a "P-Asserted-ID" header.
This is just an example, but if you could post a sample INVITE message of how a PBX (any PBX) should send the INVITE, we could try and advise you accordingly.

 

[carlosmarchi]

@JohnS_3CX and @NickD_3CX ,

Thank you for your advises, I'll follow both. Unfortunately their support is hard to reach and slow (on the other hand, the service itself is affordable and reliable, the reason why I'm insisting and being patient with them). I'll update the topic as soon as I get to any conclusion, since it could help someone in the future.

 

[carlosmarchi]

Well, unfortunately there is nothing to be learned, because they didn't disclosured what has been fixed from their side, it just started working.

But, the information that I've provided based on your suggestions certainly have helped pointint the way. Thank you!