HI guys

Can someone please help me understand the negotiation of the Edge, Chrome Browser and Genesys Cloud with regards to WebRTC?

Am I correct that when an inbound call arrives to be delivered to an agent, the Edge contacts Google STUN and provides it's public and private IPs, when an agent is targeted, their own browser does the same.  At that point, is it the browser or the Edge that tries to use the LAN IP vs the public IP for setting up the call/media?  If a private IP is showing in the list from the Edge to STUN, will the browser always try that private IP first, regardless of whether or not the private IPs are in the same subnet etc?  If a pair/match can't be made at the STUN level it will use TURN as a relay fall-back?
#ArchitectureandDesign
#Telephony

------------------------------
Vaun McCarthy
------------------------------

Hi Vaun,

I did quite a bit of work trying to get media route via a private MPLS, so some of my findings may be of use?

When the WebRTC agent registers with PureCloud and the ICE data is passed to the Edge it will contain information on where/how to send the media to the client.  This will have a list in order private,public,relay to where the edge should try and send the media (I have changed IPs):

i3ice::Session::on_remote_candidates_received_from_peer(): New candidates received from remote peer:

[MediaID, ComponentID, CandidateType, Address]

0, 1, host, 192.168.0.10:52037 0, 1, srflx, 190.180.180.10:52249 0, 1, srflx, 190.180.180.10:52250 0, 1, relay, 34.200.150.10:21294

Then before sending the media the Edge will try and ping one of the addresses starting from the left, the private address.  Once it succeeds it will use this for all media streams:

i3ice::Session::on_round_trip_failed(): Round trip between LocalAddress=EDGEIP:20306 and RemoteAddress=192.168.0.10:52037 timed out.

i3ice::Session::on_round_trip_failed(): Round trip between LocalAddress=EDGEIP:20306 and RemoteAddress=190.180.180.10:52249 timed out.

..

i3ice::Session::on_connectivity_check_succeeded(): Outgoing Connectivity Check succeeded. MediaID=0, ComponentID=1, LocalAddress=EDGEIP:20306, RemoteAddress=34.200.150.10:21294,

In this example, the private and public addresses fail, so it falls back to the working relay address

Hope this is of some use

Thanks Luke

------------------------------
Luke Mitchell
Conn3ct
------------------------------

Original Message:
Sent: 06-21-2020 15:36
From: Vaun McCarthy
Subject: STUN/TURN/ICE

HI guys

Can someone please help me understand the negotiation of the Edge, Chrome Browser and Genesys Cloud with regards to WebRTC?

Am I correct that when an inbound call arrives to be delivered to an agent, the Edge contacts Google STUN and provides it's public and private IPs, when an agent is targeted, their own browser does the same.  At that point, is it the browser or the Edge that tries to use the LAN IP vs the public IP for setting up the call/media?  If a private IP is showing in the list from the Edge to STUN, will the browser always try that private IP first, regardless of whether or not the private IPs are in the same subnet etc?  If a pair/match can't be made at the STUN level it will use TURN as a relay fall-back?
#ArchitectureandDesign
#Telephony

------------------------------
Vaun McCarthy
------------------------------

Thanks Luke, that does confirm partly what I was looking at too.

Just to confirm, the candidate lookup is only done at registration, ie when the agent first logs in for the shift?  Does it check on each subsequent inbound/outbound call or retain that target for all calls until they next logout/in again?

------------------------------
Vaun McCarthy
NTT New Zealand Limited
------------------------------

Original Message:
Sent: 06-22-2020 05:35
From: Luke Mitchell
Subject: STUN/TURN/ICE

Hi Vaun,

I did quite a bit of work trying to get media route via a private MPLS, so some of my findings may be of use?

When the WebRTC agent registers with PureCloud and the ICE data is passed to the Edge it will contain information on where/how to send the media to the client.  This will have a list in order private,public,relay to where the edge should try and send the media (I have changed IPs):

i3ice::Session::on_remote_candidates_received_from_peer(): New candidates received from remote peer:

[MediaID, ComponentID, CandidateType, Address]

0, 1, host, 192.168.0.10:52037 0, 1, srflx, 190.180.180.10:52249 0, 1, srflx, 190.180.180.10:52250 0, 1, relay, 34.200.150.10:21294

Then before sending the media the Edge will try and ping one of the addresses starting from the left, the private address.  Once it succeeds it will use this for all media streams:

i3ice::Session::on_round_trip_failed(): Round trip between LocalAddress=EDGEIP:20306 and RemoteAddress=192.168.0.10:52037 timed out.

i3ice::Session::on_round_trip_failed(): Round trip between LocalAddress=EDGEIP:20306 and RemoteAddress=190.180.180.10:52249 timed out.

..

i3ice::Session::on_connectivity_check_succeeded(): Outgoing Connectivity Check succeeded. MediaID=0, ComponentID=1, LocalAddress=EDGEIP:20306, RemoteAddress=34.200.150.10:21294,

In this example, the private and public addresses fail, so it falls back to the working relay address

Hope this is of some use

Thanks Luke

------------------------------
Luke Mitchell
Conn3ct

Original Message:
Sent: 06-21-2020 15:36
From: Vaun McCarthy
Subject: STUN/TURN/ICE

HI guys

Can someone please help me understand the negotiation of the Edge, Chrome Browser and Genesys Cloud with regards to WebRTC?

Am I correct that when an inbound call arrives to be delivered to an agent, the Edge contacts Google STUN and provides it's public and private IPs, when an agent is targeted, their own browser does the same.  At that point, is it the browser or the Edge that tries to use the LAN IP vs the public IP for setting up the call/media?  If a private IP is showing in the list from the Edge to STUN, will the browser always try that private IP first, regardless of whether or not the private IPs are in the same subnet etc?  If a pair/match can't be made at the STUN level it will use TURN as a relay fall-back?
#ArchitectureandDesign
#Telephony

------------------------------
Vaun McCarthy
------------------------------

I have not tested fail over yet with these setups, you would hope that it would check this before each call so if the private address was not available it would still succeed on either the public or relay but it would be great to confirm how this functions

------------------------------
Luke Mitchell
Conn3ct
------------------------------

Original Message:
Sent: 06-22-2020 16:44
From: Vaun McCarthy
Subject: STUN/TURN/ICE

Thanks Luke, that does confirm partly what I was looking at too.

Just to confirm, the candidate lookup is only done at registration, ie when the agent first logs in for the shift?  Does it check on each subsequent inbound/outbound call or retain that target for all calls until they next logout/in again?

------------------------------
Vaun McCarthy
NTT New Zealand Limited

Original Message:
Sent: 06-22-2020 05:35
From: Luke Mitchell
Subject: STUN/TURN/ICE

Hi Vaun,

I did quite a bit of work trying to get media route via a private MPLS, so some of my findings may be of use?

When the WebRTC agent registers with PureCloud and the ICE data is passed to the Edge it will contain information on where/how to send the media to the client.  This will have a list in order private,public,relay to where the edge should try and send the media (I have changed IPs):

i3ice::Session::on_remote_candidates_received_from_peer(): New candidates received from remote peer:

[MediaID, ComponentID, CandidateType, Address]

0, 1, host, 192.168.0.10:52037 0, 1, srflx, 190.180.180.10:52249 0, 1, srflx, 190.180.180.10:52250 0, 1, relay, 34.200.150.10:21294

Then before sending the media the Edge will try and ping one of the addresses starting from the left, the private address.  Once it succeeds it will use this for all media streams:

i3ice::Session::on_round_trip_failed(): Round trip between LocalAddress=EDGEIP:20306 and RemoteAddress=192.168.0.10:52037 timed out.

i3ice::Session::on_round_trip_failed(): Round trip between LocalAddress=EDGEIP:20306 and RemoteAddress=190.180.180.10:52249 timed out.

..

i3ice::Session::on_connectivity_check_succeeded(): Outgoing Connectivity Check succeeded. MediaID=0, ComponentID=1, LocalAddress=EDGEIP:20306, RemoteAddress=34.200.150.10:21294,

In this example, the private and public addresses fail, so it falls back to the working relay address

Hope this is of some use

Thanks Luke

------------------------------
Luke Mitchell
Conn3ct

Original Message:
Sent: 06-21-2020 15:36
From: Vaun McCarthy
Subject: STUN/TURN/ICE

HI guys

Can someone please help me understand the negotiation of the Edge, Chrome Browser and Genesys Cloud with regards to WebRTC?

Am I correct that when an inbound call arrives to be delivered to an agent, the Edge contacts Google STUN and provides it's public and private IPs, when an agent is targeted, their own browser does the same.  At that point, is it the browser or the Edge that tries to use the LAN IP vs the public IP for setting up the call/media?  If a private IP is showing in the list from the Edge to STUN, will the browser always try that private IP first, regardless of whether or not the private IPs are in the same subnet etc?  If a pair/match can't be made at the STUN level it will use TURN as a relay fall-back?
#ArchitectureandDesign
#Telephony

------------------------------
Vaun McCarthy
------------------------------