Physical 3300 to Virt

[igbe]

Hi Everyone

Hoping for a little input. Our vendor upgraded a very old 3300 hardware system to a virtual system. Everything has been fine except for SIP trunk issues. It seems when they drop, they cannot or don't reconnect. Mitel vendor says it's the SIP provider and the SIP provider says they can do a SIP trace and see the out of service error the system is reporting. We are stuck in the middle.

The IP and Firewall rules have been in place for years now but have been checked, several times. The only consistent is when they both eventually go out of service, I have to reboot the Mitel Phone Sys 10.1.0.29 VM and immediately the SIP's come back online.  They finally opened a TT with Mitel yesterday two weeks after the fact. Hopeful I can get some answers as this has been draining. The old system with the same SIP provider has never had an issue for the past 5 years, not one outage.

Release level: 10.1
Active software load: 10.1.0.29 (21.1.0.30

Anyone have any thoughts or suggestions? Can I force the SIP profile to reinit without bouncing the entire VM? Why would a reboot on the VM resolve this issue?

[ACDeezNutz]

Should be able to go into Network Elements and disable then re-enable the trunk instead of a full reboot.  That would force a re-register.  Do you have an MBG?  MiVB is not supposed to be connected directly to public SIP trunks via NAT.  Documentation shows that is not supported.  If you have a local private IP hand off for SIP then that should be OK.

[igbe]

Thanks for the reply. Mitel vendor said Mitel TT indicates it's the SIP provider.

I have disabled and reenabled the NW elements and that never works. Only thing that works is the reboot of the VM and something that seems very off to me. Yes, we have a MBG and yes, it's a private IP hand off.

[ACDeezNutz]

Disable the trunk in MiVB Network Elements then disable the trunks on the MBG also, then turn both back on should do it then.  Generally the Network Elements does it by itself.  A full reboot is a red flag something isn't setup right.

[Tech Electronics]

igbe,

You could try the following.

1. SIP LINK STATE PEER <Peer Name>; The peer name is what it is called in Network Elements.
2. SIP TRACE ON
3. SIP BUSY FORCE PEER <Peer Name>
4. SIP RTS PEER <Peer Name>
5. Wait for about 2 minutes to get enough registration and options attempts.
6. SIP TRACE OFF

Use WINSCP to log into the MCD with the Root credentials and then go to the VMAIL folder to get the SIP Packet Capture.

You could just delete the file from the MCD or use the command SIP TRACE CLEAR to get rid of it so it doesn't take up HD space.

Look at the packet capture to see if you are sending or receiving Registration or Options 'keepalive' packets.

The above is similar to disabling the Network Element which just means that it isn't trying to register or use keepalive packets. In reality though you are busying out the SIP Trunk and then Returning it to service which will force it to Register and then send Options packets to make sure the other side is up.

[sarond]

Just a small correction on Tech Electronics post.

Command should be SIP TCPDUMP (Not SIP TRACE)