Home > Communications > MC Network Administrator Guides > Other Topics > MC Traffic Flow Breakdown

MC Traffic Flow Breakdown

Overview

When troubleshooting or working with voice technologies, it is important to understand how a phone call is established and where voice traffic will travel. This article provides a breakdown of call setup and voice traffic flow on the MC platform.

MC Technologies

A number of different protocols are needed to set up and make phone calls. If you take a packet capture upstream of an active endpoint you will see the following protocols in use:

  • SIP - The Session Initiation Protocol is the control protocol used for setting up the call. It is used to determine the codecs that will be used, and provides each endpoint the possible paths that can be used for communication.
  • STUN - Session Traversal Utilities for NAT provide a means for endpoints to determine what their public IP address is, and how NAT may be modifying their traffic.
  • ICE - Interactive Connectivity Establishment allows the phones to determine what different paths call communication can take, so the phone can choose the most appropriate path.
  • RTP - The Real-time Transport Protocol is used to carry audio between phones.
  • RTCP - The Real-time Transport Control Protocol provides information on the data stream between endpoints. This includes statistics on the quality of the connection.

Traffic Flow

The following sections describe how traffic will flow in different scenarios.

There are four basic types of phone calls:

  • Extension to extension calls on the same LAN.
  • Extension to extension calls across the Internet.
  • Extension to extension calls with a VPN or other route.
  • Calls to a public phone number.

In all of these scenarios you will see management traffic from the phone being sent to the Meraki Dashboard, the differences only begin to arise when actually making phone calls.

Extension to Extension Calls on the Same LAN

One of the most common scenarios is an extension to extension call between two phones on the same LAN. In this scenario we have two phones connected behind a single upstream device on the same subnet. In terms of call setup, you will see SIP and STUN messages from the phones to the Meraki Dashboard.

The following traffic will be sent, in order:

  1. SIP messages are sent between the phones and dashboard, to negotiate the parameters of the call (e.g. the codec to be used).
  2. STUN messages are sent by the phones, to discover that they have the public IP address of 192.195.83.200. From there, they will determine whether or not they can establish reliable communication based on the NAT.
  3. The phones will determine what communications paths they can utilize. Specifically, Phone A will determine that it has two possible paths to Phone B; either via Phone B's public IP address of 192.195.83.200, or its local IP address of 192.168.128.11. Phone A will attempt to connect via both of these paths. If connectivity is established on a given path, that path may be used for the call. In the case that multiple paths are viable, the phone will prioritize the local connection.
  4. Once the call is established, you will see RTP traffic flowing directly between Phone A's IP address of 192.168.128.10 and Phone B's IP Address of 192.168.128.11.

Extension to Extension Calls across the Internet

Traffic generated by extension-to-extension calls between phones in remote networks looks very similar to extension-to-extension calls within the same LAN, though the addressing will be different. In this scenario when Phone A tries to call Phone B, differences between this and the previous scenario will start to emerge when determining possible media paths.

  1. Phone A determines that there are two paths that it can take to Phone B - via B's public IP address of 192.195.83.200 or via its local IP address of 192.168.128.11.
  2. Phone A attempts to connect via both the public and private IP address. In this scenario, the connection between the local IP addresses will fail, so Phone A is forced to utilize the public IP address of the remote Phone B.
  3. RTP traffic flows through the upstream NAT and across the Internet to reach Phone B via its public IP address. Return traffic from Phone B follows the reverse route.

Because of NAT it is important to note what the address will look like at each step of the way:

  • On Phone A's local network, the source address of the RTP traffic is 172.16.1.15 and the destination address is 192.195.83.200.
  • At the Local MX65, the source address of the RTP traffic is re-written with the MX65's WAN address of 192.168.83.201, and the destination address remains as 192.195.83.200.
  • Upon reaching the remote MX65, the destination IP address is re-written from 192.195.83.200 to the local IP address of Phone B. Any captures taken on the LAN of the remote MX will show a source IP of 192.195.83.201 and a destination IP address of 192.168.128.11.

Extension to Extension Calls with a VPN (or other route)

In this scenario, there two phones behind two different MX Security Appliances. In this case there is a Meraki AutoVPN tunnel connecting these networks. 

This traffic flow also applies to site-to-site connections other than Meraki AutoVPN, such as a 3rd party VPN tunnel or an MPLS link.

  1. Phone A determines that there are two paths that it can take to Phone B - via B's public IP address of 192.195.83.200 or via its local IP address of 192.168.128.11.
  2. Phone A attempts to connect via both the public and local paths. If both paths pass the connectivity tests, the phone will prioritize the local (VPN) connection. If the phone is unable to establish a connection across the VPN tunnel, the phone can instead use the public IP route described earlier.
  3. Once the call is established, you will see RTP traffic flowing directly between Phone A's IP address of 192.168.1.15 and Phone B's IP Address of 192.168.128.11.

Calls to a Public Phone Number

Calls made to an external phone number will use the SIP trunk(s) you have configured in your Dashboard network. The same protocols used for extension to extension calls will be used to establish this call, with a few key differences:

  • ICE is not used for connection establishment. Instead the phone will use STUN to determine NAT type and how it can communicate with other devices.
  • The connection information for the remote device is advertised via SIP from the phone.
  • The RTP stream goes through your service provider to the Publicly Switched Telephone Network (PSTN) which handles completing the call to the remote endpoint.
You must to post a comment.
Last modified
13:29, 8 Aug 2016

Tags

This page has no custom tags.

Classifications

This page has no classifications.

Article ID

ID: 4976

Contact Support

Most questions can be answered by reviewing our documentation, but if you need more help, Cisco Meraki Support is ready to work with you.

Open a Case