CUBE

A Session Border Controller (SBC) is a network element deployed to protect SIP based Voice over Internet Protocol (VoIP) networks. A Cisco Unified Border Element (CUBE) is a session border controller for enterprises. All CUBEs are SBC’s, but not all SBC’s are CUBEs. Service providers use session border controllers in their networks, but the requirements carriers are much different than for enterprises, so they usually run some interesting solutions to accommodate these requirements. In most networks, the CUBE is what the calls will contact first. Usually CUBEs are configured to be like train stations for the calls that arrive, by directing them to specific destinations within the environment using specific configuration.

SIP (Session Initiation Protocol) is an ASCII based standardized protocol used by phone calls traveling across IP networks. SIP was developed by the Internet Engineering Task Force (IETF) to address the evolving needs of IP-based communications. Native support for mobility, interoperability and multimedia were among the drivers behind SIP's development. SIP complements other communications protocols, such as Real-Time Transport Protocol (RTP) and Real-Time Streaming Protocols (RTSP), used in IP-based sessions.

SIP itself does not provide communication services. Instead, the protocol's specification defines interoperable implementations of SIP features, called primitives, that can be used to facilitate different services. Primitives allow additional information to be embedded in a SIP message, such as linking a user's photo to directory information to enable media-rich caller ID. SIP also supports name mapping and redirection services, which are two key ways the protocol enables mobility. Users and endpoints are detected with a single identifier, known as a uniform resource identifier (URI), which is independent of their network location. URIs are alphanumeric, using a syntax that looks more like an email address than a phone number or IP address.

Like HTTP or SMTP, SIP works in the application layer of the Open Systems Interconnection (OSI) communication model. SIP is a request-response protocol, receiving requests from clients and responses from servers. Requests can be sent through any transport protocol, such as UDP, SCTP or TCP. SIP determines the end system to be used for the session, the communication media and media parameters, and whether the called party agrees to engage in communication. Once these are assured, SIP establishes call parameters at either end of the communication, also handling call transfer and termination.

The CUBEs utilize dial-peer groups to direct voice traffic to the necessary servers.

Understanding SIP URI

We utilize SIP URI’s to route calls. A SIP URI is similar to user's SIP phone number. SIP URIs in their simplest form are expressed as user@host. The SIP URI resembles an email address and is written in the following format:

• sip:user@host:port

  • user is often in numeric form like a telephone number when used on CUBE

  • host can be an IP address or a domain name

  • Port can specify a specific TCP or UDP port number

Example SIP URIs:

16282806699@sip.vo.esv1.aircom.io

35316971830@sip.vo.edn1.aircom.io

+13054003676@81.146.227.134

Next up are dial-peer groups (DPG). They are configured in a similar fashion. You define the dial-peer groups, add dial-peer you wish to match to in said group, then tie the group to the desired dial-peers. The major advantage of the dial-peer groups is that you can group outbound dial-peers based on an incoming dial-peer matching requirement. Usually this results in the elimination of configuring extra dial-peers to achieve specific call routing behaviors.