How to use this guide.

This article notes most of the common symptoms experienced by end users of Hosted VoIP services and gives some guidance on what further information to gather.

The information in this article should be used as a guide only to help steer the fact-gathering process for fault resolution or for further analysis.

You may notice that over most of the symptoms there is similar information required, usually end user environment and almost a call example is required or router should be checked (SIP ALG) or router is of poor quality.

• Check router is on
• Reboot router
• Check network cable between handset and router
• Swap network cable, ideally with one known to be working
• Reboot handset
• Factory reset handset
• Gather environment details (how are things connected, who is Broadband supplier, what router is being used)
• If above have been checked, raise fault at https://www.surevoip.co.uk/partnerfault

• Check if handset is registered (check handset's status page)
• Check if device can receive calls within 15 seconds or so after having made an outgoing call
• Check if outgoing calls end after 30/60/90 seconds or so - determine if there is a pattern
• Gather environment details (how are things connected, who is Broadband supplier, what router is being used)
• If above have been checked, raise fault at https://www.surevoip.co.uk/partnerfault

• Check if handset is registered
• If not registered, double check the configuration
• Reboot handset
  • If after power cycle does not check in, factory reset device
  • If still not, verify customer internet access is working - actively ping www.google.com
  • If everything above has been performed, raise fault at https://www.surevoip.co.uk/partnerfault
• If handset is registered, note any error messages or tones
  • Get a SIP trace from the handset
• Check SIP ALG and firewall - SIP ALG should be disabled and firewall should not be blocking or forwarding VoIP ports
• Gather environment details (how are things connected, who is Broadband supplier, what router is being used)
• If still not working, gather call example and environment details and raise fault at https://www.surevoip.co.uk/partnerfault

• This is an unusual scenario so should be rarely, if ever, encountered
• Ensure the customer is calling a valid telephone number - try various, include a landline number
• If number is valid, check SIP ALG and firewall
• Gather environment details (how are things connected, who is Broadband supplier, what router is being used)
• Obtain a SIP trace if possible
• If still not working, raise fault at https://www.surevoip.co.uk/partnerfault

• For example, customer makes call, and after 30, 60, 90, 5 minutes, 10 minutes, 15 minutes whatever… the call just ends
• Check SIP ALG has been disabled
• Identify if call timer continues to run or if it's like call has been hung up (timer stops)
• If not SIP ALG:
  • Check if softphone (Bria, X-Lite, Zoiper etc) and verify configuration (specifically NAT Traversal, STUN etc should be disabled)
  • If handset, verify NAT traversal, STUN should be disabled
• Disable STUN, ICE and NAT traversal settings on the handset - refer to the relevant documentation
• Disable session timers on the handset - refer to the relevant documentation
• Gather environment details (how are things connected, who is Broadband supplier, what router is being used)
• If all has been checked, raise fault at https://www.surevoip.co.uk/partnerfault

• Reboot router then handsets (amazing how often this fixes things!)
• For example, on an incoming or outgoing call, only the caller can be heard while the recipient can not (or vice versa)
• Check SIP ALG has been disabled
• Check NAT traversal (STUN, ICE should be off)
• What handset is being used?
  • Has handset been supplied by SureVoIP or adopted?
• Verify configuration (ie check RTP packetization)
• Gather environment details (how are things connected, who is Broadband supplier, what router is being used)
• Obtain a SIP + RTP trace - see SIP Traces for guidance
• If all checked, gather all details and raise fault at https://www.surevoip.co.uk/partnerfault

• Voice quality issues are always caused by the internet connection
• Check for faults on broadband
• Check no downloading/uploading taking place (this needs to be properly checked - simply not having Facebook or YouTube open does not mean the internet is not being used)
• Determine direction
  • If Customer is having trouble hearing other party, then it's a download issue - check above and consider QoS
  • If Customer can hear other party OK, but other party can not hear Customer, then it's an upload issue - check as above and consider QoS. Remember, on ADSL (standard broadband) the speeds are asymmetrical (download is much greater than upload!)
• Don't forget to consider that it may be the Other Party that is having phone issues - so check if this happens to one or more calls
• Check if mobile or landline
• Check with the ISP. Consider business-grade broadband from SureVoIP
• Suggest Customer to obtain DrayTek router which is an SMB router with business-grade features, such as Quality of Service (QoS) which can prioritise Voice traffic (we can quote on this)

• Incoming calls at random times (even overnight) with strange caller ID, could be letters, single digit, lots of zeros etc
• When answered there is no one there, or an unexpected person speaking
  • Identify if CLI is definitely not valid and calls do not traverse SureVoIP network (check CDRs)
  • Identify ISP
  • Identify router being used
  • Check SIP ALG (refer to SIP ALG)
  • If unable to disable SIP ALG then advise to use a different business grade router - SureVoIP can supply DrayTek routers which are suitable
• The symptoms experienced are due to hackers scanning the customer's network on the public internet and the router is allowing unauthenticated traffic to pass through to the handsets, causing them to ring. Therefore the customer's router is not suitable and should be replaced ASAP with a quality, robust business grade model.
  • SureVoIP can provide business-grade voice-optimised broadband suitable for all our VoIP services
• This phenomena often occurs with the BT Home Hub or Plusnet Hub - it is strongly recommended to obtain a more suitable business router

• End user complains that the are “unable to transfer calls” or similar
• Run through basic checks
  • Is transferring handset (handset with call) able to make internal calls otherwise?
  • Is transfer target handset (handset that will receive call) able to make and receive internal calls?
  • Check registrations (Status → Registrations)
• If basics are OK then perform standard symptom and information capture to begin escalation
  • Obtain call example
    • Exact time of call and time zone
    • Transferring handset extension
    • Transfer target extension
    • Transferred party's (the original caller) phone number
    • Any error messages on handset?
    • What transfer procedure was followed at Hosted VoIP Reference Guide and/or Call Transfer
    • Intermittent or regular?
    • Easily reproduced?
    • Which ISP?
    • Which broadband router?
    • Description of symptoms beyond a mere “it doesn't work”

• If symptom is not described above, a systematic approach must still be used to gather facts
• Obtain a description of the fault, especially the symptoms experienced by the user
  • It is important to understand how this issue is experienced by the end user
• Obtain call exampls
  • Exact time of call
  • Number dialled
  • Calling number (Caller ID)
  • Direction (ingoing or outgoing)
  • Product customer is on (ie Single User, Fully Managed Hosted VoIP, SIP Trunk, SIP Number etc)
  • Obtain a SIP Trace - see SIP Traces
• Is issue intermittent? Can it be reproduced?
• When did issue first start to happen?
• Was service ever working normally?
• If on Hosted VoIP, does it affect all users? Only a subset of users? Are all users in same location?
• Where relevant, confirm issue happens to more than one other party (ie if outgoing calls, does it affect mobile and land line?)
• Get more details about the end user environment:
  • Who is the ISP
  • What router is being used? (if unknown, ask if it's a free router supplied by the ISP (internet service provider))
  • Get the user to visit www.showip.net and note the IP address
  • What handset is being used by the end user (ie Cisco SPA504G, Yealink T29GN)
• And to reiterate: make sure you understand the fault
  • If needed, have end user describe fault in detail
  • If needed, ask end user to spell out every action they took, every keypress
  • Where relevant, ask when the end user hung up handset (where call drop outs are occurring for example)
  • Do not be afraid to sound pedantic or obsessive with details - the more details the better the understanding
• Once all above have been obtained, or as much as possible, raise a fault at https://www.surevoip.co.uk/partnerfault

In order to investigate any call establishing or media issue, a call example is required.

Follow these steps to narrow down where the issue occurs and in what circumstances.

These steps are relevant for incoming call issues:

• Extension to extension call
• On-net call to customer
• On-net call to DDI (excludes ring group)
• Off-net call to customer (ie PSTN line or mobile originated)
• Off-net call to customer DDI (ie PSTN line or mobile originated call to customer's DDI - must NOT be ring group)

• Note exact time of call, number dialled and calling number (CLI)
• Note exact symptoms - ie does call to go voicemail? is ringback observed? does call appear to progress? are any tones heard? does call stop completely (return to idle)?
• Note when issue first observed
• Is issue intermittent?
• Can any pattern be determined? (time of day? particular number? particular caller network, ie happens on Vodafone but not O2, happens when another extension on a call)

The above must be met otherwise the fault will be handed back until this has been obtained.

These steps should be followed if the end user is running their own PBX (aka phone system, telephone switch, phone server, IP-PBX, PABX etc)

In this scenario there is an expectancy that the end user is competent in managing and troubleshooting their phone system. If not, then they should be in contact with their support team or support provider who can assist.

We will not accept any fault that does not include a SIP trace, unless there is a valid reason for not providing one

The outbound SIP trunk might not be configured properly. This issue should never be encountered except during initial provision. If this issue crops up suddenly then the end user may have made some changes to their system.

• In most cases this is due to incorrect configuration
• Determine what errors/tones are observed
• Is the customer dialling a correct number?
• Check logs (increase log level if required) and advise what errors are noted - the reason will be stated
• Check over configuration and resolve any issues
• Check over firewall settings - refer to http://www.surevoip.co.uk/support/wiki/nat_and_firewall_settings if required
• If assistance is still required for escalation the following must be obtained
  • When did service last work?
  • Obtain PCAP SIP trace - refer to http://www.surevoip.co.uk/support/wiki/troubleshooting:sip_traces
  • Confirm if incoming calls work
  • Raise fault at https://www.surevoip.co.uk/partnerfault

Often caused by firewall/router not configured properly. SIP and RTP need to be forwarded to the PBX for calls to work.

• Check if outgoing works
• Are any errors/tones observed on the call attempt?
• Does it work in any scenario? ie works from landline but not mobile? note which networks do and do not work
• Does calling party hear ringback tone (call progressing sound)?
• CHECK LOGS - is the call received at all?
• Check firewall. Is the relevant SIP port forwarded to the PBX? (port 5060 by default, but could be 5160 on newer version of Asterisk). Is the port being filtered?
• Run trace on PBX - is the INVITE received? http://www.surevoip.co.uk/support/wiki/troubleshooting:sip_traces
• When was service last working? When did issue first start happening?
• Is this intermittent?
• Does this happen to particular numbers? All numbers?
• If escalation is requried
  • Gather all info as above
  • If SIP trace shows NO calls enter the network then provide call example
    • *Exact* time of call and timezone if not current UK time
    • Number dialled
    • Calling number if available
  • Raise fault at https://www.surevoip.co.uk/partnerfault

Sound is only heard by one person and not the other, or no one hears each other.

This situation is often caused by an incorrectly configured firewall/router and not all RTP (media) ports are forwarded correctly.

• Who originated the call? End user or outside party?
• Intermittent? Always?
• Does it affect all numbers?
• Who hears who? BE CLEAR - refer to customer as “customer” or “end user” and the outside party as “other party”
• Are codecs configured correctly?
• Is SIP trunk settings configured correctly? Check the Public IP address
• All relevant SIP and RTP ports forwarded to PBX? Is filtering configured correctly? Direct customer to http://www.surevoip.co.uk/support/wiki/nat_and_firewall_settings
• Check firewall on PBX itself also
• Obtain SIP+Media trace from customer's PBX - http://www.surevoip.co.uk/support/wiki/troubleshooting:sip_traces
• Raise fault at https://www.surevoip.co.uk/partnerfault and include the SIP+RTP trace

The call just tears down and may appear that the other party hung up to both parties.

This is often caused by session timers not working correctly or in some cases NAT not allowing all relevant in-dialogue SIP traffic to pass.

A key symptom to look out for is that the call generally tears down at the same length of time during a call, for example, it always happens at 15 minutes.

• Who originated the call? End user or outside party? (ie is this an incoming or outgoing call? both?)
• Intermittent? Always?
• Does it affect all numbers?
• How long into the call when tear down occurs?
• Is it always this length of time?
• Check system logs - the reason will be stated there
• Check firewall
• Check Session Timers - disable and test
• Check Public IP address configuration on SIP Trunk settings
• Obtain SIP trace - http://www.surevoip.co.uk/support/wiki/troubleshooting:sip_traces
• Raise fault at https://www.surevoip.co.uk/partnerfault and include SIP trace

All information must be provided in order to qualify for escalation.

• Name of person reporting fault and company name
• Contact details:
  • Telephone number
  • Email address
• If possible, account number or SureVoIP supplied telephone number or hosted domain - something to identify the customer account
• Call example - this is mandatory
  • Date and exact time of call
  • Number dialled
  • Calling number (if available)
  • Direction of call (who is making call)
  • Explanation of symptoms
• Frequency of problem
• When was it first noticed to happen
• When was service last known to be working
• How many users are affected (if on Multi User Hosted VoIP)
• Who is the broadband provider
• What router is being used
• What handset is being used
  • Did SureVoIP provide the handset?
  • If yes, obtain MAC if Yealink, Gigaset or Snom (Serial number if Cisco)

• it is important to get this information from the customer explicitly. Challenge any ambiguous answers and get exact details.
• We can not accept answers along the lines of “it happened in last 5 minutes!” or “it happens all the time!” or “check your logs, you will see it!”
  It is recommended that you do not offer choices of “was it this call” as the end user will most likely simply say “yes that's it…!!”
• If asking customer if fault is still occurring, request a specific example.
• The fault escalation should not include terms like “it's not working” - the actual symptoms must be explored and clarified, and only then should a fault be raised

• Find out exactly what the problem is. Inbound audio? Outbound audio? Verify properly.
• If on Hosted VoIP, verify handset configuration
  • Verify NAT Traversal client-side is Disabled
  • Verify SIP ALG client-side is Disabled
  • Verify registration is TCP-NAT or UDP-NAT
  • Try setting to TCP instead of UDP, and ensure no firewall is blocking UDP/TCP port 5060
  • Verify ports 10000-40000 are not blocked.
  • Run trace from handset - see SIP Traces
• If non-hosted, verify where calls are going to on Core.
  • Verify ports are forwarded correctly
  • Verify trunk configuration is correct
  • Verify NAT settings are correct
  • Verify SIP ALG is disabled on CPE router. Unless Cisco 800 series, which works well.
    • See SureVoIP SIP ALG guide for info on disabling SIP ALG
  • Verify customer routes are properly set up
  • Verify no congestion on customer end
  • Run trace on SIP Gateway for SIP (and include media if audio issue) - see SIP Traces
  • Get customer to run trace and/or send full logs
• When fault has been proven away from customer's PBX, and evidence (SIP trace) obtained, then raise fault at https://surevoip.co.uk/partnerfault

• Does device use PSU (power supply) or PoE (power over ethernet)?
• If PSU:
  • Swap with other known working PSU, if available
    • If it powers up, PSU is faulty
    • If it does not power up, handset is faulty
  • Ensure that known working socket is used also!
• If PoE
  • Verify the handset is plugged into a PoE port (with some switches not all ports are PoE enabled)
  • Swap port with known working port (such as swapping handset to another socket)
    • If handset powers up then PoE switch either faulty, not PoE enabled or not PoE port
    • If handset does not power up then handset is most likely faulty
• Escalation requirements:
  • Verify the checks above
  • Confirm if handset has ever been working
  • Take note of primary contact, contact details, and delivery address
  • Escalate requesting RMA

This symptom is when the handset does not get an IP address - the message on the handset will vary depending on the make and model. It may say “network unavailable” or “unable to obtain IP” or similar. A Cisco SPA504G and handsets in the same family will have a red Mute button.

• Swap port with known working network port
  • if it now works, then the local equipment is faulty
  • if it still does not work, and the network port definitely works (and has been demonstrated to work) then raise RMA (via escalation - email partners@surevoip.co.uk with details and provide MAC/Serial details)
• Swap the handset with another working handset
  • if the original handset starts to work and the swapped handset stops working then it's an issue with network cable or network port
  • if the original handset still does not work and the swapped handset continues to work then it's a hardware issue so raise RMA (via escalation - email partners@surevoip.co.uk with details and provide MAC/Serial details)
• Escalation requirements:
  • Verify the checks above
  • Confirm if handset has ever been working
  • Take note of primary contact, contact details, and delivery address
  • Escalate requesting RMA (email partners@surevoip.co.uk with details and provide MAC/Serial details)

Use the following as guidance if a handset is not auto-provisioning.

In most cases, the SureVoIP experience is literally “out the box”, where a customer receives a handset supplied by us and they simply plug it into their network and it “just works”.

It rarely is the case that it simply doesn't quite work.

1. Check handset gets IP address
   1. If NO then check correct cable in correct port etc (follow on in Hardware above)
   2. Check DHCP allocation table (try rebooting router or office server responsible for DHCP allocation)
   3. Verify DHCP dialogue take place (run Wireshark in promiscuous mode on network or take PCAP from handset)
2. Check internet works (have computer in same network run tests against dynamic content - try beta.speedtest.net )
3. Check DNS works
4. Check for DHCP options (ie option 150 or option 66) - verify what router customer is using on local network - rule out conflicting provisioning set-ups
5. Check LLDP and/or CDP is disabled on device
6. Confirm whether only a single device is problematic, or a few or all of them (if more than one located on site)
7. Raise fault at https://www.surevoip.co.uk/partnerfault

1. Perform initial local checks
   1. Check filter, modem cable, ethernet cable, power, lights on router, broadband username+password are configured correctly etc
   2. Reboot router
      1. if possible, power off for 10 minutes
      2. check if router is seeing xDSL sync
      3. check if router is attempting to establish session
2. raise fault by emailing partners@surevoip.co.uk and provide broadband username (as per welcome pack)

1. Perform initial local checks
   1. cables plugged in, fibre cable plugged in and not wound too tight, power cables etc
2. email partners@surevoip.co.uk and provide circuit reference (as per welcome pack), or site post code. Call 0330 445 1000 opt 2 if urgent