A place to ask questions, connect with others, and stay in the know
Thank you for your reply.
------------------------------Charis SideridisIntracom S.A. Telecom Solutions------------------------------
Another question popped up.
Each edge has a SIP trunk attached.
Edge 1 -> Trunk 1
Edge 2 -> Trunk 2
We had an issue where edge 2 went offline and in the meantime the tie trunk between those two edges was missing (from previous incident). There were no inbound and outbound calls during the time period the second edge was offline.
The outbound route we use, uses trunk 1 and trunk 2 in sequential distribution pattern.
My questions are:
Shouldn't all users be able to make outbound calls using trunk 1, through edge 1?
Shouldn't incoming calls coming from trunk 1, be routed to the CC? (edge 1 was sending a 404-no available trunks.Support claimed it was due to the tie-trunk missing)
I mean, how does the tie-trunk affect call routing?
Yes, you should be able to build it in a way that as long as you have one viable Edge that the calls will still route successfully. This is hard to analyze through this forum as it leads into a lot of questions about your setup. For example, I would not normally expect you to have a dedicated trunk per Edge; however, this may be a requirement of your service provider. Are you able to reproduce this issue by taking Edges out of service? I would suggest doing some simulated tests to ensure your trunking is operating as expected.
There are various segments to each call - when a call is delivered to an Edge for the Contact Center, it is often going to go to IVR first - the Edge that receives the call is likely going to be selected to perform the IVR. Once the call is agent assigned the call needs to be extended to the agent. The agent's active station contributes to how this is performed. If you are using a managed station or WebRTC the station should have connections to two Edges. When both Edges are operational the Edge that handles the IVR will likely extend the call through the intra-edge trunk to the Edge that is the primary Edge for the station. When an Edge is offline or taken out of service you would expect the stations to rebalance so that only active and online Edges are assigned to stations - in which case in a two Edge scenario where one Edge is offline all stations and all inbound calls should be managed by the same singular Edge.
Shouldn't all users be able to make outbound calls using trunk 1, through edge 1? Assuming that the station was also rebalanced to the viable Edge - yes.
Shouldn't incoming calls coming from trunk 1, be routed to the CC? (edge 1 was sending a 404-no available trunks.Support claimed it was due to the tie-trunk missing) Yes, did the call get an IVR or did it fail on the initial INVITE or fail when it transfered to an station/agent?
I mean, how does the tie-trunk affect call routing? The tie trunk is used to extend calls between Edges as mentioned above. The carrier will select and inbound Edge based on their routing logic but will often perform the IVR locally, but can use the intra-edge trunk to extend the call to the agent's station.
------------------------------Charis SideridisIntracom S.A. Telecom SolutionsOriginal Message:Sent: 12-08-2020 11:55From: Phil WhitenerSubject: Intra-edge communicationIt sounds like you are on the right path. Edges being on separate networks is fine; in addition to the media ports you listed also see that the Ports and services page you referenced also have TLS/8063 (TLS used TCP). The TLS/8063 connection is used for SIP signaling and the SRTP range is used for media. It is also important to note that although Edges can be on separate networks you cannot have a NAT between Edges. When you say "this communication will go though the Cloud"... can you provide more clarification? Does that mean you will be using an Internet connection between Edges -- or possibly an MPLS cloud used for your internal corporate network. As long as they are communicating with real IPs with each other; that can be private IPs or public IPs, but the IP must be applied directly to the Edge's network interface - however, a NAT applied at a firewall is not acceptable and will cause media to fail.You can use a third port for inter-Edge communication if you want; however, it is not required. Whenever you use multiple network interfaces you have to deal with routing and you often introduce more constraints with more active interfaces. By default the Edge uses a single routing table - so only one default route should be assigned. Static Routes can be used, as you brought up, to control routing on various interfaces. However, you can work with Care to enable source based routing on your org (this is a per org setting, not per Edge) which allows you to use multiple default gateways. Multiple default gateways are more advantageous for inbound client connections on various interfaces more than it is for inter-Edge communication where the source and destination IPs are known.Configuration for setting up default routes are listed here: https://help.mypurecloud.com/articles/configure-network-interface-edge/------------------------------Phil WhitenerGenesys - EmployeesOriginal Message:Sent: 12-08-2020 04:29From: Charis SideridisSubject: Intra-edge communicationHello,We have 2 edges within a Site and each edge has a separate SIP trunk. The WAN ports are used for communication with the Cloud and Port 2 for SIP trunking. WAN port is the Network Interface for Internal Edge Communication too. We had some issues recently with inbound calls ( one edge offline and the other edge sending 404 no trunks available, SIP error messages towards the provider) and I would like some clarification concerning the intra-edge communication.In order to have both edges, that belong to different networks, communicating with each other, what is needed?According to Ports and services to configure on your company firewall - Genesys Cloud Resource CenterThe port range 16384-32768 (SRTP) must be available for incoming requests at each edge in order to have intra-edge communication. Since they do not belong to the same network, this communication will go through the Cloud. Is it possible to add a static route at each WAN interface in order to bypass the cloud? Will that work?Moreover, is it possible to use the third port of each edge for intra-edge communication only, lying on the same network?Thanks#Implementation#Telephony------------------------------Charis SideridisIntracom S.A. Telecom Solutions------------------------------
Thanks Phil for your time,
It is still not clear to me concerning the outbound flows. In our case, a WebRTC ( having edge 1 as primary connection) could not make a call at all. The other edge as mentioned before, was offline. I presume the call flow would be:
Agent A ---->Edge 1---->Trunk 1----->Outside world
That didn't happen. Anyway, thanks again for your time.
I would definitely go back and test - after hours take Edge 2 out of service and see if the issue still exists.
Is there a compelling reason to have a trunk for each Edge? It would likely be preferred to have only one trunk and assign it to both Edges. Are the trunks identical except for the Edge that they are assigned to?
Every year, Genesys® delivers more than 70 billion remarkable customer experiences for organizations in over 100 countries. Through the power of the cloud and AI, our technology connects every customer moment across marketing, sales and service on any channel, while also improving employee experiences. Genesys pioneered Experience as a ServiceSM so organizations of any size can provide true personalization at scale, interact with empathy, and foster customer trust and loyalty. This is enabled by Genesys Cloud™, an all-in-one solution and the world's leading public cloud contact center platform, designed for rapid innovation, scalability and flexibility. Visit www.genesys.com.