Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations biv343 on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Incoming calls not working for Mitel MBG. 1

Richard_Harrow

Technical User
Aug 31, 2023
50
AE
So we have an embedded MBG on a Mitel SMB with MiVB 10.1 along with an EX-Controller that has all the extensions registered on it.

Outgoing is working, but we can't seem to get incoming to work and there aren't any traces showing up on MiVB.

We don't have any routing rules set in the MBG nor do we have any digits being absorbed or inserted in the SIP peer profile. Both of them are blank within the profile.

Could someone help me out on how to go about setting incoming call for the MBG?
 
Basically, the main controller with all the extension information is an ex-controller that is clustered with an SMB controller that has an MBG blade hosted on it.

The main controller's your regular 16G EX-Controller.
Do you see any traffic on the CCS trace on either the SMB or EX?

Is the IP trunk configuration correct between the two PBX?

SSH to the MiVb that is hosting the SIP trunk and run tugtail command and make calls in to see if calls is actually landing in the MiVB and the messages.

If calls are seen on the MiVB, then the issue is on the MiVb and not MBG.
 
Thing is, the country where this controller is in uses 8 digits. We have 8 digit DIDs defined on each user which I think automatically makes entries within the DID form if I'm not mistaken.
As long as your programmed DID digits match what the carrier is sending, you will still want to absorb "0" digits in the SIP trunk attributes as Richard recommended. If they are sending 10 digits, then you would want to absorb 2 digits to match your Direct Inward tables.
 
Do you see any traffic on the CCS trace on either the SMB or EX?

Is the IP trunk configuration correct between the two PBX?
whi
SSH to the MiVb that is hosting the SIP trunk and run tugtail command and make calls in to see if calls is actually landing in the MiVB and the messages.

If calls are seen on the MiVB, then the issue is on the MiVb and not MBG.
Nah, we don't see any traces on either controller.

Also, here's the funny thing that we noticed, we tried registering a softphone on the MiVB with the MBG blade running, but seems as though it doesn't let it register and it only registers after shutting down the MBG blade.

Another thing we noticed is that we cannot SSH into the MiVB hosting the SIP trunk. The SSH application just closes as soon as we enter the MSL administrator password. It's working for the primary controller though.

It's worth noting that both blades are deployed on a single MSL that was deployed on the SMB controller.

Also, just a quick question, if the IP trunk configuration wasn't correct between the two controllers, wouldn't we have trouble making outgoing calls from an extension registered on the primary controller?
 
How many digits to asorb
Asorb from left to right...if the did digits sent is 8 and the number dosent need to be modified then the ext should match the did
If you have a 4 digit ext you would strip 4
Mod 0 and match ext number to did.. or use a did translation table ext 1010 = did 9950 if you asorb a digit its for all dids ... sx200 icp as a reference ... might not be exactly correct for your system 12345678
Strip 4 leaves 5678 translate to ext 9876
Or ext 5678 and did 5678
 
Who is your carrier? Not at&t right? Saw some simmilar issues on as nec sv8100/9100
Turned out to be the carrier rejecting the call due to protocols on there backend... however that was 2 nec systems using sip talking on a deticated circuit... it was never a programming issue on our end but a nat translation on their circuit.... same symptoms though...
 
When calling a DID do you get busy tone.. CO error recordings? Dead air?

You will need a routing rule think a wildcard is uri * going to desired controller

Something about this but like on the carrier translation for an ip or nat rule this is haunting me.......🤔
 
Nah, we don't see any traces on either controller.

Also, here's the funny thing that we noticed, we tried registering a softphone on the MiVB with the MBG blade running, but seems as though it doesn't let it register and it only registers after shutting down the MBG blade.

Another thing we noticed is that we cannot SSH into the MiVB hosting the SIP trunk. The SSH application just closes as soon as we enter the MSL administrator password. It's working for the primary controller though.

It's worth noting that both blades are deployed on a single MSL that was deployed on the SMB controller.

Also, just a quick question, if the IP trunk configuration wasn't correct between the two controllers, wouldn't we have trouble making outgoing calls from an extension registered on the D
Nah, we don't see any traces on either controller.

Also, here's the funny thing that we noticed, we tried registering a softphone on the MiVB with the MBG blade running, but seems as though it doesn't let it register and it only registers after shutting down the MBG blade.

Another thing we noticed is that we cannot SSH into the MiVB hosting the SIP trunk. The SSH application just closes as soon as we enter the MSL administrator password. It's working for the primary controller though.

It's worth noting that both blades are deployed on a single MSL that was deployed on the SMB controller.

Also, just a quick question, if the IP trunk configuration wasn't correct between the two controllers, wouldn't we have trouble making outgoing calls from an extension registered on the primary controller?
So if you are not seeing anything on the MiVb means the issue is before it, meaning MBG or upstream. Run tugtail on the MBG via SSH and verify SIP messages to see if there are any error codes.
 
Thing is, the country where this controller is in uses 8 digits. We have 8 digit DIDs defined on each user which I think automatically makes entries within the DID form if I'm not mistaken.
Verify the format the carrier is using. Here in the US, I often have carriers delivering in e.164 (+1) format, and I have to request they change to 10 digit for me. You may have an International Country code being delivered by them.
 

Part and Inventory Search

Sponsor

Back
Top