Bearer connection signaling in a distributed architecture

Abstract

A telecommunications network, which a first protocol, couples to a bearer connection, having a second protocol. At least a portion of the first protocol is mapped to the second protocol. A first signal of the first protocol is translated and inserted into a second signal of the second protocol according to the mapping, wherein the first signal of the first protocol is employed in the control of the bearer connection.

Description

BACKGROUND

[0002] 1. Field of the Invention

[0003] The present invention is directed to a telecommunication network for the transmission of voice information and particularly to signaling a bearer connection having a different protocol than the telecommunication network.

[0004] 2. Related Information

[0005] In a distributed architecture, the backbone of the network is provided by one provider and the remaining functionality is provided by other providers connecting to the network. Problematically, the network employs one protocol while the connecting provides another, which frustrates the signaling of bearer connections of the different signaling protocol. Thus, there is a great customer demand for a solution that signals existing customer bearer connections from the resident network architecture.

[0006] Take for example an architecture that employs control plane signaling traditionally associated with voice-over-internet protocol (VoIP) bearer connections. Such an architecture is not set up to signal bearer connections of another protocol. On the other hand, it is not atypical for customers to utilize an asynchronous transfer mode (ATM) protocol.

[0007] The problem is illustrated in more detail with reference to FIG. 1, wherein a distributed architecture 100 encompasses access at the edge of the network 101, interfaces to the core transport and centralized network control. At the heart of the distributed architecture 100 is a switch 102, which may be a soft switch (a software application emulating a switch), which provides service control and network intelligence.

[0008] Trunk gateways 104 provide the capability to inter-work bearer payload between legacy TDM trunks and packet based virtual trunks. Line or Access gateways 106 provide a similar interworking capability for subscriber lines. An integrated access device (IAD) 108 is a customer-located platform that delivers integrated voice and data services.

[0009] The Element Management system 110 provides open standards based management interfaces and state of the art Graphical User Interface (GUI) for the management of network elements. Servers 112 provide support functionality such as authentication and announcement services, and a server database 114 provides the information for the servers. An Operator Service Provider (OSP) 116 may be provided to establish third party application access via an APIs/CORBA PARLAY and resource servers 118 may be provided for adding additional resources.

[0010] In the distributed architecture 100 of FIG. 1, the signaling interface between a controlling switch 102 and gateways 104, 106, 108, also referred to as media gateways (MG) in the art, is commonly referred to as a vertical interface as it transcends the call control/application plane and the bearer/routing plane. In order to support a clear separation of call and bearer controls, a typical distributed architecture employs an open standard Gateway Control Protocol (e.g.; MGCP or MEGACO/H.248) across this vertical interface as shown generally by reference numeral 110.

[0011] In the example shown, the core network employs control signaling in accordance with the Internet Protocol. However, the user community has defined standard Gateway Control packages (namely Media Gateway Controller Protocols, MGCP/MEGACO, and SIP) that must be used on the vertical interface in order to signal the control bearer connections. Also defined is a standard use of Session Description Protocol (SDP) parameters. In other words, such a distributed architecture 100 is not capable to signal the bearer connections directly.

[0012] What is needed, therefore, is a means or method for a telecommunications network to signal the bearer connection. What is needed is to signal a bearer connection of another protocol. A solution could be used which seamlessly migrates signals from one signaling protocol to another. In a specific application, VoIP signaling a VoATM bearer connection is needed.

OBJECTS AND SUMMARY OF THE INVENTION

[0013] One exemplary object of the invention is to provide a telecommunications network capable to signal a bearer connection.

[0014] Another exemplary object of the invention is to signal a bearer connection of another protocol.

[0015] Yet another exemplary object of the invention is to seamlessly migrate signals from one signaling protocol to another.

[0016] Still anther exemplary object of the invention is to provide VoIP signaling to a VoATM bearer connection.

[0017] These and other objects are achieved by the present invention in which a signaling method of a bearer connection coupled to a telecommunications network is provided, wherein the telecommunications network employs a first protocol and the bearer connection employs a second protocol. At least a portion of the first protocol is mapped to the second protocol. A first signal of the first protocol is inserted into a second signal of the second protocol according to the mapping, wherein the first signal of the first protocol is employed in the control of the bearer connection.

[0018] According to the objects of the invention, there is also provided an apparatus for signaling a bearer connection coupled to a telecommunications network, wherein the telecommunications network employs a first protocol and the bearer connection employs a second protocol. A translator translates, according to a predetermined mapping, between a first signal of the first protocol and a second signal of the second protocol. A gateway inserts the first signal translated by the translator into the second signal, wherein the first signal is employed in the control of the bearer connection.

BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The present invention shall be described in reference to the following drawings which illustrate at least one example of the invention.

[0020] FIG. 1 is a block diagram of one example of a distributed telecommunications/networked architecture;

[0021] FIG. 2 is a flow diagram according to one embodiment of the invention;

[0022] FIG. 3 is an address mapping according to one embodiment of the invention;

[0023] FIG. 4 is a port mapping according to one embodiment of the invention;

[0024] FIG. 5 is a block diagram according to one embodiment of the invention;

[0025] FIGS. 6A, 6B are system and flow diagrams respectively according to one embodiment of the invention; and

[0026] FIG. 7 is a flow diagram according to one embodiment of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0027] The present invention shall be discussed in reference to the flow diagram 200 shown in FIG. 2, which illustrates a method for signaling a bearer connection of another protocol coupled to a telecommunications network. The telecommunications network employs a first protocol, which in the exemplary embodiment is VoIP. The bearer connection employs a second protocol, such as VoATM. However, its shall be understood that the invention is not so limited to any particular protocol, but encompasses at least signaling a bearer connection of a different protocol than the telecommunications network.

[0028] In step 202, the first protocol is mapped to the second protocol, or vice versa. Of course, the invention may map the entire first protocol to the second protocol, or at least a potion thereof.

[0029] As heretofore discussed, it is typical for a distributed architecture to employ an open standard Gateway Control Protocol, such as MGCP or MEGACO/H.248, across the vertical interface. Here now is an example of a mapping according to the invention to control VoATM connections using packages more commonly associated with VoIP connections. In Table I below, there is shown a Megaco Real-Time Transport RTP Package (RTP) mapped to an ATM Package (ATM).

	TABLE I
	Package		VoATM
	Definition	VoIP	mapping	Comment
	Properties	N/A	N/A
	Events	N/A	N/A
	Signals	N/A	N/A
	Statistics	Packets	Cells sent	The packets sent field
		sent	(cs)	(rtp/ps) is populated
		(ps)		with the number of ATM
				cells sent in
				accordance with /E1/.
		Packets	Cells	The packets received
		received	received	field (rtp/pr) is
		(pr)	(cr)	populated with the
				number of ATM cells
				received in accordance
				with /E1/.
		Packets	Cell loss	The packets lost field
		lost	(cl)	(rtp/pl) is populated
		(pl)		with the number of ATM
				cells lost in
				accordance with /E1/.
		Jitter	Jitter	The jitter field
		(jit)	(jit)	(rtp/jit) is populated
				with the interarrival
				jitter in accordance
				with /E1/.
		Delay	Delay	The jitter field
		(delay)	(delay)	(rtp/delay) is
				populated with the
				average cell
				transmission delay in
				accordance with /E1/.

[0030] It was also discussed that there is defined a standard use of Session Description Protocol (SDP) parameters. As shown in Table II(a) to II(c) below, the invention further provides a mapping of SDP parameters to control VoATM connections using parameter values more commonly associated with VoIP connections.

[0031] Table II(a) shows the Session Description Mappings for the Session Description Protocol.

TABLE II(a)
Description	Sub-	VoIP	VoATM
Type	Field	value	mapping	Comment
SDP	N/A	<number>	<number>	No mapping
version				required.
(v=)
Origin	TBD	TBD	TBD
(o=)
session	TBD	TBD	TBD
Name (s=)
session	TBD	TBD	TBD
information
(i=)
URI (u=)	TBD	TBD	TBD
E-mail	TBD	TBD	TBD
address
(e=)
phone	TBD	TBD	TBD
number
(p=)
connection	network	IN	ATM	One to one
info. (c=)	type			mapping.
	address	IP4	NSAP	One to one
	type			mapping.
	Connection	<IP4	<NSAP	See FIG. 3 and
	address	Address>	Address>	the associated text
				regarding the IP
				and ATM address
				mapping.
Bandwidth	TBD	TBD	TBD
info. (b=)
timezone	TBD	TBD	TBD
(z=)

[0032] Table II(b) shows the Time Description Mappings for the Session Description Protocol.

	TABLE II(b)
	Description	SDP		VoATM
	Types	Value	VoIP	mapping	Comment
	Session	TBD	TBD	TBD
	time (t=)
	Repeat	TBD	TBD	TBD
	times
	(r=)

[0033] Table II(c) shows the Media Description Mappings for the Session Description Protocol.

TABLE II(c)
Description			VoATM
Types	SDP Value	VoIP	mapping	Comment
Media name	Media	audio	audio	No mapping
(m=)	type			required.
		video	video	No mapping
				required.
		Application	application	No mapping
				required.
		Data	data	No mapping
				required.
		control	control	No mapping
				required.
	Transport	<port>	<eecid>	See FIG. 4
	port			and the
				associated
				text
				regarding
				the port
				and EECID
				mapping.
	Transport	RTP/AV	AAL1/ATM F
	protocol
	Media	0	0	No mapping
	format			required for
				this value.
				0 represents
				u-law
				encoded 8 K
				channel.
Media	TBD	TBD	TBD
title (I=)
Connection	TBD	TBD	TBD
info. (c=)
Bandwidth	TBD	TBD	TBD
info. (b=)

[0034] SDP further includes address and port information. Since other protocols, such as ATM in the present example, have a different structure for the addresses and port information, the present invention maps the address, or port, for SDP into an area of an ATM address, or port. As will be discussed further with respect to steps 204 and 206, the invention translates the SDP address or port into a suitable form for insertion into the ATM address or port. The manner in which the invention chooses the suitability of the address structure will be explained in the discussion of the FIGS. 3 and 4.

[0035] FIG. 3 illustrates how IP address information transported in SDP connection data is mapped to the equivalent SDP ATM address format (and vice versa). Subsequently, this information is translated to an ATM End System Address (AESA) used in UNI signaling messages.

[0036] In general, the mapping is based on virtual addressing overlay as generally indicated by the reference numeral 302 whereby a private addressing scheme 304 is overlayed over the public addressing scheme 306 used by the ATM infrastructure. This method ensures that the mapping is segregated and is applicable to any public addressing scheme previously adopted by the ATM infrastructure.

[0037] In this particular example, the proposed ATM addressing redefines the Network Prefix field 308 of the E.164 ATM format (AFI=0×45) of the Private ATM address 310. The area of interest is the 24 digits (8 octets) 312 following the Authority and Format Identifier (AFI) field 314. This area is composed of three fields; the E.164 address itself 316, the Routing Domain (RD) 318 specifying a unique domain within the addressing scheme in use and the Area 320 identifying a unique area within the routing domain in use.

[0038] The invention redefines these three fields into a private mapped IP/ATM address 310. This 24 digits (8 octets) address would be subdivided into two fields; a 12 digits (6 octets) prefix (‘000000000000’) isolating this overlay virtual space from the AESA addressing scheme used by the ATM infrastructure and a second 12 digits (6 octets) field holding the end-point IP address of the form ‘xxx.yyy.zzz.ddd’. Of course, this is merely an example and other address configurations are also possible.

[0039] It shall be appreciated that the present invention, maintains an ATM addressing scheme that does not violate standard ITU or ATM Forum addressing rules. Of course, it shall be understood that the present invention covers also a mapping that does not necessarily violate an ITU standard.

[0040] Returning now to the flow diagram of FIG. 2, the private address 202 is translated into a signal suitable for insertion into the public address of the ATM protocol in step 204. For example, the SDP address is translated into the format xxx.yyy.zzz.ddd such that the translated address fits bit-wise within the area designated by the mapping.

[0041] In step 206, the translated address is inserted into the ATM protocol of the second protocol according to the mapping. This address will be used later in the control of the bearer connection.

[0042] FIG. 4 shows how the invention maps an IP port information transported in SDP media data to equivalent EECID information (and vice versa). As shown, a port number 402, for example, 1234678, is translated into an EECID format 404. This format is then mapped into the transport mechanism 406, for example, a Generic Identifier Transport (GIT). In the example shown in the Figure, the port is mapped into the user data portion 408 of the GIT occurring after the ID, flags and length of the Identifier. Subsequently, this information is inserted into the GIT and transported, whereby it is later used in UNI signaling messages.

[0043] Now with respect to FIG. 2, in step 208, the information inserted into the ATM protocol is transmitted to the bearer connection. Thereafter, it is extracted according to the mapping and used to control the bearer connection.

[0044] A better understanding of the invention shall be obtained in consideration of FIG. 5, in which there is shown a block diagram of the system of the invention. A calling side, or ingress PSTN (I-PSTN) 502, that establishes a call, is coupled to a calling side media gateway 504, a so-called ingress media gateway (IMG). The I-PSTN 502 may communicate with the IMG 504 via time division multiplexing (TDM), for example.

[0045] On the receiving, or terminating, side is an egress PSTN (E-PSTN) 506, which receives the call. The E-PSTN 506 is coupled to a terminating side media gateway 508, or a so called egress media gateway (EMG). The IMG 504 communicates with the EMG 508 via the IP network 510. Of course, the I-PSTN and E-PSTN 502, 506 may be any type of communication network. Similarly, the network 510 may be other than an IP network.

[0046] The call signaling is controlled by a switch 512, such as the soft switch earlier mentioned. Part of the switch 512 may be a packet manager 514, which, at the control of the switch 512, packetizes and transmits signaling information to the media gateways 504, 508, to be explained later.

[0047] It shall be recognized that the system of FIG. 5 is similar to a traditional call signal connection of VoIP virtual trunking calls originating and terminating at traditional class 5 switches traversing an IP a packet network. As such, the gateway control protocol signaling selected for this example is Megaco (although MGCP could equally have been used.)

[0048] The present invention, in one aspect, adds the mapping and translating functionality to the media gateway, or gateways as the case may be. With which, the functionality performs translations between VoIP and VoATM control information based on mappings defined in this document. The functionality should also perform supporting functions such as detecting that a translation is required and inserting/extracting the messages. The entity performing this functionality will be hereafter referred to as the Vertical Interface Translation Function (VITF).

[0049] FIG. 5 illustrates the call signaling traffic 521-533 between the various elements in the system, which also may be thought of as steps of a call flow diagram. In step 521, a call is initiated at, for example, a class 5 office at the I-PSTN 502. The I-PSTN normally transmits a signal to the switch 512, typically an SS7 IAM signal. In step 522, the switch 512, through the packet manager 514 returns an add control message (ACM) to the I-MG 504 to add a call. In step 523, the VITF parses the add control command and determines that translation is necessary. In response, the VITF builds a reply message with an address for routing the call and the IMG 504 sends the message to the packet manager 514. In addition, the VITF translates a call control block provided by the calling side into an IP port number.

[0050] On the receiving side, in step 524, the switch 512 sends an IAM message to the E-PSTN 506 to signal an incoming call. In step, 525, the packet manager constructs an add control message for adding a terminating call, which includes the address and port information constructed by the calling side VITF, and sends the message to the EMG 508. In step 526, the EMG 508, which may be provided with its own VITF, determines that the incoming call is to be translated. In response, the receiving side VITF translates the information from the incoming message into an equivalent receiving side protocol.

[0051] Next, the invention provides the remaining handshaking protocol to complete the call. For purposes of example, the protocol for SS7 shall be used in this example, although other protocols are certainly within the scope of the invention. In step 527, an SS7 COT message is sent to the switch 512. In step 528, the E-PSTN 506 returns an ACM SS7 message to the switch 512, for example. The switch, via the packet manager 514, in step 529 sends a modify message to the IMG 504 with connection information from the receiving call side. In step 530, the IMG 504 returns an acknowledge signal to the switch 512, via the packet manager 514. In step 531, the switch 512 sends an ACM message to the IPSTN 502.

[0052] When an off-hook condition is detected at the receiving call side as in step 532, the EPSTN 506 sends an SS7 ANM message to the switch 512 indicating a call is received. The switch 512 then informs the IPSTN 502 that the call is received and the call is completed and a 2 way bearer channel is set up.

[0053] A more concrete example of the invention shall now be discussed with reference to FIGS. 6A and 6B, which respectively show the system and corresponding flow diagram of the present invention. In FIG. 6A, there is shown a 2 way bearer connection 600, in which the IMG 602 connects to the EMG 604 via respective switch routers 606 and 608. The switch 610, which orchestrates the control signaling, is shown here generally as 610.

[0054] After a call is initiated in the ingress PSTN (IPSTN) and an SS7 IAM message is signaled to the switch 610, an add control message to add the call is sent from the switch to the IMG 602 in step 612. As an example of such an add control message, the following code is provided, although certainly another message that has a similar function is within the scope of the invention.

MEGACO/1 [165.218.245.117]:20003
TRANSACTION=2363 {
CONTEXT = $ {
ADD = T01/02/03/04 {
MEDIA {
LOCALCONTROL { MODE = SENDONLY }
}
},
ADD = $ {
MEDIA {
LOCALCONTROL { MODE = RECEIVEONLY },
LOCAL {
v=0
c=IN IP4 $
m=audio $ RTP/AVP 0
}
}
}
}
}

[0055] In step 613, the IMG 602 on parsing the message detects that the second Add command in the message is for an IP termination. The IMG 602 checks its local configuration information and detects that the local packet network is, for example, an ATM network and so parameter translation is required. The VITF translates the SDP session and media parameters contained in the message according to the mappings heretofore described.

[0056] An ATM address is selected for routing of the backward ATM call based on configuration information typically provided by an ATM interface group. The VITF translates this address to an equivalent IP address, such as 111.222.333.444 in the exemplary Figure, according to the mappings described.

[0057] A local call control block is selected to handle the call, for example 12345678. This call control data (signaled in a VoATM call as an EECID) is translated to a port number by the VITF according to the mappings. Ultimately this call control data is returned to the IMG 602 as a UNI GIT IE and used to locate the call control block once when an ATM UNI SETUP message is received. The IMG 602 responds to the switch 610 with a reply signal, such as the following code.

MEGACO/1 [MediaGateway1]:2000
Reply = 2363 {
Context = 1 {
Add = T01/02/03/04,
Add = A4444 {
Media{
Local{
v=0
c=IN IP4 111.222.333.444
m=audio 12345678 RTP/AVP 0
}
}
}
}
}

[0058] After the switch 610 sends an SS7 IAM message to the EPSTN 604 (step 524, FIG. 5), the switch sends an add message to the EMG 508 to add the receiving side call in step 615. For purposes of example, the message may be constructed as follows:

MEGACO/1 [165.218.245.117]:20003
TRANSACTION=2364 {
CONTEXT = $ {
ADD = T05/06/07/08 {
MEDIA {
LOCALCONTROL { MODE = SENDRECEIVE }
}
},
ADD = $ {
MEDIA {
LOCALCONTROL { MODE = SENDRECEIVE },
LOCAL {
v=0
c=IN IP4 $
m=audio $ RTP/AVP 0
},
REMOTE {
v=0
c=IN IP4 111.222.333.444
m=audio 12345678 RTP/AVP 0
}
}
}
}
}

[0059] In step 616, a UNI setup message is forwarded from the EMG 604 to the IMG 602 UNI through the switches 606, 608. The setup message includes the call control data inserted into the UNI GIT IE. The IMG 602 uses the data to locate the call control block once when an ATM UNI SETUP message is received. A call proceeding message is sent from the IMG 602 to the switch in step 617 and, similarly, from switch 608 to the EMG 604. In step 618, a UNI connect message is returned from the ATM network to the EMG 604 through the switches 606, 608. In this manner, a 2-way ATM-TDM interworking bearer path is setup through the EMG 604.

[0060] In step 619, the EMG 604, i.e., the VITF of the EMG, parses the message and detects that the second Add command in the message is for an IP termination. The EMG checks its local configuration information and detects that the local packet network is, for example, an ATM network and so parameter translation is required. The VITF translates the SDP session and media parameters contained in the message according to, for example, the mappings heretofore defined.

[0061] More specifically, the IP address (111.222.333.444) received in the remote descriptor SDP connection data is translated by the VITF to an equivalent address, for example, an ATM address, according to the exemplary mappings defined. This address data is used to populate a Called Party Address IE of the ATM UNI SETUP message sent by the EMG 604 in order to initiate a backward connection of ATM SVC.

[0062] Furthermore, the VITF translates the port number received in the remote descriptor media name data (i.e., 12345678) according to the mappings. This data is used at the EMG 604 to populate the Generic Information Transport IE in the ATM UNI SETUP message.

[0063] Once the ATM UNI CONNECT message is returned from the ATM network and a 2-way ATM-TDM interworking bearer path has been setup through the EMG 604 then the a message, such as the example message below, is returned to the switch 610.

MEGACO/1 [MediaGateway1]:2000
Reply = 2364 {
Context = 2 {
Add = T05/06/07/08,
Add = A5555 {
Media{
Local{
v=0
c=IN IP4 555.666.777.888
m=audio 89ABCDEF RTP/AVP 0
}
}
}
}
}

[0064] In step 620, an SS7 COT message is forwarded by the switch 610 to the EPSTN 506. In step 621 The E-PSTN returns an acknowledge signal in the form of an ACM SS7 message.

[0065] As explained in reference to FIG. 5, the invention performs the remaining handshaking. A modify message in step 529 is sent from the switch to the IMG 504. The message for example purposes may be provided as follows.

MEGACO/1 [165.218.245.117]:20003
TRANSACTION=2365 {
CONTEXT = 1 {
MODIFY = T01/02/03/04 {
MEDIA {
LOCALCONTROL { MODE = SENDRECEIVE }
}
},
MODIFY = A4444 {
MEDIA {
LOCALCONTROL { MODE = SENDRECEIVE },
REMOTE {
v=0
c=IN IP4 555.666.777.888
m=audio 89ABCDEF RTP/AVP 0
}
}
}
}
}

[0066] It shall be appreciated that, in this particular example, the IP address (555.666.777.888) received remote descriptor SDP connection data is not used by the IMG 504 for signaling purposes and so no translation is required. Similarly the port number (89ABCDEF) received in the remote descriptor media name data is not required and so again no translation is required.

[0067] At this time, a 2-way ATM-TDM interworking bearer path is essentially setup through the IMG 504. In step 530 an acknowledge signal, such as that provided below, is returned to the switch.

MEGACO/1 [MediaGateway1]:2000
Reply = 2365 {
Context = 1 {
Modify = T01/02/03/04,
Modify = A4444
}
}

[0068] The remaining signaling executed upon an off-hook condition to establish the call has already been discussed with reference to FIG. 5.

[0069] The invention further provides for the removal, or tear-down, of the call once a call is ended. The steps for tear-down will be discussed in reference to the flow diagram 700 of FIG. 7. In step 702, the I-PSTN signals an SS7 REL to the switch 610 initiating the tear-down of the call. The switch 610 sends subtract message to the IMG 602, such as that shown here.

MEGACO/1 [165.218.245.117]:20003
TRANSACTION=2366 {
CONTEXT = 1 {
SUBTRACT = T01/02/03/04,
SUBTRACT = A4444 {
AUDIT { STATISTICS }
}
}
}

[0070] In step 704, the IMG 602 initiates the clearing of the ATM SVC. Call statistics data is located and translated by the VITF at the IMG 602 according to the exemplary mappings defined above. Once the interworking bearer path is torn down the IMG 602 returns the reply message to the switch, such as follows.

MEGACO/1 [MediaGateway1]:2000
Reply = 2366 {
Context = 1 {
Subtract = T01/02/03/04,
Subtract = A4444 {
Statistics {
rtp/ps = 1234,
nt/os = 56749,
rtp/pr = 10000,
nt/or = 984726,
rtp/pl = 34.90,
rtp/jit = 9,
rtp/delay = 29
}
}
}
}

[0071] Next, the receiving side is torn-down. In step 706, the switch sends a subtract message to the EMG 604, which may be the following.

MEGACO/1 [165.218.245.117]:20003
TRANSACTION=2367 {
CONTEXT = 2 {
SUBTRACT = T05/06/07/08,
SUBTRACT = A5555 {
AUDIT { STATISTICS }
}
}
}

[0072] In step 708, Call statistics data is located and translated by the VITF at the EMG 604 according to the predefined mappings. Once the interworking bearer path is torn down, the EMG 604 returns the reply message to the switch 610, such as given by the following reply message example.

MEGACO/1 [MediaGateway1]:2000
Reply = 2367 {
Context = 2 {
Subtract = T05/06/07/08,
Subtract = A5555 {
Statistics {
rtp/ps = 4321,
nt/os = 647290,
rtp/pr = 5000,
nt/or = 836193,
rtp/pl = 45.78,
rtp/jit = 10,
rtp/delay = 34
}
}
}
}

[0073] Thus, the call is torn down and the network resumes operation, ready for the next call initiation.

[0074] While the present invention has been described in the context of a specific example, it shall be appreciated that the invention is not so limited to a single example, but that similar embodiments and variations are within the scope of the invention. The invention encompasses not only the IP and ATM protocols, but any mapping from one protocol to another. The specific code provided is for example only and other code which provides the same function is certainly within the invention. The present invention proposes a standards based solution that can be employed in multi vendor networks a primary motivation, but the invention need not be standards based.

Claims

1. A method for signaling a bearer connection coupled to a telecommunications network, wherein the telecommunications network employs a first protocol and the bearer connection employs a second protocol, the method comprising the steps of: mapping at least a portion of the first protocol to the second protocol; and inserting a first signal of the first protocol into a second signal of the second protocol according to the mapping, wherein the first signal of the first protocol is employed in the control of the bearer connection.

2. The method according to claim 1, wherein the first protocol is an Internet Protocol (IP), and the step of mapping maps at least a portion of the Internet Protocol to the second protocol.

3. The method according to claim 1, wherein the second protocol is an asynchronous transfer mode (ATM) protocol, and the step of mapping maps at least a portion of the ATM protocol to the first protocol.

4. The method according to claim 1, wherein the first protocol is an Internet Protocol (IP) and the second protocol is an asynchronous transfer mode (ATM) protocol, wherein the step of mapping maps at least a portion of the Internet Protocol to the ATM protocol.

5. The method according to claim 1, further comprising the step of translating the first signal of the first protocol into a signal suitable for insertion into the second signal of the second protocol according to the mapping.

6. The method according to claim 5, wherein the first protocol is an Internet Protocol (IP), wherein the step of translating translates an Internet Protocol address into a signal that is insertable into a predetermined area of the second signal of the second protocol.

7. The method according to claim 6, wherein the second signal of the second protocol is an ATM address and the step of translating translates the Internet Protocol address into a signal suitable for insertion into an area within a network prefix of the ATM address.

8. The method according to claim 7, wherein the step of mapping redefines a portion of the network prefix field following an authority and format identifier.

9. The method according to claim 1, wherein the first signal of the first protocol is Internet Protocol (IP) port information, wherein the step of translating translates the Internet Protocol port information into a signal that is insertable into a predetermined area of the second signal of the second protocol.

10. The method according to claim 9, wherein the second signal of the second protocol is a generic identifier transport (GIT) information element, and wherein the step of translating translates the first signal into a signal suitable for insertion into the GIT information element.

11. The method according to claim 10, wherein the step of mapping maps the first signal translated into a user data area of the GIT information element.

12. An apparatus for signaling a bearer connection coupled to a telecommunications network, wherein the telecommunications network employs a first protocol and the bearer connection employs a second protocol, the apparatus comprising: a translator that translates, according to a predetermined mapping, between a first signal of the first protocol and a second signal of the second protocol; and a gateway that inserts the first signal translated by the translator into the second signal, wherein the first signal is employed in the control of the bearer connection.

13. The apparatus according to claim 12, wherein the telecommunications network is an Internet Protocol (IP) network.

14. The apparatus of claim 12, wherein the bearer connection employs an asynchronous transfer mode (ATM) protocol.

15. The apparatus according to claim 12, wherein the mapping maps at least a portion of an internet protocol (IP) to an asynchronous transfer mode (ATM) protocol.

16. The apparatus according to claim 12, further comprising a map that maps at least a portion of the first protocol to the second protocol.

17. The apparatus according to claim 16, wherein the map maps the portion of the first protocol to an area suitable for insertion into the second signal of the second protocol.

18. The apparatus according to claim 12, further comprising a switch

19. The apparatus according to claim 12, further comprising an ingress media gateway for receiving the first signal translated and inserted into the second signal for setting up an initiating call.

20. The apparatus according to claim 12, further comprising an egress media gateway for receiving the first signal translated and inserted into the second signal for setting up a terminating call.