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 Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
SysMonitor Help 2
- Thread starter BResource
- Start date
intrigrant
Systems Engineer
I have seen that recently, ip phones chained?
- Thread starter
- #3
intrigrant
Systems Engineer
Should have mentioned that to start with.
SlowRRQ means the keepalive acknowledge packets coming from the phone are not or close to the time limit they should be within.
Keepalive are the above mentioned packets which the phone must reply on within a fixed amount of time. A full H.323 trace will show that time.
ExistRRQ is when the gatekeeper receives a Registration ReQuest which is in use by another device or the device rebooted unexpectedly while it was registered.
All they above will happen on poor connections. Enabling QoS within the VPN tunnel and the intermediate switches may help.
SlowRRQ means the keepalive acknowledge packets coming from the phone are not or close to the time limit they should be within.
Keepalive are the above mentioned packets which the phone must reply on within a fixed amount of time. A full H.323 trace will show that time.
ExistRRQ is when the gatekeeper receives a Registration ReQuest which is in use by another device or the device rebooted unexpectedly while it was registered.
All they above will happen on poor connections. Enabling QoS within the VPN tunnel and the intermediate switches may help.
- Thread starter
- #5
Thank you very much for this!
Your right I should have mentioned that, one other thing I should have mentioned is what URQ stands for! User Request? Is this initiated by the phone?
Which is worse SlowRRQ or Keepalive?
Is Keepalive shown when no packets get through or when the phone responds in the correct way?
If everything is perfect should I see anything in URQreason?
I saw another entry today TCPclose??
Sorry for all the questions!
Many thanks!
Your right I should have mentioned that, one other thing I should have mentioned is what URQ stands for! User Request? Is this initiated by the phone?
Which is worse SlowRRQ or Keepalive?
Is Keepalive shown when no packets get through or when the phone responds in the correct way?
If everything is perfect should I see anything in URQreason?
I saw another entry today TCPclose??
Sorry for all the questions!
Many thanks!
? Are your phones having any specific problems.
The phones and the system will be regularly talking even when no calls are in progress. The phones want to know that the system is still there (else in some scenarios they will try to connect to a fallback system). The system wants to know that a registered device is still there to potentially answer calls rather than wasting times routing calls to devices that have been switched off.
That non-call traffic, is also useful to stop intermediate devices like firewalls and routers from closing down the connections between the phone and the system.
Stuck in a never ending cycle of file copying.
The phones and the system will be regularly talking even when no calls are in progress. The phones want to know that the system is still there (else in some scenarios they will try to connect to a fallback system). The system wants to know that a registered device is still there to potentially answer calls rather than wasting times routing calls to devices that have been switched off.
That non-call traffic, is also useful to stop intermediate devices like firewalls and routers from closing down the connections between the phone and the system.
Stuck in a never ending cycle of file copying.
- Thread starter
- #7
Hi Sizbut,
I want to know if this can help identify network performance issues.
There was a fault where a selection of phones displayed reseting on URQ then rebooted.
Also I am really curious about what that part of SysMon can tell me.
I know the phones heartbeat and continuously talk, I just want to know what the H.323 Phone Status page tells me in detail.
Many thanks!
I want to know if this can help identify network performance issues.
There was a fault where a selection of phones displayed reseting on URQ then rebooted.
Also I am really curious about what that part of SysMon can tell me.
I know the phones heartbeat and continuously talk, I just want to know what the H.323 Phone Status page tells me in detail.
Many thanks!
holdmusic34
Vendor
Mate there's a system monitor manual on the knowledgebase.
Depending on the URI configuration the ICR can be completely ignored.
If your URI is configured to use internal data then the IP Office will look into the user's SIP tab and if you have *'s it will look into ICR.
A madman with a taste for speed.
Depending on the URI configuration the ICR can be completely ignored.
If your URI is configured to use internal data then the IP Office will look into the user's SIP tab and if you have *'s it will look into ICR.
A madman with a taste for speed.
- Thread starter
- #9
intrigrant
Systems Engineer
A URQ is a User ReQuest, usually it has a command with it.
If it comes from the Gatekeeper(IP Office) it is reboot or re-register request, if it comes from the endpoint it is a notification to the Gatekeeper, usually a message the phone wants to unregister or is about to reboot.
You can initiate a reboot/re-register request from within sysMon or SSA or with local admin on the phone.
Both slowRRQ and missing keepalives are bad, the messages use UDP so there is no session to terminate by a firewall.
H323 is a complex sessionless protocol, that is why SIP was introduced which prefferred use TCP for Gatkeeper <> endpoint communication.
If it comes from the Gatekeeper(IP Office) it is reboot or re-register request, if it comes from the endpoint it is a notification to the Gatekeeper, usually a message the phone wants to unregister or is about to reboot.
You can initiate a reboot/re-register request from within sysMon or SSA or with local admin on the phone.
Both slowRRQ and missing keepalives are bad, the messages use UDP so there is no session to terminate by a firewall.
H323 is a complex sessionless protocol, that is why SIP was introduced which prefferred use TCP for Gatkeeper <> endpoint communication.
- Thread starter
- #11
nothingworks101
Programmer
we are having the issues with many phones in our office, rebooting when idle or freezing when on a call. when I pull up monitor we see the same things BResource had.
a ton of these every day :
SlowRRQ, existrrq, keepalive, TCP close, sysmonRestart
but our network team says they see nothing wrong. I s there something I can show them to prove its a network issue and to dig deeper?
a ton of these every day :
SlowRRQ, existrrq, keepalive, TCP close, sysmonRestart
but our network team says they see nothing wrong. I s there something I can show them to prove its a network issue and to dig deeper?
-
1
- #13
intrigrant
Systems Engineer
Your network guys don't see issues because they don't look or they don't really care, it is a common attitude for network guys.
Most of them know how to setup a network but are really bad in trouble shooting, you need some luck to find the right guy or complain to the CEO and increase the pressure on them.
Most of them know how to setup a network but are really bad in trouble shooting, you need some luck to find the right guy or complain to the CEO and increase the pressure on them.
- Thread starter
- #14
Hi,
Here are my notes such as they are:
* SlowRRQ means the keepalive acknowledge packets coming from the phone are not or close to the time limit they should be within.
* Keepalive are the above mentioned packets which the phone must reply on within a fixed amount of time. A full H.323 trace will show that time.
* ExistRRQ is when the gatekeeper receives a Registration ReQuest which is in use by another device or the device rebooted unexpectedly while it was registered. Phone rebooted between heartbeat time outs. If it breaches the time out and reregisters you wont see this.
Phones heartbeat every 55s (sometimes different) with a registration request.
The system timesout the phone if it sees no registrations in 240s and the phone is classed as unregistered after this time.
The Registrations tab shows how many times a phone has registered since the system has been up. This doesnt mean how many heartbeats it has had but full on registrations from such things as a phone reboot etc. You can break down why the phone has had say 20 registrations by counting how many ErrorURQ and ExistURQs there have been and adding 1 for the original registration. It may have had 15 ErrorURQs indicating phone reboots/packet timeouts before the 240s timeout and 4 times another device has tried to be this extension (or they hotdesk).
RRQtime >150% Avg this counter shows how many times the heartbeat has been outside of the 55s but also inside of 240s. Indicateing a slow connection.
Error URQ counter shows how many times a phone has timed out or lost registration for what ever reason between hearbeats but within the 240s timeout.
ExistURQ means that the phone was registered on another device or re-registered during the 240s timeout. If the phone registered after the 240s timeout it would be seen as a clean registration.
If all is perfect you will not see any URQ reasons. If there is a ErrorURQ during this time the URQreason shows 'KeepAlive'.
Delay disabled in a trace means that the phone is off hook.
Here are my notes such as they are:
* SlowRRQ means the keepalive acknowledge packets coming from the phone are not or close to the time limit they should be within.
* Keepalive are the above mentioned packets which the phone must reply on within a fixed amount of time. A full H.323 trace will show that time.
* ExistRRQ is when the gatekeeper receives a Registration ReQuest which is in use by another device or the device rebooted unexpectedly while it was registered. Phone rebooted between heartbeat time outs. If it breaches the time out and reregisters you wont see this.
Phones heartbeat every 55s (sometimes different) with a registration request.
The system timesout the phone if it sees no registrations in 240s and the phone is classed as unregistered after this time.
The Registrations tab shows how many times a phone has registered since the system has been up. This doesnt mean how many heartbeats it has had but full on registrations from such things as a phone reboot etc. You can break down why the phone has had say 20 registrations by counting how many ErrorURQ and ExistURQs there have been and adding 1 for the original registration. It may have had 15 ErrorURQs indicating phone reboots/packet timeouts before the 240s timeout and 4 times another device has tried to be this extension (or they hotdesk).
RRQtime >150% Avg this counter shows how many times the heartbeat has been outside of the 55s but also inside of 240s. Indicateing a slow connection.
Error URQ counter shows how many times a phone has timed out or lost registration for what ever reason between hearbeats but within the 240s timeout.
ExistURQ means that the phone was registered on another device or re-registered during the 240s timeout. If the phone registered after the 240s timeout it would be seen as a clean registration.
If all is perfect you will not see any URQ reasons. If there is a ErrorURQ during this time the URQreason shows 'KeepAlive'.
Delay disabled in a trace means that the phone is off hook.
-
1
- Thread starter
- #15
nothingworks101, I had this issue before and it turned out that there where some faulty PC's spamming the network with DCHPv6 requests.
I had to use a hub and wireshark to prove to the network team that this was the issue.
I was able to identify the MAC addresses of the devices spamming these requests and pass on to it.
I had to use a hub and wireshark to prove to the network team that this was the issue.
I was able to identify the MAC addresses of the devices spamming these requests and pass on to it.
- Status
Similar threads
