401 Unauthorized response to incoming calls?


#1

This is a 6202 on firmware 1.0.19.29. It was working perfectly during the first half of the day.

Vitelity (the carrier) is starting to refuse outbound calls through an inbound server. This is just background. Unfortunately in the beginning I learned (w/ their advice) to set both inbound and outbound calls to go through the inbound server assigned to the client. They stop allowing this for a specific client and suddenly outbound calls aren’t going through. So I have to build an outbound trunk, point it at the outbound server, and then set all the outbound rules to use that trunk instead.

I did that for a client this afternoon. Outbound calling is working now.

However, inbound calls are being rejected by the UCM. See attached. Any ideas why that would start happening suddenly? Inbound routes have not changed. I see on the initial invite that the correct DID (inbound) is displaying. So the inbound rule should see that and route the call accordingly.


#2

1, Get rid of the unneeded codecs.
2. Look at the trunk settings. I assume this to be a register trunk so check and see if require authtrunk is enabled and if so, disable it.


#3

The Codecs are in the inbound Invite - so I don’t think I can control those?

And Authtrunk is not checked.


#4

Yes, they are, but I am still speaking of any unneeded in the UCM.


#5

I have only PCMU set on the trunk, and the Auth trunk is not checked. (The former is a new condition, the latter was like that before the problem cropped up.)

Should I delete and rebuild the inbound route?


#6

rebuild the route? no.

If a register trunk, the UCM should not be challenging the provider, but accept the call whereupon the UCM should be sending a TRYING and RINGING.

Delete the trunk and try again is all I can offer.


#7

When I deleted the newly created outbound trunk, inbound calls began working again. Does that tell you anything?


#8

Not really. I would need to understand all the settings from Vitelity in the UCM and how Vitelity is functioning at their end.


#9

I think I have isolated the problem.

Vitelity says you don’t have to register to the outbound server, and that “doing so can create problems with incoming calls.” (In a prior support ticket I had opened with them.)

But if no registration is required to the outbound server, how would they know the account from which the call was originating? The caller ID may not always be one on the client’s account - for example a call forwarded out from the UCM that retains the original Caller ID.


#10

Presumably it is then a peer trunk and they know the IP from which to expect the traffic and if the IP matches, they allow. They may not care about the CID.


#11

That sounds right - and they would know the registration IP because the inbound trunk is registered from the same IP.

However, in this case I have two separate accounts - two businesses under one roof sharing an internet connection - and both accounts register from the same public IP. I guess that could be problematic.


#12

Could be, I always found Vitelity to be a little contrary


#13

Yeah. I’ve had pretty good success with them for quite a few years now.

They still want me to use the credentials with the outbound server, but they don’t want me to register. So I configured a register SIP trunk and just unchecked the “need registration” box. But I have two such outbound trunks. If I disable them both, inbound calls come in fine. If I enable one of them, still inbound calls are fine. As soon as I enable both of them, I’m back to the inbound call failure.

So Vitelity says that they authenticate based on the credentials that are sent, and that’s how they know which account it is. So it’s not based on the IP address from which the account registered.

Any thoughts on why inbound calls begin to fail when two outbound trunks are enabled, even though neither of them are actively registering?


#14

I think I got it. I think it was dependent on some of the settings in the outbound trunks. I’ll post some more detail later.

Thanks, as always, for the help!

Mike


#15

Repeating 401 means 2 things:
No credential is added
Packet is to large and fragmentation make mess.

packet capture show both problem.


#16

Well an odd setup indeed.


#17

Here are the settings that ended up working for me. Thanks again for the help. The client is in the office this morning and everything is working as expected.


#18

Good morning, all.

The settings I posted worked to restore inbound/outbound calling. Problem is, Caller ID has stopped working on outbound calls. I have DOD set up on an extension group that contains the list of extensions used by this client. No matter what settings I change, I can’t seem to restore the outbound Caller ID.


#19

Here is the SIP flow, in case that helps. Looks like the UCM is sending the CID info, no?


#20

Can’t tell from a flow need to see the pcap to examine headers