UCM6204 - Inbound receives INVITE calls but does not connect them (INVITE > Status 100 > 183 > 480)


#1

Hi, and thank you for reading this in advance, whether you can help or not.

Situation: deploying a VoIP system on an existing LAN for 50-100 users, using the same fiber gateway.

Layout: LAN > pfSense > Fiber Router.

PBX: UCM6204

VoIP Provider: IrishVoIP

What works: registering trunk, registering extensions, internal calls, outbound calls.

What doesn’t work: inbound calls. This problem is, I believe, divided in two:

1.- When PBX Settings > SIP Settings > Allow Guest Calls = unchecked.
The PBX receives the invite and immediately replies a 404 not found. The inviting server acknowledges.

and

2.- When PBX Settings > SIP Settings > Allow Guest Calls = checked.
The PBX receives the invite and replies a 100 Trying > 183 Session Progress > RTP Packet to server [x 300 times] > 480 Temporarily Unavailable. No other packets come out of the PBX (searching destination?) or to the PBX during this process, except for the final inviting server acknowledgment to the 480 error.

As Allow Guest Calls changes the behavior, I assume that points to some problem with the authentication of calls.

As Allow Guest Calls checked does still not connect calls, I assume we also have a problem other than authentication. From what I see around, and taking into account I’m in unknown land, it seems the replies from the PBX are not what could be expected, nor is the silence from the inviting server - I understand the PBX should then try invite the Destination, report back, ring both and only then open an RTP connection. This understanding may well be very wrong.

=====

  • Inbound route is for _X. with nothing else checked except Destination, set to a working extension.

  • Fiber Router firewall is disabled.

  • I’ve changed the destination in Inbound Route: extension 1, extension 2 (can call internally from one to another or use them for outbound calls), external phone, dummy IVR. No change in the packets.

  • I’ve captured packets on the WAN side of pfSense: no related packets seem to be blocked -> shows the same communication.

  • I’ve also searched and blind-tested anything that looked like a similar problem someone faced before, and solved somehow. In case you haven’t figured by now, expert I am not, and after days of trying I don’t really know what to do next.

Can anyone suggest what to do further, or where to look for the misconfiguration?


#2

Guest is not a desirable function. Please re-enable as this opens it for virtually everyone.

Put the PBX behind the firewall and port forward the SIP and RTP ports and disable any SIP ALG or Helper function. You may need to look up pFSense and SIP to see more details of how to do correctly. Strongly consider setting the firewall such that the provider can get through, but no one else can. You can address remote and all later once the system is working with the provider.

Look at the INVITE and examine the TO header and the Request URI where you will see the DID being sent by the provider. In the inbound rule insert the number exactly as you saw in either header and they may be different. Simply select one and insert and note the field from which you took same and then go to the VoIP Trunk and change the DID Mode to reflect the field you used in the capture.

IN the trunk, NAT should be unchecked and you need to have g711A in the codec list at the top.

In PBX settings, SIP settings, NAT input your public IP or FQDN in the external host field, check the box for SDP and at the bottom of the page insert your LAN subnet, save and apply.


#3

Hi lpneblett,

I was activating Guest for the sole purpose of trying to achieve a successful call and work it from there, aware of the implications. Furthermore, I could see in the sniffed packets that even though we just got our number, during the couple of minutes of each guest-allowed-test a few attempts were made to place a call (by an alien number to an alien number) through our PBX. Be it as it was, I will follow your advice leave it off now.

I followed your recommended steps, but only PBX settings were to be filled-in differently. Reboot and test call, I received the same result: invalid number / 404.

IP: 46.19.210.14 is one of our provider’s server
IP: 8 […] 6 is our public IP address, and saved at PBX > SIP > NAT > external host field.
DID: 3 […] 1 is the caller
DID: 3 […] 5 is the destination, the number I exactly introduce in the Inbound Route pattern (_3…5).


#4

You are looking at the response, not the INVITE. The fields of interest are below:

Then in the VoIP trunk settings -

Then in the Inbound Route Settings -

As you can see in my 1st screen shot, the number shown in the URI is not the same as that in the To. As you can see, in the trunk settings I selected the To header to be the field of interest and you will note that this number is in an e.164 format with the “+” sign prepended. Then in the inbound route, you will see that I have taken the number from the To header and inserted it in the route exactly as shown in the To header.

I do not know if your URI and To are the same and is the DID mode is set, so that may explain the problem.


#5

Thank you so much for using your time on this. This is how those screens look for me:


#6

Why is there a diversion header in the INVITE?

Do this then and see -

In the inbound route add the number as seen in the diversion header exactly as shown with the “+” and see what happens.


#7

I ignore why there is a Diversion header in the INVITE. There is a possibility I checked the option following the solution to someone else’s problem. I don’t think so, but it could be.

Inserting the DID as it appears in the Diversion header gets the same result. Packet sequence also looks the same.

Unchecking the PBX > SIP > Diversion Header also does not alter the result, neither using the DID from the now-killed Diversion header nor the DID from the To header.


#8

The diversion header is coming from the provider if not mistaken. You need to ask them why?


#9

Ok, I will. Someone else has our credentials for their support portal, so I may need to wait this one off until Monday.

Before parking it, does the PBX > SIP > Bind IP need to have an individual address?


#10

Most likely not, what mode is the device in, switch, dual , route?


#11

Switch.


#12

Then no, it is OK. you can put in the IP of the UCM if you wish, but it really doesn’t matter as there is one one IP in play and 0.0.0.0 binds to any and all.


#13

Ok, so whenever the credentials-holder comes back I will check with the provider about the Diversion header, see where that gets me and, in any case, report back. Thanks lpneblett.


#14

SOLVED.

I ignore if this is standard and would thus be obvious for someone more savvy, or is specific to our provider, IrishVoIP.

I had registered only one trunk, which was supposed to handle both incoming and outgoing calls. The solution was to separate into different trunks, one Outbound trunk and actually not just one trunk for Inbound but as many as possible servers will handle calls coming to our UCM.

Calls were being rejected because the server handling the calls didn’t have an authenticated connection with the UCM, and the trunk used, what now is our Outbound trunk, needed that authentication. Inbound trunks are peer trunks, which don’t involve credentials, and thus the INVITE is not dropped. Again, this may be obvious, but it wasn’t for me.

So, solution, if anyone else stumbles across this:

Let me just state that support from our provider was good and fast, and thank you lpneblett for your great help and guiding.