The customer has reported a delay, an abnormal pause after dialing before the call begins or other delays in interaction. This delay could be heard once or multiple times, on one call or over a series of interactions, and could be heard by either just the caller, just the callee, or on both sides
Information to gather from the customer:
- Circumstances of the call–Think in terms of Who, What, When, Where and How:
- Who: The parties involved, usually an Originating Party who called out to a Terminating Party
- Originating Party (calling number):
- Terminating Party (called number):
- Direction of issue: Did the delay happen for only one party (just the caller? just the callee?) or is the delay heard from both sides?
- Scope of the issue: How many users are experiencing delays?
- Single user
- If remote, investigate network
- If in office, investigate physical layer
- Multiple users - Investigate Edgewater
- All users
- Site-wide - Investigate Edgewater
- Enterprise-wide - If in different locations, there could be an issue on the server or back end
- Single user
- What: The context of the call. Inbound? Outbound? Internal? External? Is it only certain kinds of calls, or is it all calls?
- What is being experienced or reported: This could be a delay after dialing a phone number, before the call begins. Sometimes it's a delay after dialing before any ringing is heard. There can also be delays in calls being routed to the appropriate destinations, delays with softphones and application call pops, delays with hold music, etc.
- Endpoint: Method of placing and receiving call
- Deskphone:
- Manufacturer: Polycom, Yealink, Cisco or other?
- Primary Device or SCA?
- Hotel/Open Seating host
- Remote Office: For example, delays making an outbound call in Unity, the call takes too long to reach the user's remote office cell phone. Get call examples and test with your own cell. This may be an issue with the user's network that would require firewall settings
- Softphone
- UC-One
- Skype
- Teams
- Cell phone
- Deskphone:
- Application: Was any call tracking application in use?
- Unity
- ECS
- Call center
- Receptionist
- Any additional details pertinent to the call (Was the user transferred or put on hold?)
- Any error messages on the phone or application?
- Headset?
- When: Was this a one-time occurrence, intermittent or persistent with every call? Try to get a specific call example.
- Date:
- Time (including time zone):
- When did the issue start?
- Today at a specific time
- Previous day
- Does this happen at a certain time of day?
- If at certain times, could be due to call volume (connection bandwidth) or network issues (network saturation or QoS issues)
- Any unusual weather conditions such as rain or electrical storms? Could indicate bad wiring or electrostatic discharge (ESD)
- Has never worked since implementation
- When does the delay occur?
- What is the duration of the delay? Is it always the same amount of time?
- Frequency
- Every call?
- Intermittent?
- Can it be replicated?
- On user's end?
- On our end?
- Where: Location of each party.
- Remote or in an office behind an Edgewater? (Ask the user, "Are you in the office or remote/at home?")
- Check phone in OCOM to see what IP address it's registering from. If the IP can't be found in Nagios, it's probably remote.
- Does Evolve own the numbers involved or are they off-platform numbers owned by another carrier? (Some troubleshooting may be necessary to determine this)
- Remote or in an office behind an Edgewater? (Ask the user, "Are you in the office or remote/at home?")
- How: How was the call initiated?
- Direct call: Originating Party dialed Terminating Party directly
- Queued call: The call was presented to the Terminating Party through a call center.
- Transfer: The Originating Party reached a Terminating Party, then was transferred to a secondary Terminating Party.
- Who: The parties involved, usually an Originating Party who called out to a Terminating Party
- Obtain a call example - Call Examples must be from within the past 24 hours so that if needed they can be investigated with underlying carriers.
- Caller:
- Callee:
- Time/Date (including Time Zone):
- Call Example Verbiage:
To facilitate troubleshooting the reported issue, a call example is required.
Please provide us with a specific, recent call example (from within the last 24 hours) of the reported issue, so we can verify its routing and quality.
Please include the following information:
Caller number:
Callee number:
Date and time (including time zone):
Issue description:
**************************Your ticket is now being placed on a HOLD status pending the requested information.
A delay can occur for one of two major reasons:
- LAN/Physical Layer (Local Network or Device Hardware):
- Outbound calls: After picking up the handset/headset, before hearing a dial tone
- Inbound calls: Delays after answering a call, before being able to talk - If in office, investigate Edgewater
- After pressing phone buttons, a delay between pressing the button and getting a response from the phone
- Delays after a voicemail is received, before the indicator begins to light up
- Example ticket INC-31166: VM pin was synchronized, phone was rebooted
- Typical troubleshooting steps:
- Reboot phone
- Ping the phone's local IP and see response times.
- If behind an Edgewater, try plugging the phone directly into a LAN port on the Edgewater.
- For site-wide delay issues, investigate the Edgewater - Gather data re. up time, load and switch CPU (see higher tier if not sure how to do this.)
- WAN/Carrier (Delays with SIP/Latency on the Call):
- After dialing a phone number, before it starts ringing
- Example ticket INC-22889: Site-wide delays making outbound calls. They'd hear a dial tone right away but would experience delays after entering a phone number before it'd ring out. Call examples showed 403 Forbidden errors occurring right after the Invite, before finally going through to 183 Ringing. The 403 turned out to be coming from us. Bounced survivability in the Edgewater and delays stopped.
- With audio and hold music
- Delayed audio might be noticed on a call if the two parties are not hearing each other right away and end up talking over each other. For more information, see Call Quality Troubleshooting: Delayed audio / Talking on top of each other
- With softphones and application call pops: Investigate network, get logs
- In calls being routed to the appropriate destinations: For example, delays reaching voicemail or getting into a call center
- Typical troubleshooting steps:
- Check OCOM for jitter, latency and slow round-trip times
- Look at SIP messaging and timing in OCOM. Any delays in when the signal's sent to the carrier and when the carrier responds? Look for delays after the invite. After the Try, you should be getting a Ringing message (180 or 183). Is this delayed after a few seconds? If so, you might need to investigate with the underlying carrier.
- Check routing profile in OSSmosis as carrier interactions can cause a 503 error
- These delays can occur because:
- SIP messaging is delayed - Look for timing delays in the call example.
- The call is struggling to find a path.
- After dialing a phone number, before it starts ringing
Troubleshooting
- Find the call example in OCOM and document the call example and PCAP in the ticket
- OCOM
- Search by the offnet number. This is the best way to make sure you get all the legs of a call. Can search under "User Tracking" or "Calls."
- Calls from a softphone like UC-One or ECS will show as inbound.
- Is there any packet loss or jitter? (Note: Delay is usually caused more by jitter and latency, as opposed to packet loss)
- If so, identify the source
- Carrier: Open a ticket with the offending carrier for investigation.
- Local network:
- If in the office, is there latency on the WAN connection of the Gateway/Edgewater? Check round-trip times in Nagios:
-
- If we manage the circuit, open a ticket with the carrier
- If customer manages circuit, advise them to contact their ISP and close the ticket
- Confirm physical layer
- Reboot phone
- Ping the phone's local IP and see response times
- If behind an Edgewater, try plugging the phone directly into a LAN port on the Edgewater. Check survivability.
- If using headset, try with handset and speakerphone
- Replace ethernet cable
- Move phone to a known-good location
- Any issues with the local switch?
- For site-wide LAN delays, investigate the Edgewater - Gather data re. up time, load and switch CPU (see higher tier if not sure how to do this.)
- If remote, provide firewall guide and advise the user to call their ISP.
- If not, investigate local/physical layer.
- Reboot phone
- Ping the phone's local IP and see response times
- If behind an Edgewater, try plugging the phone directly into a LAN port on the Edgewater
- If using headset, try with handset and speakerphone
- Replace ethernet cable
- Move phone to a known-good location
- Any issues with the local switch?
- For site-wide LAN delays, investigate the Edgewater - Gather data re. up time, load and switch CPU (see higher tier if not sure how to do this.)
- If so, identify the source
- OCOM
Analyzing SIP Messaging for Delays
In this example, the callee would have experienced a brief ring then a missed call that goes right to voicemail.
This is an example of a delay in signaling. The site (172.25.1.114) does not respond to the invite attempts sent by east02.voip.evolveip.net (64.27.39.168) in a timely manner. The response comes in after 6 seconds, but we are already CANCELing the call at that time. The call set up is thus ended and the call ends before it can begin.
End user experience is that the the phone would either do a half ring or no ring at all, and the call would go to voicemail.
This is an example of a normal call. Healthy response times happen in miliseconds. Note that here, the site (172.25.1.114) sends an invite to east02.voip.evolveip.net (64.27.39.168) which is responded to in .002 seconds (as opposed to 6 full seconds above). This is proper and allows the call to start up and connect.
Additional Troubleshooting Steps
If no packet loss, jitter or SIP messaging has been found to account for the delay, you may have to investigate the physical layer:
- Try to replicate the issue.
- Remove variables.
- If using a headset, try speaker and handset
- Move the phone to another, known-good port. If in the office, and no packet loss is showing on the Edgewater or carrier, it's possible there may be an issue with the cable, port or switch.
- Check the Edgewater for latency or down survivability.
- For customers that have dedicated call recording servers, we can pull their recordings and listen to locate the delay (Note: Don't mention this to the customer, though. This is just a troubleshooting step on our side) - List of customers that have dedicated servers: Orecx Call Recording Server List
- Based on the originating source of packet loss, your next steps may vary:
- Client Side
- Check for circuit errors, dropped packets
- If circuit is EIP responsibility, then open a ticket with the circuit provider
- If circuit is client responsibility, tell the customer they need to open a ticket with their ISP/WAN provider
- If circuit is clean,
- If Evolve owned or managed CPE, check equipment (CPU utilization, physical connections)
- If not Evolve owned or managed equipment, request customer to have their IT staff review
- Check for circuit errors, dropped packets
- PSTN Side - Open ticket with Carrier
- Evolve IP network - Document findings and elevate the ticket to the next Tier.
- Client Side
- When to send to Tier 2:
- Chronic, replicatable issues for which the client pushes back that the issue's on us or they don't believe the issue is from off our platform
- Issues that can't be resolved with Tier 1 resources (always present issue in the group chat and check with team leads before elevating to Tier 2)
- If the customer's listed on Orecx Call Recording Server List, you can mention this to Tier 2, that recordings can be pulled, but again, don't mention this to the customer.