SIP (Session Initiation Protocol) -- Introduction

Introduction

The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying, and terminating multimedia sessions(voice/video calls) with one or more participants.

SIP support following five facets of establishing and terminating multimedia communications:

1. User Location: Determination of End System to be used for communication.
2. User Availability: Determination of the willingness of the called party to engage in communications
3. User Capabilities: Determination of the media and media parameters to be used.
4. Session Setup: “Ringing”, establishment of session parameters at both called and calling party.
5. Session Management: Including transfer and termination of sessions, modifying session parameters, and invoking services.


BASIC SIP CALL FLOW























Few Terms/Abbreviations

URI: Uniform Resource Identifier – ex: sip:abc@xyz.com
UAC - User Agent Client
UAS - User Agent Server
UA - User Agent
B2BUA - Back To Back Uger Agent (UAC + UAS): It is a logical entity that receives a request and processes it as a user agent server (UAS). In order to determine how the request should be answered, it acts as a user agent client (UAC) and generates requests. Unlike a proxy server, it maintains dialog state and must participate in all requests sent on the dialogs it has established. Since it is a concatenation of a UAC and UAS, no explicit definitions are needed for its behavior.


Dialog: A dialog is a peer-to-peer SIP relationship between two UAs that persists for some time. A dialog is established by SIP messages, such as a 2xx response to an INVITE request. A dialog is identified by a call identifier, local tag, and a remote tag. A dialog was formerly known as a call leg in RFC 2543.

SIP Transaction: A SIP transaction occurs between a client and a server and comprises all messages from the first request sent from the client to the server up to a final (non-1xx) response sent from the server to the client. If the request is INVITE and the final response is a non-2xx, the transaction also includes an ACK to the response. The ACK for a 2xx response to an INVITE request is a separate transaction.

Loose Routing: A proxy is said to be loose routing if it follows the procedures defined in RFC 3261 for processing of the Route header field. These procedures separate the destination of the request (present in the Request-URI) from the set of proxies that need to be visited along the way (present in the Route header field). A proxy compliant to these mechanisms is also known as a loose router.


Strict Routing: A proxy is said to be strict routing if it follows the Route processing rules of RFC 2543 and many prior work in progress versions of this RFC. That rule caused proxies to destroy the contents of the Request-URI when a Route header field was present. Strict routing behavior is not used in RFC 3261, in favor of a loose routing behavior. Proxies that perform strict routing are also known as strict routers.


Few salient points about SIP

• SIP is end-to-end, client-server session signaling protocol
  
• SIP clients use TCP or UDP typically using port 5060 to connect to SIP servers and other SIP endpoints.Most implementation use UDP.
• Transport-independent, because SIP can be used with UDP, TCP, ATM, TLS,SCTP & so on.
• Lightweight, in that SIP has only six methods, reducing complexity.
• Text-based, allowing for humans to read SIP messages.
• Involved only in the signaling portion of a communication session.
  
  

SIP Components

SIP Proxy Server
Relays call signaling, i.e. acts as both client and server operates in a transactional manner, i.e., it keeps no session state (stateless/stateful proxies??).
It helps route requests to the user's current location, authenticates and authorizes users for services, implements provider call-routing policies, and provides features to users."

Forking proxies needs to be stateful

SIP Redirect Server
Redirects callers to other servers

SIP Registrar
Accept registration requests (REGISTER) from users maintains user’s whereabouts at a Location Server (like GSM's HLR)

SIP Location Server
Used by a SIP redirect or proxy server to obtain information about a called party’s possible location (s)



SIP Call Flow (SIP Trapezoid)

SIP Methods

INVITE - Requests a session
ACK - Final response to the INVITE
OPTIONS - Ask for server capabilities
CANCEL - Cancels a pending request
BYE - Terminates a session
REGISTER - Sends user’s address to server

SIP Responses

1XX Provisional 100 Trying

2XX Successful 200 OK

3XX Redirection 302 Moved Temporarily

4XX Client Error 404 Not Found

5XX Server Error 504 Server Time-out

6XX Global Failure 603 Decline


SIP Header Fields

Request Line:
INVITE sip:marconi@radio.org SIP/2.0
(Method) Rx-URI SIP-VERSION

To:
The To header field first and foremost specifies the desired "logical" recipient of the request, or the address-of-record of the user or resource that is the target of this request. This may or maynot be the ultimate recipient of the request.

From:
The From header field indicates the logical identity of the initiator of the request, possibly the user's address-of-record.

Call-ID:
The Call-ID header field acts as a unique identifier to group together a series of messages. It MUST be the same for all requests and responses sent by either UA in a dialog. It SHOULD be the same in each registration from a UA.

From SIP RFC 3261 - The Call-ID header field uniquely identifies a particular invitation or all registrations of a particular client. A single multimedia conference can give rise to several calls with different Call-IDs, for example, if a user invites a single individual several times to the same (long-running) conference. Call-IDs are case-sensitive and are simply compared byte-by-byte.

The compact form of the Call-ID header field is i.
Examples:
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com
i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4


CSeq: (32 it)
The CSeq header field serves as a way to identify and order transactions. It consists of a sequence number and a method. The method MUST match that of the request.

From SIP RFC 3261 - A CSeq header field in a request contains a single decimal sequence number and the request method. The sequence number MUST be expressible as a 32-bit unsigned integer. The method part of CSeq is case-sensitive. The CSeq header field serves to order transactions within a dialog, to provide a means to uniquely identify transactions, and to differentiate between new requests and request retransmissions. Two CSeq header fields are considered equal if the sequence number and the request method are identical.
Example: CSeq: 4711 INVITE

Max-Forwards: (Default Value 70??)
The Max-Forwards header field serves to limit the number of hops a request can transit on the way to its destination. It consists of an integer that is decremented by one at each hop. If the Max-Forwards value reaches 0 before the request reaches its destination, it will be rejected with a 483(Too Many Hops) error response.

VIA:
The Via header field indicates the transport used for the transaction and identifies the location where the response is to be sent.

When the UAC creates a request, it MUST insert a Via into that request. The protocol name and protocol version in the header field MUST be SIP and 2.0, respectively. The Via header field value MUST contain a branch parameter. This parameter is used to identify the transaction created by that request. This parameter is used by both the client and the server.
The branch parameter value MUST be unique across space and time all requests sent by the UA.
The branch ID inserted by an element compliant with RFC3261 MUST always begin with the characters "z9hG4bK".

Via: SIP/2.0/UDP lab.high-voltage.org:5060;branch=z9hG4bKfw19b


Contact:
The Contact header field provides a SIP or SIPS URI that can be used to contact that specific instance of the UA for subsequent requests. The Contact header field MUST be present and contain exactly one SIP or SIPS URI in any request that can result in the establishment of a dialog. For the methods defined in Rfc3261 specification, that includes only the INVITE request.
Contact: ~~sip:n.tesla@lab.high-voltage.org~~ (~~X~~ encloes in angular bracket)

SIP Registeration

~~~~~ TBD~~~~~

SIP Redirection

SIP Routing

• A request from User Agent – A to User Agent – B may be routed through several proxies.
• Via Header: Each time a proxy forwards a message it appends a ‘Via’ Header to the list of forwarding proxies. It is useful to detect the routing loops.
• SIP Clients can add a Contact header so that each client can send them requests directly and therefore proxies are not guaranteed to be in the path of all request.
• Record Route Header: It may be desirable to follow the same route back. For example, proxy might be Billing Proxy and needs to have access to all the information regarding the call. When the proxies get the request then they insert the Record-Route header inserting their SIP URL.

More SIP Call Flows

TBD



FAQs

How SIP request is distinguished from response?

SIP - Redirect Servers

From SIP RFC 3261
8.3 Redirect Servers
In some architectures it may be desirable to reduce the processing load on proxy servers that are responsible for routing requests, and improve signaling path robustness, by relying on redirection.

Redirection allows servers to push routing information for a request back in a response to the client, thereby taking themselves out of the loop of further messaging for this transaction while still aiding in locating the target of the request. When the originator of the request receives the redirection, it will send a new request based on the URI(s) it has received. By propagating URIs from the core of the network to its edges, redirection allows for considerable network scalability.

A redirect server is logically constituted of a server transaction layer and a transaction user that has access to a location service of some kind (see Section 10 for more on registrars and location services). This location service is effectively a database containing mappings between a single URI and a set of one or more alternative locations at which the target of that URI can be found.

A redirect server does not issue any SIP requests of its own. After receiving a request other than CANCEL, the server either refuses the request or gathers the list of alternative locations from the location service and returns a final response of class 3xx. For well-formed CANCEL requests, it SHOULD return a 2xx response. This response ends the SIP transaction. The redirect server maintains transaction state for an entire SIP transaction. It is the responsibility of clients to detect forwarding loops between redirect servers.

When a redirect server returns a 3xx response to a request, it populates the list of (one or more) alternative locations into the Contact header field. An "expires" parameter to the Contact header field values may also be supplied to indicate the lifetime of the Contact data.

The Contact header field contains URIs giving the new locations or user names to try, or may simply specify additional transport parameters. A 301 (Moved Permanently) or 302 (Moved Temporarily) response may also give the same location and username that was targeted by the initial request but specify additional transport parameters such as a different server or multicast address to try, or a change of SIP transport from UDP to TCP or vice versa.

However, redirect servers MUST NOT redirect a request to a URI equal to the one in the Request-URI; instead, provided that the URI does not point to itself, the server MAY proxy the request to the destination URI, or MAY reject it with a 404.

If a client is using an outbound proxy, and that proxy actually redirects requests, a potential arises for infinite redirection loops.

Note that a Contact header field value MAY also refer to a different resource than the one originally called. For example, a SIP call connected to PSTN gateway may need to deliver a special informational announcement such as "The number you have dialed has been changed."

A Contact response header field can contain any suitable URI indicating where the called party can be reached, not limited to SIP URIs. For example, it could contain URIs for phones, fax, or irc (if they were defined) or a mailto: (RFC 2368 [32]) URL. Section 26.4.4 discusses implications and limitations of redirecting a SIPS URI to a non-SIPS URI.

The "expires" parameter of a Contact header field value indicates how long the URI is valid. The value of the parameter is a number indicating seconds. If this parameter is not provided, the value of the Expires header field determines how long the URI is valid. Malformed values SHOULD be treated as equivalent to 3600.

This provides a modest level of backwards compatibility with RFC 2543, which allowed absolute times in this header field. If an absolute time is received, it will be treated as malformed, and then default to 3600.

Redirect servers MUST ignore features that are not understood (including unrecognized header fields, any unknown option tags in Require, or even method names) and proceed with the redirection of the request in question.

SIP - Route and Record-route

SIP-Route and Record-route: My Google Doc

SIP versus H.323

H.323 v/s SIP

SIP - Books and Links

SIP Books


























Links

SIP RFC 3261
SIP RFC 3261: My Google Doc
SIP PSTN Call Flows: My Google Doc
IETF SIP Charter

SS7 - REQUEST and INDICATION primitives

primitive (Definition from webopedia.com)

A low-level object or operation from which higher-level, more complex objects and operations can be constructed. In graphics, primitives are basic elements, such as lines, curves, and polygons, which you can combine to create more complex graphical images. In programming, primitives are the basic operations supported by the programming language. A programmer combines these primitives to create more complex operations, which are packaged as functions, procedures, and methods.

CCS (Common Channel Signaling)

CAS (Channel Associated Signalling)

TBD

SS7-SCCP (Signalling Connection Control Part)

Introduction



Terms/Abbreviations
SLR
DLR

DTAP

SS7 - ISUP Notes

Fully Associated Signaling
Quasi Associated Signaling

SS7 - ISUP

Terms/Abbreviations

CIC: Circuit Identification Code
OPC: Origination Point Code
DPC: Destination Point Code
SLS: Signalling Link Selection

COT (Continuity Test): To test continuity of bearer channel



ISUP Messages

Complete list of ISUP messages and descriptions:
http://www.asknumbers.com/SS7ISUPMessages.aspx

ACM (Address Complete Message)
An Address Complete Message (ACM) is sent in the "backward" direction to indicate that the remote end of a trunk circuit has been reserved.

The originating switch responds to an ACM message by connecting the calling party's line to the trunk to complete the voice circuit from the calling party to the called party. The terminating switch sends a ringing tone to the calling party's line.



ANM (Answer Message)
When the called party answers, the destination switch terminates power ringing of the called line, removes audible ringing tone from the calling line and sends an Answer Message (ANM) to the originating switch. The originating switch initiates billing after verifying that the calling party's line is connected to the reserved trunk.



Call Progress Message (CPG)
CPG is sent in either direction during the set-up or active phase of the call, indicating that an event, which is of significance, and should be relayed to the originating or terminating access, has occurred.


Circuit Group Response Message (CQR)
Sent in response to a Circuit/CIC Group Query message to indicate the state of all circuits/CICs in a particular range.


Circuit Group Reset Acknowledgement Message (GRA)
GRA is sent in response to a Circuit/CIC Group Reset message indicating that the requested group of circuits/CICs has been reset. The message also indicates the maintenance blocking state of each circuit/CIC.


Confusion Message (CFN)
CFN is sent in response to any message (other than a confusion message) if the node does not recognize the message or detects a part of the message as being unrecognized.


Connect Message (CON)
CON is sent in the backward direction indicating that all the address signals required for routeing the call to the called party have been received and that the call has been answered.

Continuity Message (COT)
COT is sent in the forward direction indicating whether or not there is continuity on the preceding circuit(s) as well as of the selected circuit to the following exchange, including verification of the communication path across the exchange with the specified degree of reliability.

Facility Reject Message (FRJ)
FRJ is sent in response to a facility request message to indicate that the facility request has been rejected.

Information Message (INF)
INF is sent to convey information in association with a call, which may have been requested in an information request message.


Information Request Message (INR)
INF is sent by a node to request information in association with a call.

ISUP - Continuity bit

ISUP - CPG

SS7 - Flow Control - SIB LSSU

SS7 - Signalling Link Alignment

There are two forms of alignment procedures: the emergency procedure and the normal alignment procedure. The emergency procedure is used when the link being aligned is the only available link for any of the routes defined within the SSP. Otherwise, the normal alignment procedure is used.

SS7 - MTP3 (Message Transfer Part 3)

MTP3 does message handling and network management.

Message handling


Signaling Link Management
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signaling link activation,deactivation
SLTM - Signaling Link Test Message
SLTA - Signaling Link Test Acknowledge


Traffic Management
~~~~~~~~~~~~~~~~~~~~~~~~~~
Changeover (COO and COA)
COO - Change Over Order
COA - Change Over Acknowledgment
Changeback (CBD and CBA)
CBD - Change Back Declaration
CBA - Change Back Acknowledgment
Management inhibiting/Uninhibiting
MTP restart
Signaling traffic control
Forced rerouting
Controlled rerouting




Route Management
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TFP (Transfer Prohibited)
FTR (Transfer Restricted)
TFC (Transfer Controlled)
TFA (Transfer Allowed)
SRSM (Signaling-route-set-test)




Clusters
~~~~~~~~~~~~~~



MTP3 Timers -
~~~~~~~~~~~~~~


Timer T17 : Timer T17 (MTP3) prevents the rapid oscillation from in service to out of service. Timer T17 is started when the link begins the alignment procedure. No further alignment attempts are accepted from a remote or local SP until T17 has expired.

SS7 - MTP2 (Message Transfer Part 2)

MTP2
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SIO - status indication out of alignment
SIN - status indication normal alignment
SIE - status indication emergency alignment
SIOS - status indication out of service
SIPO - status indication processor outage
SIB - status indication busy


BEC - Basic Error Correction
PCR (Preventive Cyclic Retransmission) Technique
Difference between BEC and PCR
Forced Retransmission
Signaling Link Alignment
Proving Period (T4)
AERM - Alignment Error Rate Monitor
SUERM - Signal Unit Error Rate Monitor
PO - Processor Outage


Link Alignment (Normal and Emergency Alignment)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~







MTP2 Flow Control (SIB - Status Indication Busy)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~




MTP2 Timers
~~~~~~~~~~~~~~~~~~~~~~~
T1
T2
T3
T4
T5 -- sending SIB (80 to 120 ms),
T6 -- remote congestion
T7 -- excessive delay of acknowledgment
T8

SS7 - Difference between SLS and SLC

SS7 - Links and books

SS7 Standards

List of SS7 Standards: http://www.c7.com/ss7/ss7_standards.htm

ITU-T Q Series standards: http://www.itu.int/rec/T-REC-Q/en



Books


Signaling System No. 7 (SS7/C7): Protocol, Architecture, and Services
by Lee Dryburgh, Jeff Hewett





























Signaling System 7
By Travis Russell

SS7 - Signalling System 7 - Introduction

Introduction
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~







Power point slide for this picture: SSP-STP-SCP.ppt








SSP: Service Switching Point
STP: Signal Transfer Point
SCP: Service Control point




Terms/Abbreviations
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PC (Point Code) : Wikipedia page for point code




SS7 Stack
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~




MTP - Message Transfer Part
SCCP - Signalling Connection and Control Part
ISUP - ISDN User Part
TUP - Telephone User Part
TCAP -Transaction Capabilities
MAP - Mobile Application Part
INAP - Intelligent Network Application Part


Power point slide of this picture: SS7-stack.ppt













MTP Layer
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
FISU - Fill In Signal Unit
LSSU - Link Status Signal Unit
MSU - Message Signal Unit


Flag - 01111110 - Separates two message units.
BSN - Backward Sequence Number
BIB - Backward Indicator Bit
FSN - Forward Sequence Number
FIB - Forward Indicator Bit
The value of the LI (Length Indicator) field determines the signal unit type.

SIO - Service Information Octet
SIF - Signaling Information Field


Power point slide of this figure: FISU-LSSU-MSU.ppt






The FISU is sent when no other signal units are available.

The LSSU is used by the signalling link level to bring the link into alignment.

The MSU carries the actual upper-level information. For example, if ISDN User Part (ISUP) information is to be sent, it will be carried in an MSU.



Service Switching Point (SSP)

Signal Transfer Point (STP)

Service Control Points (SCP)

SS7 - notes

Few salient points
~~~~~~~~~~~~~~~~~~~~~~~






Terms and more
~~~~~~~~~~~~~~~~~~~~~~~


BEC (Basic Error Correction)


Telcordia administers ANSI Point Codes.
User Part Unavailable (UPU)
Mixed Linkset
Combined Linkset
Alias Point Code/Capability Point Code

quasi-associated route

Class3 Switch/Class 4 Switch



Switches are also known as exchanges; within the United States, the term exchange is used interchangeably with Central Office (CO) or End Office (EO).

Network signaling is also known as inter-switch signaling, network-network signaling, or trunk signaling.

PSTN (public switched telephone network) = Plain Old Telephone Service (POTS).

How voice circuit is reserved?
~~~~~~~~~~~~~~~~~~~~~~~~~~


What is the voice path?
~~~~~~~~~~~~~~~~~~

SS7 Signaling can do lot more ---
~~~~~~~~~~~~~~~~~~~~~~~~~~

• translate toll-free numbers into "routable" numbers
• validate credit and calling cards
• provide billing information
• remove faulty trunks from service
• provide the support for supplementary services (such as caller ID),
• roaming with your cellular telephone
• local number portability (LNP)

Non-circuit related signaling
~~~~~~~~~~~~~~~~~~~~~~~~~~

modern telephone networks can perform signaling while a call is in progress, especially for supplementary services—for example, to introduce another called party into the call, or to signal the arrival of another incoming call (call waiting) to one of the parties. In fact, since the 1980s, signaling can take place even when there is not a call in place. This is known as non-circuit related signaling and is simply used to transfer data between networks nodes. It is primarily used for query and response with telecommunications databases to support cellular networks, intelligent networks, and supplementary services. For example, in Public Land Mobile Networks (PLMNs), the visitor location register (VLR) that is in charge of the area into which the subscriber has roamed updates the home location register (HLR) of the subscriber's location. PLMNs make much use of non-circuit-related signaling, particularly to keep track of roaming subscribers.


TUP versus ISUP
~~~~~~~~~~~~~~~~~~~
ISUP resides at Level 4 of the SS7 stack with its predecessor, the Telephone User Part (TUP). TUP is still used in many countries, but ISUP is supplanting it over time. TUP also provides a call setup and release that is similar to ISUP, but it has only a subset of the capabilities. TUP is not used in North America because its capabilities are not sufficient to support the more complex network requirements.

Telecom Books

3G Mobile Networks
Architecture, Protocols, and Procedures
by Sumit Kasera and Nishit Narang

IMS Links, Books

The 3G IP Multimedia Subsystem (IMS): Merging the Internet and the Cellular Worlds
by Gonzalo Camarillo, Miguel-Angel García-Martín

NP (Numner Portability)

GTT (Global Title Translation)

RTP and RTCP

GPRS

PPT slide of the above picture: GPRS.ppt

Softswitch

What is Gateway MSC?

IMS (IP Multimedia Subsystem)

IMS_Security.doc- IP Multimedia Subsystem Security Framework

IMS IPsec : My Google Doc

SIGTRAN

Voip Protocols

GSM Links/Books

GSM Association

CDMA Call Flows

The Network











Power point slide of the above picture: Network.ppt




















Subsystems

Network Switching System (NSS)

The Network Switching System (NSS) or simply the switching system (SS) is responsible for performing call processing and subscriber-related functions. The switching system includes the following functional units:

• home location register (HLR)-The HLR is a database used for storage and management of subscriptions. The HLR is considered the most important database, as it stores permanent data about subscribers, including a subscriber's service profile, location information, and activity status. When an individual buys a subscription from one of the *mobile services switching center (MSC)-The MSC performs the telephony switching functions of the system. It controls calls to and from other telephone and data systems. It also performs such functions as toll ticketing, network interfacing, common channel signaling, and others.
• visitor location register (VLR)-The VLR is a database that contains temporary information about subscribers that is needed by the MSC in order to service visiting subscribers. The VLR is always integrated with the MSC. When a mobile station roams into a new MSC area, the VLR connected to that MSC will request data about the mobile station from the HLR. Later, if the mobile station makes a call, the VLR will have the information needed for call setup without having to interrogate the HLR each time.
• authentication center (AUC)-A unit called the AUC provides authentication and encryption parameters that verify the user's identity and ensure the confidentiality of each call. The AUC protects network operators from different types of fraud found in today's cellular world.
• equipment identity register (EIR)-The EIR is a database that contains information about the identity of mobile equipment that prevents calls from stolen, unauthorized, or defective mobile stations.

The AUC and EIR are implemented as stand-alone nodes or as a combined AUC/EIR node.

Base Station System (BSS)

All radio-related functions are performed in the BSS, which consists of base station controllers (BSCs) and the base transceiver stations (BTSs).

• BSC-The BSC provides all the control functions and physical links between the MSC and BTS. It is a high-capacity switch that provides functions such as handover, cell configuration data, and control of radio frequency (RF) power levels in base transceiver stations. A number of BSCs are served by an MSC.
• BTS-The BTS handles the radio interface to the mobile station. The BTS is the radio equipment (transceivers and antennas) needed to service each cell in the network. A group of BTSs are controlled by a BSC.

Operation and Support System (OSS)

The operations and maintenance center (OMC) is connected to all equipment in the switching system and to the BSC. The implementation of OMC is called the operation and support system (OSS). The OSS is the functional entity from which the network operator monitors and controls the system. The purpose of OSS is to offer the customer cost-effective support for centralized, regional, and local operational and maintenance activities that are required for a GSM network. An important function of OSS is to provide a network overview and support the maintenance activities of different operation and maintenance organizations.

Additional Functional Elements
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Other functional elements shown are as follows:

• message center (MXE)-The MXE is a node that provides integrated voice, fax, and data messaging. Specifically, the MXE handles short message service, cell broadcast, voice mail, fax mail, email, and notification.
• mobile service node (MSN)-The MSN is the node that handles the mobile intelligent network (IN) services.
• gateway mobile services switching center (GMSC)-A gateway is a node used to interconnect two networks. The gateway is often implemented in an MSC. The MSC is then referred to as the GMSC.
• GSM interworking unit (GIWU)-The GIWU consists of both hardware and software that provides an interface to various networks for data communications. Through the GIWU, users can alternate between speech and data during the same call. The GIWU hardware equipment is physically located at the MSC/VLR.

Protocols





















The Base Station Application Part (BSAP) is the application layer signaling protocol that provides messaging to accomplish the functions of the A1 Interface component of the MSC - BS Interface. BSAP is split into two sub-application parts; the BS Management Application Part (BSMAP), and the Direct Transfer Application Part (DTAP).
The BS Management Application Part (BSMAP) supports all Radio Resource Management and Facility Management procedures between the MSC and the BS, or to a cell(s) within the BS. BSMAP messages are not passed to the MS, but are used only to perform functions at the MSC or the BS. A BSMAP message (Complete Layer 3 Information) is also used together with a DTAP message to establish a connection for a MS between the BS and the MSC, in response to the first layer 3 air interface message sent by the MS to the BS for each MS system request. The description of the layer 3 protocol for the BSMAP information exchange is contained within this specification.

The Direct Transfer Application Part (DTAP) messages are used to transfer call processing and mobility management messages between the MSC and BS. DTAP messages carry information that is primarily used by the MS. The BS maps the DTAP messages going to and coming from the MSC from/into the appropriate air interface signaling protocol.



Terms/Abbreviations

IMSI - International Mobile Subscriber Identifier. Wikipedia page: IMSI

ESN - Electronic Serial Number. Wikipedia Page: ESN
ESNs are mainly used with AMPS and CDMA phones in the United States, compared to IMEI numbers used for GSM phones in Europe and elsewhere.



MDN - Mobile Directory Number

CIC - Circuit Identification Code

IS-41 (ANSI-41)
ANSI-41 (IS-41) is a standard for identifying and authenticating users, and routing calls on mobile phone networks. The standard also defines how users are identified and calls are routed when roaming across different networks.
ANSI-41 is the standard used by AMPS (analog), IS-136 (TDMA) and CDMA networks.
GSM and WCDMA networks use a different standard, known as MAP.


CMSR - Connection Management Service Request



Few important points

• In case of mobile cic is chosen by MSC and sent to the BSC.
  
• In case of ISUP cic come in the IAM megssage
  

Subscriber Registration

TBD


Mobile to mobile call (M-M Call flow)

TBD


Mobile to PSTN Call

TBD


PSTN to Mobile Call

TBD

CDMA Books/Links

CDMA Working Group(cdg.org)
Login info for cde.org



CDMA Internetworking: Deploying the Open A-Interface
by Su-Lin Low, Ron Schneider

MEGACO/MGCP versus SIP

SIP versus MEGACO/MGCP

SDP - Session Description Protocol

SDP RFC 4566: My Google Doc

MEGACO/H.248 Versus MGCP

MEGAOC Versus MGCP: My Google Doc

MEGACO - MGW Call Flows

MEGACO - MGW Call Flows : My Google Doc

MEGACO - CALEA - Topology descriptor

SPLIT-IN CALEA
SPLIT-OUT CALEA
MIXED CALEA



7.1.18 Topology descriptor (From RFC 3525 Gateway Control Protocol Version 1)
A Topology descriptor is used to specify flow directions between Terminations in a Context. Contrary to the descriptors in previous subclauses, the Topology descriptor applies to a Context instead of a Termination. The default topology of a Context is that each Termination's transmission is received by all other Terminations. The Topology descriptor is optional to implement. An MG that does not support Topology descriptors, but receives a command containing one, returns Error 444 Unsupported or unknown descriptor, and optionally includes a string containing the name of the unsupported Descriptor ("Topology") in the error text in the error descriptor.

The Topology descriptor occurs before the commands in an action. It is possible to have an action containing only a Topology descriptor, provided that the Context to which the action applies already exists.

A Topology descriptor consists of a sequence of triples of the form (T1, T2, association). T1 and T2 specify Terminations within the Context, possibly using the ALL or CHOOSE wildcard. The association specifies how media flows between these two Terminations as follows.

- (T1, T2, isolate) means that the Terminations matching T2 do not receive media from the Terminations matching T1, nor vice versa.

- (T1, T2, oneway) means that the Terminations that match T2 receive media from the Terminations matching T1, but not vice versa. In this case use of the ALL wildcard such that there are Terminations that match both T1 and T2 is not allowed.

- (T1, T2, bothway) means that the Terminations matching T2 receive media from the Terminations matching T1, and vice versa. In this case it is allowed to use wildcards such that there are Terminations that match both T1 and T2. However, if there is a Termination that matches both, no loopback is introduced.

Megaco Packages (Events and Signals)

Megaco Packages: My Google Doc

MEGACO Links, RFCs, Books

RFCs

RFC 3525 Gateway Control Protocol Version 1

RFC 3525 Gateway Control Protocol Version 1 : My Google Doc

RFC 4566 : Session Description Protocol : My Google Doc


Other Links

MEGACO IETF (old) Charter

MEGACO/H.248

Introduction

A Context is an association between a number of Terminations. Null Context is a special context that contains Terminations that are not associated to any other Termination.

In general, an Add command is used to add Terminations to Contexts. If the MGC does not specify an existing Context to which the Termination is to be added, the MG creates a new Context. A Termination may be removed from a Context with a Subtract command, and a Termination may be moved from one Context to another with a Move command. A Termination SHALL exist in only one Context at a time.

Commands:

Add
The Add Command adds a Termination to a Context.

Modify
The Modify Command modifies the properties of a Termination.

Subtract
The Subtract Command disconnects a Termination from its Context and
returns statistics on the Termination's participation in the Context.

Move
The Move Command moves a Termination to another Context from its
current Context in one atomic operation.

AuditValue
The AuditValue Command returns the current values of properties,
events, signals and statistics associated with Terminations.

AuditCapabilities
The AuditCapabilities Command returns the possible values of
properties, events, signals and statistics associated with
Terminations.

Notify
The Notify Command allows the Media Gateway to notify the Media
Gateway Controller of events occurring within the Media Gateway.

ServiceChange
The ServiceChange Command allows the Media Gateway to notify the
Media Gateway Controller that a Termination or group of Terminations
is about to be taken out of service or has just been returned to
service.













































Example Call Flow: Initiating a telephone call
Power point slide of the pictures of this calls flow: MEGACO-Call-Flow.ppt


Initial assumptions:
One MGC controlling both ends
Both gateways have associated with the MGC
MG1 and MG2 have TDM terminations programmed to listen to events









STEP1: MG1 detects an offhook event and notifies MGC

STEP2: MGC modifies MG1 to collect digits

STEP3: MG1 notifies when digits are collected

STEP4: MGC analyzes the digits and begins to connect MG1 and MG2

STEP5: MGC adds a TDM and RTP termination to context in MG1


















STEP6: MG1 replies with local IP address, UDP port and choice of codec

















STEP7: MGC adds a TDM(recvonly) and RTP termination to context in MG2





















STEP8: MG2 replies with local IP address, UDP port and choice of codec











STEP9: MGC modifies the RTP termination at MG1 to sendrecv.











STEP10: User 1 hears ringback and User 2 hears phone ringing

STEP11: User 2 lifts up the phone

STEP12: The telephone call is initiated


Abbreviations/Terms
Package :

The primary mechanism for extension is by means of Packages.Packages define additional Properties, Events, Signals and Statistics that may occur on Terminations.

Examples of packages -

Tone Generator Package
Tone Detection Package
Basic DTMF Generator Package
DTMF detection Package
Network Package
RTP Package

Events: Events are detected at MG and reported to MGC. (example: inband signaling). MGC controls what events it wants to learn about at any given time sets the termination Events descriptor

Signals: Signals cause things to happen on terminations. For e.g. play a tone, display text, ...

DTMF: Dual Tone Multi Frequency

RTP: Real Time Protocol

Packetization Time (ptime):

Telephony and Voip Forums

PcketCable
http://www.packetcable.com/

A consortium of cable system operators

PacketCable is a CableLabs-led initiative that is aimed at developing interoperable interface specifications for delivering advanced, real-time multimedia services over two-way cable plant. Built on top of the industry's highly successful cable modem infrastructure, PacketCable networks use Internet protocol (IP) technology to enable a wide range of multimedia services, such as IP telephony, multimedia conferencing, interactive gaming, and general multimedia applications. Working with CableLabs member companies and technology suppliers, the PacketCable project addresses issues such as device interoperability and product compliance with the PacketCable specifications.

Telecom Standard and RFCs

RFC 3578: Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP)

Introduction, Terms/Abbreviations

Terms/Abbreviations

AMPS - Advances Mobile Phone System