PSTN Failover

Texas:

dial-peer voice 2001 voip
destination-pattern 2...
session-target ipv4:10.10.10.2
preference 0

dial-peer voice 2002 pots
destination-pattern 2...
port 1/0:1
no digit-strip
prefix 1408666
preference 1

How to match inbound dial-peer

When a gateway recieves an inbound call , it will try to match a dial-peer according to the following order:

1- DNIS using "incoming called-number"
2- Caller-id (ANI) using "answer-address"
3- Incoming POTS using the port in the dial-peer
4- If not match then use dial-peer 0

Dial-peer 0 is a default dial peer with the following characteristics:

- No QoS
- No DID
- All Codecs
- VAD is on

SIP

SIP is a text-based, application-layer control signaling protocol that is used for setting up, modifying, and tearing down multimedia sessions between participants. It is defined in RFC 3261 (which obsoletes RFC 2543) and takes advantage of elements of HTTP, SMTP, and SDP.

In the process of setting up and tearing down sessions, SIP supports the capability to determine a user’s location and the user’s willingness to communicate, and ascertain appropriate media parameters. By default, SIP uses port 5060 for TCP/UDP and port 5061 for TLS over TCP.

Various elements contribute to SIP’s capability to establish, manage, and terminate sessions, and these include :

• User agent (UA): This is an endpoint that can act as both a user agent client (UAC) and a user agent server (UAS). A UA could, for example, be a SIP IP phone.

• UAC: This is a logical entity that initiates and sends requests, such as those specifying the INVITE method. The UAC is a logical role, so it lasts only for the duration of a SIP transaction. A transaction comprises all messages beginning with the initial request message and ending with the final response message.


• UAS: This is an entity that responds to a SIP request by accepting, rejecting, or redirecting the request. The UAS role also lasts only for the duration of the transaction.


• Redirect server: This is a (user agent) server that provides address translation and redirects clients to alternative destination addresses. It does this by sending 3xx responses to requests.


• Proxy server: A SIP proxy server’s primary role is to provide routing, but it can also enforce policies, provide features, and authenticate and authorize users.


• Registrar server: This allows users to register their current locations (this information is added to a location service). Registrar servers use the information to provide a lookup service that allows SIP UAs to be located.


• Location service: This is created by a registrar server and is populated with bindings of address-of-record (AOR, a user’s “public” address) to contact addresses. The location service can be used by proxy or redirect servers to retrieve information relating to a called party’s possible locations.


• Back-to-back user agent (B2BUA): This is an entity that receives requests but, to process them, has itself to generate requests. Because it both processes and generates requests, its functionality is a combination of that of a UAC and a UAS. Note that it differs from a proxy server in that it must participate in all requests corresponding to dialogs that it has set up. A dialog is a SIP peer-to-peer relationship between UAs that exists for some time.


• Presence server: This is a physical device that is aware of the willingness and capability of tracked parties (presentities) to communicate across a set of devices, and distributes this information to interested parties (watchers). Information about a tracked party’s willingness and capability to communicate is known as presence information.

There are two SIP message types

• Request: This is a message sent by a client to a server that is used to invoke certain operations or functions.


• Response: This is a message sent by a server to a client that indicates the status of the request received from the client.

As already mentioned, request messages can invoke certain functions on a server. These functions are known as methods. A method is specified in a request message sent by a client to a server, and they include

• INVITE: When a UAC wants to initiate a session, it sends an INVITE request to a server. When this arrives at a UAS (it may be forwarded by proxies), the UAS processes it and sends an appropriate type of response message .


• ACK: This message is sent in reply to a final response message from a server.


• BYE: Used to terminate a session.


• CANCEL: A CANCEL request is used to terminate a pending request (a request for which a final response has not yet been received). When a caller’s UA (UAC) wishes to hang up when there has not yet been a final response to an INVITE, the session will still be pending, so a CANCEL will be sent. In this case, the CANCEL constitutes a request to stop ringing.


• REGISTER: This message is used to register contact information. When a user wants to initiate a session with another user, SIP must locate the host at which the destination user is currently reachable. The location of the host is often determined by a proxy or redirect server because these servers will frequently receive requests that they are then responsible for forwarding to the destination user’s host.
  To locate the destination user host, the server consults a location service, the purpose of which is to provide address bindings. These address bindings consist of URI to user agent at which a user is currently located.
  Address bindings can be created using a process called registration. Registration entails sending REGISTER messages to an element called a registrar server. As previously mentioned, a registrar server is a front end for the location service that both reads and writes mappings based on REGISTER messages.


• OPTIONS: A UA can query another UA or SIP server about its capabilities using an OPTIONS request. In this way, a client can find out capabilities such as supported methods, content types, codecs, and so on before, for example, sending an INVITE specifying required options.


• INFO: This method is defined in RFC 2976 and can be used to carry session-related control information such as ISUP or ISDN signalling information.
  
  There are six different ranges of response:
  - 1XX: Responses in this range are provisional or informational.
  - 2XX: These indicate success
  - 3XX: These responses indicate redirection.
  - 4XX: These responses indicate client errors.
  - 5XX: These indicate server errors.
  - 6XX: These indicate global failures.

The following Figure illustrates a typical SIP session established via a proxy server.

Media Gateway Control Protocol - MGCP

Media Gateway Control Protocol (MGCP) is defined in RFC 3435 (which obsoletes RFC 2705), and it specifies an application programming interface and text-based master/slave protocol used by a media gateway controller (MGC) or Call Agent to control media gateways (MG). MGCP is based on two other (now obsolete) protocols, the Simple Gateway Control Protocol (SGCP) and Internet Protocol Device Control (IPDC).

MGCP MGCs and MGs can be described as follows:

• MGC/Call Agent: This element possesses call control intelligence and controls MGs. An MGC/Call Agent could,for example, be a Cisco CallManager.



• MG: This device provides translation between data packets and audio signals received over VoIP networks and other networks, such as the PSTN. A media gateway could, for example, be an IOS router with analog or digital voice ports.

Media gateways can be classified depending on the connectivity they provide. For example, a media gateway that terminates trunks connecting to the telephone network can be referred to as a trunking gateway, and a media gateway that provides analog connections to phones can be referred to as a residential gateway.

MGCP specifies a connection model involving endpoints and connections:

• Endpoint: MGCP media gateways contain endpoints,which are sources/destinations for data.Endpoints can be physical, such as interfaces terminating trunks connecting to a PSTN or interfaces terminating POTS connections to PBX, key systems, or telephones. Endpoints can also be virtual endpoints, such as audio content sourced from a server.



• Connection: This is an association between endpoints for the purpose of transmitting data, and can be either piont-to-point or multipoint in nature.

MGCs/Call Agents and MGs use several commands and responses (or verbs) to communicate with each other:

• EndpointConfiguration (EPCF): A Call Agent sends this message to a gateway to specify signal encoding that will be received by an endpoint. This message could, for example, be used to specify whether audio calls will be encoded
  using mu-law or a-law.


• CreateConnection (CRCX): This command creates a connection between two endpoints. The connection is created based on parameters included with the command, such as codec, allowable bandwidth, use of echo cancellation, silence suppression, gain control, and so on.


• ModifyConnection (MDCX): This is used to modify the parameters associated with a connection that was previously created.


• DeleteConnection (DLCX): The Call Agent can send this command to inform a gateway that it should terminate a connection, and a gateway can send this command to indicate that a connection can no longer be sustained. In response to a DeleteConnection command, a media gateway sends statistics associated with the connection.


• NotificationRequest (RQNT): This is sent by a Call Agent to instruct a gateway to inform it when specific events occur in an endpoint. These events could, for example, be on-hook/off-hook status changes or the reception of certain tones.


• Notify (NTFY): A media gateway uses this command to inform a Call Agent when requested events occur.


• AuditEndpoint (AUEP): The Call Agent sends the AuditEndpoint command to the gateway to audit the status of an endpoint. The Call Agent can, for example, find out signal status, event status, bearer information, and endpoint apabilities using this command.


• AuditConnection (AUCX): The Call Agent sends this command to the gateway to find out the status of a connection.Connection status information that can be retrieved using this command includes call ID, connection mode, and connection parameters


• RestartInProgress (RSIP): The gateway sends this command to the Call Agent to inform the Call Agent that it is taking an endpoint or group of endpoints out of service or is returning an endpoint or group of endpoints to service.

MGCP messages are sent on UDP port 2427. However, TCP port 2428 is used to exchange keepalives between an MG and CallManager, as well as for MGCP PRI/BRI backhaul between a media gateway and CallManager.

MGCP PRI/BRI backhaul is used to transport ISDN Q.931 (D channel) signalling information from the gateway to the Call Agent (CallManager). ISDN Q.921 signalling is terminated on the gateway and is not backhauled to the Call Agent.

MGCP is a popular gateway control protocol for several reasons, including the following:

• MG configuration is simplified because call control and dial plan are centralized on the MGC.
• Dial plan management and administration is simplified due to its centralization on the MGC.
• Cisco MGCP MG can be configured to switch over from a primary to backup CallManager in the event of a failure of the primary (there can be two backups in addition to the primary). Similarly, Cisco MGCP gateways can be configured to fall back to using H.323 for call control in case gateways are unable to communicate with any CallManagers.
• Active calls are preserved when an MGCP gateway switches over to a backup CallManager.
• Active analog and T1 CAS calls are preserved in the event of fallback to H.323. Any active PRI calls that are being backhauled to CallManager are not preserved during fallback.