Embed Size (px)
DESCRIPTION
Citation preview
Abstract— The objective of the paper is to demonstrate a soft one to one gateway switch that describes a call control architecture, where the intelligence of the call control is outside the gateways and handled by external call control elements called call agents. The gateway protocol assumes that these call control elements will synchronize with each other by sending coherent commands to the gateways under their control. This gateway switch is master/salve protocol where the gateways are expected to execute commands sent by the call control elements. Gateway protocol does not define a mechanism for synchronizing call control elements.
Keywords— MGCP, MGCI, Gateway, Callagent, endpoint, NTFY, DLCX, AUEP, AUCX, CRCX, MDCX, RSIP, hairpin.
I.INTRODUCTION
Media gateway control interface describes an abstract application programming interface (MGCI) and a corresponding protocol (MGCP) for controlling Media Gateways from external call control elements called media gateway controllers or Call Agents. A Media Gateway is typically a network element that provides conversion between the audio signals carried on telephone circuits and data packets carried over the Internet or over other packet networks. MGCP assumes a call control architecture where the calls control “intelligence" is outside the gateways and handled by external call control elements known as Call Agents.
The MGCP assumes that these call control elements, or Call Agents will synchronize with each other to send coherent commands and responses to the gateways under their control. If this assumption is violated, inconsistent behavior should be expected. MGCP does not define a mechanism for synchronizing Call Agents.
Media Gateway Control Interface functions provide for connection control and endpoint control. Connections are grouped in calls. One or more connections can belong to one call. Connections and calls are set up at the initiative of one or more Call Agents. Media gateways should be able to establish several connections between the endpoint and the packet networks, or between the endpoint and other endpoints in the same gateway.
The decomposed gateway consists of a call agent, which contains the call control” intelligence”, and a media gateway, which contains the media functions. Media gateways contain endpoints on which the call agents can create, modify and delete connection in order to establish and control media sessions with other multi media generate signals. The end points automatically communicate changes in services state to the call agent. Furthermore, the call agent can audit endpoints
1Balachandra G.C. Tontadarya College of Engineering, Mundargi Road , Gadag-582101, Karnataka . INDIA ( Phone: +091-821-236933, 232445; Fax: +091-08372-232446, Email: [email protected], [email protected].
2Hanumanthappa .J., Dos in Computer Science, University of Mysore, Manasagangothri, Mysore, Karnataka .INDIA ( phone: +091-821-2419552; fax: +091-0821-2510789,Email: [email protected] )
as well as the connection on endpoints [1], [2].
Block diagram of MGCP
Fig 1.1: Block diagram of MGCP
Endpoint and Connection Identifiers Endpoint identifiers have two components that both are case- insensitive:
the domain name of the gateway that is managing the endpoint
a local name within that gateway Endpoint names are of the form: local-endpoint-name@domain-name
Where domain-name is an absolute domain-name and includes a host portion, thus an example domain-name could be: softonetoone.gataway.net
Also, domain-name may be an IP-address of the form [192.168.1.2]
Both IPv4 and IPv6 addresses can be specified, however use of IP addresses as endpoint identifiers are generally discouraged [1], [2].
View of call agent and gateway
Fig 1.2: View of call agent and gatewayA point-to-point connection is an association between two
endpoints with the purpose of transmitting data between these endpoints. Once this association is established for both endpoints, data transfer between these endpoints can take place [7],[9].
Call agents instructs the gateways to create connections between endpoints and to detect certain events, e.g: off-hook, on-hook etc, and generate certain signals, eg: ringing. It is strictly upto the call agent to specify how and when connections are made, between which endpoints they are made, as well as what events and signals are to be detected and generated on the endpoints. The gateway, there by, becomes a simple device, without any call state, that receives
Soft One To One Gateway ProtocolBalachandra G.C 1 and Hanumanathappa J 2
CA : Call agent
GW : Gateway
MGCP: Media Gateway Control
Protocol
RTP: Real Time Protocol
SIP: Session initialization protocol
CA CA
GW GW
EC1
SIP
MGCP
RTP
EC2 EC3
Call Agent or Media Gateway
Controller (MGC)
Media Gateway
(MG)
Call Agent or Media Gateway
Controller (MGC)
Media Gateway
(MG)
SIP H.323
MGCP
MGCP
general instructions from the call agent without any need to worry about or even understand the concept of calls or call states.
When new services are introduced or customer profiles changed, the changes are transparent to the gateway. The call agent implements the changes and generates the appropriate new mix of instructions to the gateways for the changes made.
In the MGCP model, the gateways focus on the audio signal translation function, while the call agent handles the signaling and call processing functions. As a consequences, the call agent implements the "signaling".
Table 1 :Command Formats
Command
Message NameSent By
Description
AUEP AuditEndpoint CADetermines the status of a
given endpoint.
AUCX AuditConnection CARetrieves all the parameters
associated with a connection.
CRCX CreateConnection CACreates a connection between
two endpoints.
DLCX DeleteConnection Both
From CallManager: Terminates a current
connection.From Gateway: Indicates that a connection can no longer be
sustained.
MDCX ModifyConnection CAChanges the parameters
associated with an established connection.
RQNT NotificationRequest CA
Instructs the gateway to watch for special events such as
hooks or DTMF tones. It is also used to instruct the
gateway to provide a signal to the endpoint (for example, dial
tone and busy tone).
NTFY Notify GWInforms the Cisco
CallManager when requested events occur.
RSIP RestartInProgress GW
Informs the Cisco CallManager that an endpoint
or group of endpoints are taken out or placed back into
service.
Sequence of Commands for a Call EstablishmentThe first command is a NotificationRequest, sent by the Call
Agent to the Gateway Server. The request will consist of the following lines:RQNT 1201 endpoint/[email protected] MGCP 0.1 N: [email protected] hatever.net: X: 0123456789AC R: hd(E (dl;hu, D/[0-9#*T](D);) D: 2XXX
The gateway immediately acknowledges the command, repeating in the acknowledgement message the transaction id that the Call Agent attached to the query. 200 1201 OK
When the off hook event is noticed, the gateway provides the dial tone to the line (the delay between off-hook and dial tone is thus minimal.) The gateway will then start accumulating digits according to that digit map.
When it has noticed a sufficient set of values, it will
notify the observed string to the Call Agent:NTFY 2002 endpoint/[email protected] MGCP 0.1 N: [email protected] X: 0123456789AC O: 2001
The Call Agent immediately acknowledges that notification. 200 2002 OK
The call agent analyzes the called number and determines that this is a hairpin connection the called party is located on the same gateway, on endpoint/2. The Call Agent can prepare two simultaneous Create Connection commands, creating the two legs of the connection.
The create connection sent to the first endpoint piggybacks a notification request, to stop collecting digits yet continue watch for an on-hook transition. The Create Connection sent to the second endpoint piggybacks a request to generate ringing and look for off-hook. Both commands can be sent in a single UDP packet:CRCX 1204 endpoint/[email protected] MGCP 0.1 C: A3C47F21456789F0 X: 0123456789AD M: sendrecv R: hu v=0 c=LOCAL rgw.whatever.net endpoint/2 m=audio 0 LOCAL 0 CRCX 1205 endpoint/[email protected] MGCP 0.1 C: A3C47F21456789F0 X: 9875659876 M: sendrecv R: hd S: rg v=0
c=LOCAL rgw.whatever.net endpoint/1 m=audio 0 LOCAL 0
We should note that the call agent does not send the local connection options since it knows that it is a local (a.k.a. "hairpin") connection are entirely described by the SDP text.
The gateway immediately acknowledges the creations, sending back in two messages the identification of the newly created connections: 200 1204 OK I:FDE234C8 200 1204 OK I:9867659A
The gateway, at that point, is instructed to look for an off-hook event on the second endpoint, and to report it. When the gateway notices the off hook event, it sends a Notify command to the Call Agent:NTFY 2001 endpoint/[email protected] MGCP 0.1 X: 9875659876 O: hd
The Call Agent immediately acknowledges that notification: 200 2001 OK
The Call agent will now send a Notification Request command to the gateway, asking to look for an off-hook event on the second end-point:
RQNT 1206 endpoint/[email protected] MGCP 0.1 X: 987565989A R: hu
The gateway acknowledges that command: 200 1206 OK
At this point the call is active between the two gateway users.When the first user goes off hook, it sends a notification to the call agent: NTFY 2010 endpoint/[email protected] MGCP 0.1 X: 987565989A O: hu
The call agent acknowledges the notification. It can, in a single UDP message, send the acknowledgement and the Delete Connection commands that will clear the call.
For the first gateway, the command embeds a notification request that readies that gateway for the next call: 200 2010 OK . DLCX 1210 endpoint/[email protected] MGCP 0.1 C: A3C47F21456789F0 I: FDE234C8 N: [email protected] X: 012345673FDE R: hd(E(dl;hu, D/[0-9#*T](D);) . DLCX 1211 endpoint/[email protected] MGCP 0.1 C: A3C47F21456789F0 I: 9867659A X: A3C5F0 R: hu
The gateway will acknowledge the commands in a single UDP message that will carry the "local connection" version of the connection parameters. 250 1243 OK 250 1244 OK
When the second user goes off hook, the gateway sends a Notify commandsNTFY 2020 endpoint/[email protected] MGCP 0.1 X: A3C5F0 O: hu
The Call agent follows with a notification requests, transmitted in the same packet as the acknowledgement, in order to ready the line for the next call: 200 2020 OK . RQNT 1220 enpoint/[email protected] MGCP 0.1 N: [email protected] X: 0123456793E5 R:hd(E(dl;hu, D/[0-9#*T](D);)
The gateway acknowledges the command, signaling that the second endpoint is now ready [1], [2]. 200 1220 OK
II DESIGN AND ARCHITECTURE
Design of Call Processing and Feature ProcessingAlso called Call Processor, implements the Call
processing and feature processing code. This module of the
MGCP Call Agent incorporates the basic functionality of the entire call processing for the MGCP based endpoints. It is a generic Call Processing, which can work with any kind of protocol as long as it adheres to the interface message explained below.
A basic call finite state machine has been designed & implemented to achieve a stable & real time call processing between the multiple web clients operating over the LAN.
States Recognosized Idlestate Dialingstate Ringingstate Establishedstate Terminationstate
Designing Basic Call Flow
Fig 2.1: Basic Call FSM with different states
Events InterfaceThis interface contains all the possible physical events
that are sent by the web clients during Call Processing (To establish a basic call). It also includes some of the other messages, which are for the internal functioning of the FSM.List of events possible are
OnHook OffHook DigitsDialed Flash TimedOut CallAccepted CallTerminated CallRequestedThe last three messages/events are used for the internal
functioning of the FSM.
ActionsThis interface contains the list of all the generic actions
(applicable to all the end users/clients). In appropriate states the required action should be processed & rendered to the web clients List of actions possible are
StopTone GiveTone InvalidEvent SendMessage
Events
STATE
IdleState
DialingState
RingingState
EstablishedState
Actions
Terminating state
Interface
Other state specific actions are processed in the respective individual states.
III IMPLEMENTATION
StatesThe State class implements the two interfaces EVENTS
and ACTIONS. All the states of the basic call FSM are derived from this common Class STATE.This class adds some extra member functions, other than implementing the two Interfaces. Idle State
The Idle State class is one of the classes of the basic call FSM. This class overrides some of the methods of it’s base class STATE which in turn implements the EVENTS and ACTIONS interface[5][6].On the occurrence of the following Events appropriate Actions are taken on the particular Set Object & the Actions taken are listed below the event names. The functions or methods that are overridden by the IdleState class are: OnHook( )
InvalidEvent ();Only when Web Clients goes OffHook a set object is created which has a state as IdleState
OffHook( )Dial Tone is fed to the end client. The corresponding set object fields are manipulated as follows:
STATE == DIALING;SUB_STATE == SS_START_DIALING;TONEFLAG == TRUE;
PREVSTATE == IDLE; PREVSUBSTATE==NONE;Update the Hash table with the modified set object
DigitsDialed( )InvalidEvent ();
Flash( )InvalidEvent ();
CallRequested( )Give RING to the set (end client) for which the message/event has arrived.Give RING_BACK_TONE to the set from which this message has come.Set Object fields changed are:
STATE == RINGINGSTATE;SUB_STATE == NONE;RINGFLAG == TRUE;
Change the TONE field of the other set object to RING_BACK_TONEUpdate the two set objects in the HASH table
CallAccepted( )InvalidEvent ();
CallTerminated( )InvalidEvent ();
TimeOut( ) : yet to design IdleState specific actions are taken in each of the above methods / functions.
Dialing State
The Dialing State class is one of the classes of the basic call FSM. This class overrides some of the methods of it’s base class STATE which in turn implements the EVENTS & ACTIONS interface
The functions or methods that are overridden by the DialingState class & the appropriate Actions are: OnHook( )
If (SUB_STATE == SS_CONNECTING)Send CallTerminated message to the other Set
ObjectSTATE == IDLE;SUB_STATE == NONE;The set object is removed from the Hash Table
OffHook( )InvalidEvent ();
DigitsDialed( )If (SUB_STATE == SS_CONNECTING) InvalidEvent ();ElseIf (SUB_STATE == SS_START_DIALING)
Stop the Dial Tone to the set;Read the digits dialed;SUB_STATE == SS_CONNECTING;Update the Call Register associated with the set;Update the Hash table with the modified set object;
Flash( )If (SUB_STATE == SS_CONNECTING) Feed RING_BACK_TONE to the set;Else if (SUB_STATE == SS_START_DIALING) Feed DIAL_TONE to the set
CallRequested( )Give BUSY_TONE to the set from which the message/event has arrived;Get the set object from the Hash Table;TONE == BUSY_TONE;Update the Hash Table with this set object
CallAccepted( )If (SUB_STATE == SS_CONNECTING) Stop the RING on the terminating set; Stop the RING_BACK_TONE to the; originating set STATE == ESTABLISHEDSTATE; SUB_STATE == NONE; Else InvalidEvent ();
CallTerminated( )InvalidEvent ();DialingState specific actions are taken in each of the above methods / functions
Ringing StateThe Ringing State class is one of the classes of the basic
call FSM. This class overrides some of the methods of its base class STATE which in turn implements the EVENTS & ACTIONS interface
The functions or methods that are overridden & the appropriate actions taken by the are:
OnHook( )InvalidEvent ();
OffHook( )
Send CallAccepted message to the other set object;STATE == ESTABLISHEDSTATE;RING_FLAG == False;Make the call register handle of the RINGINGSTATE set object point to the call register of the other (opponent) set object;
DigitsDialed( )InvalidEvent ();
Flash( )InvalidEvent ();
CallRequested( )Give Tone BUSY_TONE to the set object from where the message has arrived whose present TONE == BUSY_TONE;
Update the Hash Table with the updated set object; CallAccepted( )
InvalidEvent (); CallTerminated( )
Stop Ring to the set;STATE == IDLE;RINGFLAG == false;Remove the set object from the Hash Table;
TimeOut( ) yet to design;
RingingState specific actions are taken in each of the above methods / functions
Established StateThe Established State class is one of the classes of the
basic call FSM. This class overrides some of the methods of its base class STATE which in turn implements the EVENTS & ACTIONS interface
The functions or methods that are overridden & the Actions are: OnHook( )
Send CallTerminated to the other (opponent) set objectSTATE == IDLE;SUB_STATE == NONE;Remove the set object from the Hash Table;
OffHook( )InvalidEvent ();
DigitsDialed( )InvalidEvent ();
Flash( )InvalidEvent ();
CallRequested( )Give BUSY_TONE to the set from which this message/event has been received with CURRENT_TONE == BUSY_TONE;
Update the Hash Table with this set object; CallAccepted( )
InvalidEvent (); CallTerminated( )
STATE == TERMINATIONSTATE;SUB_STATE == NONE;Update the Hash Table with the modified set object;
EstablishedState specific actions are taken in each of the above methods / functions
Terminate StateThe Established State class is one of the classes of the
basic call FSM. This class overrides some of the methods of its base class STATE which in turn implements the EVENTS & ACTIONS interface
The functions or methods that are overridden & the specific Actions are: OnHook( )
STATE == IDLE;Remove the set object from the Hash Table;
OffHook( )InvalidEvent ();
DigitsDialed( )InvalidEvent ();
Flash( )InvalidEvent ();
CallRequested( )Give Tone BUSY_TONE to the set from which this message/event has arrived; CURRENT_TONE == BUSY_TONE;Update the Hash Table;
CallAccepted( )InvalidEvent ();
CallTerminated( )InvalidEvent (); TerminationState specific actions are taken in each of the above methods / functions
State Machine DiagramThe FSM implements the Basic Call FSM.This is the
class, which handles & manipulates the call processing with the aid of the FSMThe public functions of this class are: void startFsm( )
This function is responsible for the start of the Basic CallFSM.It creates objects of all the classes present in the
FSM. void EventDispatcher(Sets handle , InterfaceMessage
iMsgHandle)This function is responsible for the dispatching of the
events in the appropriate state handles. void printCurrentState( )
This function is responsible for printing out in the console the set object related information & also the call register related information for testing purposes.
IV IMPLEMENTATION RESULTS & ANALYSISTable 2: State Transition Matrix
STATE
EVENT
IDL DIALINGRINGI
NG
ESTA
BLISH
ED
TERMI
NATED
Off- HookDIALL
INGInValid
ESTA
BLISH
ED
InValid InValid
On- Hook Invalid IDLE InValid IDLE IDLE
Digits Invalid DIALLING Invalid Invalid Invalid
Dialled
Call
Requested
RINGI
NGInvalid Invalid Invalid Invalid
Call
AcceptedInValid
ESTABLIS
HEDInvalid Invalid Invalid
Call
TerminatedInvalid Invalid IDLE Invalid Invalid
TimeOut Invalid Invalid IDLE Invalid Invalid
Analysis The above results are satisfying the requirement of
MGCP 1.0 standard, verified for all the command format of table 1.1. The webclient is a ‘Browser downloadable secured Applet’ which can be downloaded from the web server and used to make VOIP calls with other similar webclients.
ConclusionIf we look at the development of media gateway control
protocols from simple PSTN/VOIP interworking “enables” to complex media-specific applications, it is clear that the Media Gateway Control Protocols have an important role to play. Like IP centric conferencing and media-related application. The inherent client/server architecture of the protocol provides room for growth and possibilities of developing flexible, scalable applications. The decomposed gateway architecture greatly eases the problems of management and expansion.Future Enhancement
The media-Oriented Design of the protocols provide the opportunity for better media management as multimedia conferencing media-rich application become a greater part of everyday life (IVR announcement servers, call centre application). New Package- such as a media server package that defines events and signals for controlling a media server.
References[1] Arango, et al. Informational RFC 2705 Media Gateway Control
Protocol (MGCP) 1999,2003.[2] Network Working Group, Cisco Systems Informational RFC 3661 B.
Foster C. Sivachelvan 2003[3] Data Communication and Networking 4e-Forouzan[4] Andrew S. Tanenbaum, Computer Networks., Fourth edition,2005.[5] Herbert Schildt Complete Reference Java 2 Tata McGraw Hill 2002 5e[6] E Balaguruswamy Programming with Java A Primer 2000 2e[7] http://www.voip-info.org/wiki/index.php?page=VOIP+phone[8] http://www.ietf.org/rfc.html[9] http://wwwprotocols.com/pbook/voipfamily
Authors
Mr.Hanumanthappa.J. has taken his birth in Harihar on 6-12-1975,which belongs to Davanagere (D).He has received his Bachelor of Engineering Degree in computer science and engineering from University B.D.T College of
Engineering , Davanagere, Karnataka( S),India( C),which is affiliated to Kuvempu University , Shimoga in the year 1998 and Master of Technology in cs & engineering from NITK Surathkal , Karnataka( S ), India (C) in the year 2003.He is currently pursuing his doctoral program from Mangalore university , Mangalore under the supervision of Dr.Manjaiah. D. H. under
the title called “Security issues of IPv6”.
He is currently working as a LECTURER in Department of Studies in Computer Science ,Manasagangothri, University of Mysore. He has presented 2 research papers in National and International Conferences in Network Engineering. Currently He is writing two Text books on Introduction to “C” and one more on Cryptography and Network security for computer science and Engineering students.
He is a Life member of CSI, ISTE,AMIE, IAENG, Embedded networking group of TIFAC – CORE in Network Engineering .
Mr. Balachandra G.C is currently working as Lecturer in Tontadarya College of Engineering, Gadag. He received his Master of Technology in Computer Science and Technology from DOS in Computer Studies, University of Mysore, Mysore in 2006. In the Year 1999 he completed his M..Sc (Electronics) from Karnataka University Dharwad. He is having good Knowledge in computer Network;
his area of interest is Network Security, Algorithms Data Structure and OOAD.
