Solved Problems using yay.com as a SIP Trunk provider

[Lee Cramman]

Has anyone been able to get 3CX working using yay.com as a SIP trunk provider and if so can you offer me some pointers?

I have it configured using the Generic template, both IP and username / password authentication with server + proxy both configured as talk.yay.com:5060. The trunk is showing as green in the list and I am able to make outbound calls on this trunk so I am definitely authenticated correctly.

However all incoming calls fail and I get silence. Yay have not been able to help me much (they only seem to speak freePBX...) other than to say they are getting a "proxy authentication error" at their end when they try to deliver the call which just left me more confused.

I am running 15.5.15502.6 Pro (16 simn calls) deployed to the Google compute cloud using the 3CX tool. Both of the other trunks are working without issue, the inbound rules are definitely fine and my firewall check shows all green. I've even whitelisted all of the IP addresses Yay use for SIP / RTP (probably not necessary but I couldn't think of what else to try).

I'm stumped and can't find any mention of Yay in the forums...

edit: Just to say Yay wanted me to check the correct codecs are in place (which I have) and I've also tried enabling / disabling "Call Source Identification". The trunk is set for "PBX delivers audio" and all other settings have been left as default.

 

[leejor]

Does the 3CX Firewall Checker all pass?

 

[Lee Cramman]

Does the 3CX Firewall Checker all pass?

Yes, I re-checked it today. Everything passes.

 

[leejor]

Is there a 3CX Activity log entry for an incoming call? Any error messages?

 

[Lee Cramman]

Annoyingly, the 3CX log viewer requires 64 bit Windows which we do not have on the desktop at work (don't ask...). I scrounged a 64 bit Windows laptop and I get an unhandled exception due to a missing DLL when I try to open the log. Manual registration of said DLL fails if I try.

Sigh...

I'll see if I can scrounge a different machine.

edit: Different machine scrounged, same error message...

 

[Lee Cramman]

Wow, that was torture - tried on 5 different machines and 6 separate "Support info" downloads. Same error...

I didn't really want to spend more time troubleshooting installing the log viewer than the fault...

There are several mentions in the forum of this happening to people in the past but no solutions.

However, in the end it worked when I started using 7-zip to unzip the logs rather than the Windows inbuilt unzipping. Go figure.

Back to the problem at hand - can you tell me more specifically what I'm looking for in the log?

 

[YiannisH_3CX]

Hello @Lee Cramman

From the provided description it looks like you are having source identification issues so you will probably need wireshark and not the Bin log Viewer.
What is happening is that the number format Yay.com is sending does not match the format of your DIDs. You could also be reading the called number from a wrong SIP field.
So the call comes in and the PBX cannot match it to a trunk and is asking for identification from the provider which obviously fails so the call fails.
The easiest thing to do to see if that works is to edit your DIDs and add a "*" at the start of each DID. This will tell the PBX to try to match only the digits the follow the "*"
For example if have a DID +1123456789 and your provider sends the call in as 123456789 then the number will not match. You can edit that DID and add as *23456789 so you catch all possible number formats the provider could be using.

If this does not work then you have a bigger issue. Perhaps the DIDs are present to more that one trunks or you are reading the number from a wrong SIP field.
You will need to identify the SIP filed the provider sends the number in and adjust the trunks Inbound rules to read the called number from there.
You may also need to turn on Source identification but to do that you need to know what options to add there. It must be a SIP field that is unique to the trunk you are using. Like the IP the Invite arrives or a unique to the trunk user agent.

Obviously this work is done by 3CX for supported providers among other things so it is always recommended using a supported provider where these settings are pre-configured to the included template for you.

 

[Lee Cramman]

Many thanks - adding an asterisk at the start of the DID did not work but it gave me a lightbulb moment and led me to the correct solution.

I remembered seeing that Yay has an option to manually configure the incoming sip trunk username. When I checked it defaults this to the word "incoming". This is configurable to something else on their web portal and changing it to the DID number that 3CX is expecting to see fixed the problem.

It seems an odd choice for Yay to choose as a default option, and there isn't a lot of technical information on their support site, but at least the answer is here for anyone that has the same problem in the future.

Thanks again .

 

[YiannisH_3CX]

Glad to see the issue has been resolved and thank you for updating the thread with the solution.