Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Heritage02Rider

Pages: [1] 2
1
Thank you. You are correct. I tested and call dropped at 5 minutes. I set to 255 and call continued on as expected.

One thing is, none of us were getting a beep or option to DTMF anything. The call would just drop.

Anyway, it appears to have resolved a lingering issue.

2
I have a scenario whereby we receive call to our desk phone line and they get twinned to our mobile phones. We noticing that if you are on a call at five (5) minutes, the call drops. At first we assumed it was an iPhone issue, then complained to the carrier. Neither appears to be able to solve the issue, especially since a call directly to a cell phone does not exhibit this behavior. The only other part is the twinning.

So, after looking around a lot for something that says 600 seconds or 5 minutes and I found System > Timers and Limits > Unsupervised CO is set to 5 minutes.

Help has this definition: "Limits the duration of outside calls transferred or forwarded to outside numbers before recalling the primary attendant."

First, has anyone ever had this happen?
Second, can anyone confirm that changing this will prevent the calls dropping and whether or not this actually has any affect on twinned calls?

3
MiVoice Office 250/Mitel 5000 / Voicemail - Stop Failed Attempts messages
« on: February 25, 2015, 11:22:17 AM »
On our 5000, we have an after hours mailbox used for emergency calls. This will call a specified user(s) and tell them they have a message waiting. If they mistakenly log in incorrectly and then get in on another attempt, they can listen to the emergency message. However, shortly thereafter, the system sends another notification that a message is waiting,  which  is the message saying "there have been X attempts to log on to this mailbox". Again in an attempt to log on, they fail and the process continues.

Is there a way to turn off failure notifications?

4
MiVoice Office 250/Mitel 5000 / Re: Twinning with phantom
« on: December 17, 2014, 03:22:43 PM »
SOLVED

Sorry about this; really was my issue. I entered 10 digit phone number into the mobile number. This became an issue when we bought VTN's (virtual telephone numbers) in different area codes. The calls needed the area code included. Well, when you add 10 digits, the call fails because you need to dial "1" for long distance. Therefore, making the number 1xxxxxxxxxx the call functions properly.

5
MiVoice Office 250/Mitel 5000 / Re: Twinning with phantom
« on: December 17, 2014, 02:45:35 PM »
CPN is set to DID number. We use the twinning for all our desk phones and it propagates correctly. Propagate Original Caller ID on Transferis set to Yes.

6
MiVoice Office 250/Mitel 5000 / Twinning with phantom
« on: December 17, 2014, 02:28:00 PM »
I have a user who will be in the "field" all the time. They will be using a cell phone for all communications and therefore no desk phone. I have provided a DID and inside extension via phantom. My problem is this:

  • I created a phantom extension, 2236 with a user account
  • I added the mobile number to the user account
  • In the phantom > Associated Extensions, I have 92000 (automatic selection) set for Outgoing Extension
  • I have call routing for inbound DID # pointing to 2236

If I call from my cell to the DID, it rings and after a few goes to voice mail. The call never gets transferred/forwarded to the cell.

If I change the Outbound Extension to 92001 (backup copper lines), then call the DID, the call goes through.

If I change the Outbound Extension to 92003 (SIP trunk group), then call the DID, the call rings and after a few goes to voice mail

So apparently the call is not transferring to the SIP trunk properly. What should I look for to resolve the problem.

I have tried using 355 2236 xxxx# 359 xxx-xxxx # to forward all calls, but the call cannot be returned to the MITEL since it is forwarded. This is reasonable, but not preferred. Also, since the call works properly when using copper, I assume that the problem is resolvable.

7
MiVoice Office 250/Mitel 5000 / Re: Set VLANs on 5340 Phone?
« on: December 03, 2014, 04:07:24 PM »
Glad it worked out. You are welcome.

8
MiVoice Office 250/Mitel 5000 / Re: Set VLANs on 5340 Phone?
« on: December 03, 2014, 01:51:53 PM »
Yes - before firing up the phone, press and hold both the up and down arrows and then plug it in. You will be taken to the phone setup.

NETWORK PARAMETERS
* Yes
VIEW CURRENT SETTINGS
# No
STATIC QOS SETTINGS
* Yes
VIEW QOS SETTINGS
# No
MODIFY QOS PARAMS
* Yes
down arrow
VLAN
30
down arrow (6x)
STORE CHANGES
* Yes
REBOOT
* Yes

Mind you that you will have to do this on every single phone. Adding to the DHCP server sets your VLAN and the QOS settings and takes you about 2 minutes to setup versus 2-3 minutes for X number of phones.

9
MiVoice Office 250/Mitel 5000 / Re: Set VLANs on 5340 Phone?
« on: December 03, 2014, 12:50:25 PM »
You can also simply set the ports as untagged 10 and tagged 30 with PVID of 10. This will eliminate having to try setting computers to look for a specific VLAN. Then set your DHCP server for your computers on VLAN 10 (not the MITEL VLAN 30) with Option 125 for MITEL phones. It would look something like:

eid: ipphone.mitel.com;sw_tftp=xxx.xxx.xxx.xxx;call_srv=xxx.xxx.xxx.xxx;vlan=30;12p=6v6s3;dscp=46v46s26;

where xxx.xxx.xxx.xxx is the IP address of your MITEL switch.

The phones will connect to the DHCP server on VLAN 10, see the option 125 and then release the DHCP address and then restart using VLAN 30. Your MITEL switch will now see the phone and respond to the ACK and give it an IP address on that VLAN 30.

10
Follow up - I believe the problem to be solved. Turns out that it may have been a setting in the switches as it pertains to spanning tree. Ultimately I made a lot of changes. Found some incorrect configurations on some ports. I modified and tweaked everything until it was how it should look. I was still getting random "INSUFFICIENT BANDWIDTH" messages. Then I came along a document, simply but enlightening.

In case I had not mentioned earlier, I am using HP A5120's setup in a stack of four.

HP A-Series Switches - How to Troubleshoot Spanning-Tree Problems
1=wsrp-navigationalState%3DdocId%253Demr_na-c03661144-2%257CdocLocale%253D%257CcalledBy%253D&javax.portlet.tpst=ba847bafb2a2d782fcbb0710b053ce01&ac.admitted=1415983014553.876444892.492883150" class="bbc_link" target="_blank" rel="noopener noreferrer">http://h20565.www2.hp.com/portal/site/hpsc/template.PAGE/public/kb/docDisplay?javax.portlet.begCacheTok=com.vignette.cachetoken&javax.portlet.endCacheTok=com.vignette.cachetoken&javax.portlet.prp_ba847bafb2a2d782fcbb0710b053ce0 1=wsrp-navigationalState%3DdocId%253Demr_na-c03661144-2%257CdocLocale%253D%257CcalledBy%253D&javax.portlet.tpst=ba847bafb2a2d782fcbb0710b053ce01&ac.admitted=1415983014553.876444892.492883150

Using the "display stp tc", "display stp brief" and the "display stp root" commands, I realized my stack was not defined as the root. It was changing to other ports connected to other remote switches and Wi-Fi access points.

Ultimately, I added the following command:

stp instance 0 priority 0

And I am now (for the most part) free of the "INSUFFICIENT BANDWIDTH" issue. I do get a message every once in a while from my remote phones, but they are 3000 to 5000 miles away and I can live with a few random bandwidth issues.

So, I guess we can now mark this as solved. Thanks for everyone's input on this subject.

11
Unfortunately no. Mitel, as well as HP and Windstream had no answer. However, I have an idea, but I have to talk with my vendor first. The only things that changed when this started was in the adding of the SIP trunks and an MBG. The MBG actually does not filter the SIP trunk due to the Windstream configuration. So we use the MBG for simply doing MiNet and SIP phones (UCA app).

The default route of the Mitel 5000 had to be changed to point to the Windstream router to allow calls to be forwarded to Windstream. So now our default route, which was our HP stack becomes a secondary route on the Windstream router. So, I am guessing that the DHCP on the Mitel 5000 has also changed the default route from the HP stack to the Windstream router. So when a phone call is initiated, it has to bounce off the Windstream router before getting back to the Mitel switch. In reality, this should not be an issue, but as for what I am seeing, the insufficient bandwidth mostly appears (I say mostly since I have no hard facts to say all) when a phone is using a SIP trunk (i.e. inbound/outbound call). I can make a "internal" call to our plant 3000- miles away and talk for 30 minutes and never get a insufficient bandwidth message. If they receive an inbound call, they may get it in a a minute or so.

This leads me to still center my attention to the network configuration of the Windstream router and the Mitel switch. However, I do not know how to reprogram the phones to point to the internal HP stack as the default route. (the phones do not need to the Windstream router to be their default route)

Option 6 in the IP Settings >DHCP Server Settings > Options is Option ID 3 (router default gateway) but my configuration reads as follows:
Scope = IP Address Range and points to IP Settings >DHCP Server Settings > IP Address Ranges > 1
Format = Mitel Automatic (can I change this to IP address??? and force the local stack...)


12
If anyone is still following this post, my current situation is this; MITEL has been engaged as well as the telco SIP carrier. The carrier has shown no drops and since the user is receiving a fast busy, they have said there is no way for them to provide a busy signal during a call. They are on standby if needed. MITEL has reviewed my logs and freezes and have now sent them to engineering for further review. I have not heard back from them in over a week. Apparently they are perplexed as well. As I find out more information and/or resolution I will post. :D

The odd part of the whole issue is that the problem did not exist for the previous 8 months we had the 5000. Only changes to the system were the addition of a SIP trunk and an MBG for UCA/MiNet support (not SIP trunking - SIP is direct).

Thanks for everyone's support. Stay tuned.
 :D

13
Well, I am not going to discount that. I am not an HP expert, but I follow instructions fairly well. After pondering just that same idea, I can say that we have not had the problems prior to implementation of our SIP trunk. (Freud says that 'sometimes a cigar is just a cigar')

Regarding the connection between the MPLS and the core switches, I will investigate the QoS. To the end-user I believe it to be correct.

I am thinking if it were solely the SIP trunk to be the issue, I should be getting the insufficient bandwidth message at the MITEL switch rather than the end-user and it should be the connection to the SIP trunk in the alert; correct? I have had these messages, but they are never (or rarely) coincidental.

14
Follow up reply:

RE: Remote phones
Have not gotten a notice about bandwidth from the remote phone yesterday or today, but it appears they only made two calls. I will call them to see what is up - and perhaps a lengthy enough call to determine if we get a drop.

RE: Local phones
The INSUFF BANDWIDTH has been aggressive yesterday and today. Two phones today at exactly the same time today. So I checked the log and they were both receiving incoming calls. (not talking to each other) I am perplexed here. I cannot imagine that they are really having not enough bandwidth for a call. The one phone, which has had several since Friday had one occur at 5:17 pm. Basically 3/4 of the people had gone for the day. No possible bandwidth issue should be occurring.

To add to the frustration, I received an Insufficient Bandwidth notice from our SIP trunk as well. SO I decided to monitor the link and another occurred. We were utilizing about 1% of a 20 Mbps Ethernet MPLS circuit at the time the notice went out.

So... is it possible that the messages are phantom? The users are complaining that they get a brief busy signal, so something real is happening.

I will be contacting my phone vendor, but I already assume they will say its my network and that I need to call in someone else. I just cannot believe that it is the HP switches that are the weak link.

For reference - yesterdays Freeze - I see nothing indicating a problem:
Insufficient Bandwidth: 03-24-2014 at 11:45 AM
   IP Station Extension: '2167' at IP Address 192.168.200.21 on Board 7
   VoIP Configuration Information (Audio Session 110):
      VoIP DSP Number: 110
      Audio Frames Per Packet: 2
      In-Time Frame Percentage Threshold: 60%
      In-Time Frame Timeout: 5 secs
      Audio TX IP Address/Port: 192.168.200.21:50228
      Speech Vocoder Type: G711 Mu-Law
      Speech RTP Payload: G711 MU-Law
      Other Device System Echo Canceller Profile: No Echo
      Echo Suppression: FALSE
      Echo Saturation: TRUE
      Echo Suppression Sensitivity Level: 0
      Conn Dir: Two-Way; Call Session: 2167 (GW) 94072
   IP Audio Quality Snapshot Values:
      Reporting ICP IP address: 192.168.200.201
      Reporting IP Address: 192.168.200.21
      Reporting Signalling Port: 6993
      Reporting Voice Port: 50228
      Far End IP Address: 192.168.200.203
      Far End IP Port: 6824
      RX Codex: 1
      Delay: 0
      Jitter Instant: 0
      Jitter Average: 0
      Jitter Buffer Overflow: 0
      Jitter Buffer Underflow: 0
      Jitter Buffer Average Depth: 20
      Jitter Buffer Max Depth: 20
      Snapshot Packets Lost: 0
      Packet Loss Max Burst: 0
      Packets Out of Order: 0
   IP Audio Quality History:
      Packets Lost: 0
      Packets Received Total: 18250
      Jitter Buffer Histogram:
        10-19ms:   0
        20-39ms:   0
        40-59ms:   0
        60-99ms:   0
        100-200ms: 0
        200+ms:    0
      Packet Loss Histogram: consecutive packets
        1:    0
        2:    0
        3-5:  0
        6-10: 0
        10+:  0
   Audio Samplings:
   Rec:    Time   Jitter   Pck Lst   Pck Rx   InTime%
   1   5   0   0   250   100
   2   5   0   0   250   100
   3   5   0   0   250   100
   4   5   0   0   250   100
   5   5   0   0   250   100
   6   5   0   0   250   100
   7   5   0   0   250   100
   8   5   0   0   250   100
   9   5   0   0   250   100
   10   5   0   0   250   100
   11   5   0   0   250   100
   12   5   0   0   250   100


15
Heritage02Rider,

That will teach me to try and explain from memory, especially since I am not getting any younger, and you are correct it is Operations not Tools to get to the error logs; at least you found them and that is what matters.

Now, I don't know what kind of pipe you have at both ends between the US and Mexico, but let's just try a little experiment with your codecs before you start changing a lot of stuff around.

According to your Network Diagnostics File you are running G.711 for your remote phones so let's knock that down to G.729 and see if the frequency at which this happens either lessens or goes away all together; I will bet on it being reduced with some instances still occuring.

Go to System > IP-Related Information > IP Connections > Remote {or whatever your Mexico Phones are using}

Now, that I look at your Diagnostics again it looks as though you may have you Mexico Phones as local phones since it is showing 2 audio frames per packet. Hmm, you may just want to change your Mexico Phones over to the Remote IP Configuration or at least seperate them from the Local ones so you can change the Codec without affecting all the local phones as well. If you need help with this let me know and I can walk you through it.

Thanks,

TE

You are correct - all my phones were listed as Local. I did move the affected phones to the Remote configuration. They should now be doing G.729. The lower bandwidth requirement should provide less dropouts. I will see if the call quality suffers, but I will assume it will be negligible.

This one is obviously a wait and see, so I will post back next week after we let it sit for a while.

As for the local - still have not see an INSUFF BANDWIDTH show up since the change to the switches.

Thank you for all the help! It has been detailed and informative.

Karl

Pages: [1] 2