CA2464296C - Method for transmission of signal tones in heterogeneous networks, device and computer program product - Google Patents
Method for transmission of signal tones in heterogeneous networks, device and computer program product Download PDFInfo
- Publication number
- CA2464296C CA2464296C CA2464296A CA2464296A CA2464296C CA 2464296 C CA2464296 C CA 2464296C CA 2464296 A CA2464296 A CA 2464296A CA 2464296 A CA2464296 A CA 2464296A CA 2464296 C CA2464296 C CA 2464296C
- Authority
- CA
- Canada
- Prior art keywords
- transfer
- converter
- accordance
- network
- signal tones
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/102—Gateways
- H04L65/1033—Signalling gateways
- H04L65/104—Signalling gateways in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/102—Gateways
- H04L65/1023—Media gateways
- H04L65/103—Media gateways in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/102—Gateways
- H04L65/1043—Gateway controllers, e.g. media gateway control protocol [MGCP] controllers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
- H04M7/0072—Speech codec negotiation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
- H04M7/1205—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
- H04M7/1295—Details of dual tone multiple frequency signalling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q3/00—Selecting arrangements
- H04Q3/0016—Arrangements providing connection between exchanges
- H04Q3/0025—Provisions for signalling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/0093—Arrangements for interconnection between switching centres signalling arrangements in networks
Abstract
The invention relates to a method for the establishment of a connection, whereby a media gateway controller (11) on the B side, which is given the transmission method supported by the media gateway (3) on the A side, selects a transmission method, which is supported by both the media gateway (3) on the A side and the media gateway (4) on the B side and transmits the selection thereof to the media gateway controller (10) on the A side. It can thus be guaranteed that in a commonly supported transmission method that a connection occurs in which the DTMF signal tones can be transmitted.
Description
Description Method for transmission of signal tones in heterogeneous networks, device and computer program product The invention relates to a method for selecting a transmission procedure for digital signal tones in heterogeneous networks. The invention further relates to a device and computer program product which is designed to execute the procedure.
The signal tones mentioned are for example DTMF (Dual Tone Multi Frequency) digits. The DTMF digits are referred to below as DTMF
signal tones or signal tones for short. It is frequently necessary with a telephone connection for one party to the call to enter DTMF
signal tones which must be transported to the distant end. This is the case with an account query in telephone banking for example.
Telephone connections are currently made using two types of communication networks: the classical, circuit switched telephone network which serves primarily for speech transfer and the packet-switched data network which is primarily designed to transfer data.
The term circuit network will be used below as a short form of circuit-switched telephone network and packet network as a short form of packet switched network.
In classical circuit networks not only information is exchanged between the parties to the call but also information relating to the control of the circuit network itself. This information does not necessarily reach the parties to the call but is evaluated by the network node or by terminals. This exchange of information is referred to as signaling. Since defined communication paths are generally reserved for signaling in circuit networks, the term signaling networks is used. Basically the signaling for a circuit network can also be transferred over a packet network.
In addition there is the tendency to also use packet networks for transfer of information which was previously routed via classical circuit networks. Since the corresponding information is then not just routed via the classical circuit network, but also via packet networks, such networks are referred to as heterogeneous networks.
DTMF signal tones must also be transmitted if a classical telephone connection is routed via a packet network. The telephone or voice connection via a packet network is also called a VoIP (Voice-over-IP) connection. The transmission of the DTMF signal tones over the packet network is possible without any problems if the packet network involved is an IP (Internet Protocol) network and if a non-compressing codec, G.711 for example, is used for voice transmission, since in this case it is possible to transport the digital DTMF signal tones together with the voice information in the RTP (Real Time Protocol) data stream without problems.
If however a compressing codec is used for voice transmission, for example G.723 or G.729, it is not possible to simply transmit the digital DTMF signal tones in the RTP data stream since the DTMF
signal tones will not be transmitted without frequency corruption.
If compressing codes are used for voice transmission there are basically two standardized options for still transmitting the DTMF
signal tones.
One possibility is to transmit the DTMF signal tones in the RTP data stream with specific RTP packets in accordance with RFC2833 (RTP
Payload for DTMF Digits, Telephony Tones and Telephony signals. This method will be abbreviated to RTP transmission below.
There is also the option of removing the DTMF signal tones in a Media Gateway from the RTP data stream and transmitting them to bypass the packet network via the Media Gateway Controller by means of the MGCP (Media Gateway Control) and BICC (Bearer Independent Call Control) protocol. This method is referred to for short below as OUTBAND transmission.
However difficulties arise in heterogeneous networks, in which both first-generation Media Gateways and also newer Media Gateways are present, because a few Media Gateways support transmission of the DTMF signal tones in accordance with RFC2833 whereas others only support OUTBAND transmission and yet others do not support either of the two options.
Starting from this prior art, the object of the invention is to specify a method and also a device and a computer program product for selecting a transfer procedure for signal tones in heterogeneous networks.
This task is achieved in accordance with the invention by a method with the following steps:
- Notification of the transfer procedures usable for the signal tones which are supported by a first transfer exchange between packet network and circuit network from the first transfer exchange via a signaling network to a second exchange between packet network and circuit network - Selection of a transfer procedure supported by both the first exchange and also the second exchange for the DTMF signal tones by the second exchange and Notification of the transfer procedure selected by the second transfer exchange to the first transfer exchange.
This object is further achieved by a device designed to execute the procedure and a computer program product designed to execute the procedure.
With the method in accordance with the invention the transfer procedure supported by the first exchange is notified to the second exchange by the first exchange with the aid of the signaling network during the connection setup between a first and a second transfer exchange. The second exchange can select a transfer procedure which is supported by both transfer exchanges and can notify the first exchange of its choice. The transfer exchanges can then for example set up a voice connection over the packet network, taking into consideration the selected transfer procedure for the DTMF signal tones. The method in accordance with the invention ensures that the DTMF signal tones can always be transmitted, provided both transfer exchanges support a common transfer procedure for DTMF signal tones.
Without use of the method in accordance with the invention there would in most cases be no transmission of DTMF signal tones. The invention also ensures that for different transfer procedures of different quality the transfer procedure is always selected which is most suitable for transfer of DTMF signal tones.
In a preferred embodiment of the method in accordance with the invention transfer exchanges with a converter and a converter control each are used which communicate with each other using a modified standard protocol. Communication between the converter controls should also be undertaken using a modified standard protocol. For communication between the converters and the associated converter control MGCP in accordance with RFC2705 is used for example and for communication between the converter controls the BICC protocol in accordance with Q.763/Q.765.5 is used in a modified 5 form.
This embodiment offers the advantage that existing protocols have to be only slightly modified for execution of the method in accordance with the invention. Accordingly it can be made possible without any great effort for existing transfer exchanges to execute the method in accordance with the invention.
Further details are the subject of the dependent claims.
The invention is explained in detail below using the enclosed drawing. The diagrams show:
Figure 1 a block diagram showing a first part of the execution sequence of a method for transmission of digital DTMF
signal tones;
Figure 2 a further block diagram showing the second part of the execution sequence of the method from Figure 1;
Figure 3 a diagram of the data structure of a message sent from a first Media Gateway Controller to a second Media Gateway Controller;
Figure 4 a diagram of the data structure of an information element contained in the message from Figure 3;
The signal tones mentioned are for example DTMF (Dual Tone Multi Frequency) digits. The DTMF digits are referred to below as DTMF
signal tones or signal tones for short. It is frequently necessary with a telephone connection for one party to the call to enter DTMF
signal tones which must be transported to the distant end. This is the case with an account query in telephone banking for example.
Telephone connections are currently made using two types of communication networks: the classical, circuit switched telephone network which serves primarily for speech transfer and the packet-switched data network which is primarily designed to transfer data.
The term circuit network will be used below as a short form of circuit-switched telephone network and packet network as a short form of packet switched network.
In classical circuit networks not only information is exchanged between the parties to the call but also information relating to the control of the circuit network itself. This information does not necessarily reach the parties to the call but is evaluated by the network node or by terminals. This exchange of information is referred to as signaling. Since defined communication paths are generally reserved for signaling in circuit networks, the term signaling networks is used. Basically the signaling for a circuit network can also be transferred over a packet network.
In addition there is the tendency to also use packet networks for transfer of information which was previously routed via classical circuit networks. Since the corresponding information is then not just routed via the classical circuit network, but also via packet networks, such networks are referred to as heterogeneous networks.
DTMF signal tones must also be transmitted if a classical telephone connection is routed via a packet network. The telephone or voice connection via a packet network is also called a VoIP (Voice-over-IP) connection. The transmission of the DTMF signal tones over the packet network is possible without any problems if the packet network involved is an IP (Internet Protocol) network and if a non-compressing codec, G.711 for example, is used for voice transmission, since in this case it is possible to transport the digital DTMF signal tones together with the voice information in the RTP (Real Time Protocol) data stream without problems.
If however a compressing codec is used for voice transmission, for example G.723 or G.729, it is not possible to simply transmit the digital DTMF signal tones in the RTP data stream since the DTMF
signal tones will not be transmitted without frequency corruption.
If compressing codes are used for voice transmission there are basically two standardized options for still transmitting the DTMF
signal tones.
One possibility is to transmit the DTMF signal tones in the RTP data stream with specific RTP packets in accordance with RFC2833 (RTP
Payload for DTMF Digits, Telephony Tones and Telephony signals. This method will be abbreviated to RTP transmission below.
There is also the option of removing the DTMF signal tones in a Media Gateway from the RTP data stream and transmitting them to bypass the packet network via the Media Gateway Controller by means of the MGCP (Media Gateway Control) and BICC (Bearer Independent Call Control) protocol. This method is referred to for short below as OUTBAND transmission.
However difficulties arise in heterogeneous networks, in which both first-generation Media Gateways and also newer Media Gateways are present, because a few Media Gateways support transmission of the DTMF signal tones in accordance with RFC2833 whereas others only support OUTBAND transmission and yet others do not support either of the two options.
Starting from this prior art, the object of the invention is to specify a method and also a device and a computer program product for selecting a transfer procedure for signal tones in heterogeneous networks.
This task is achieved in accordance with the invention by a method with the following steps:
- Notification of the transfer procedures usable for the signal tones which are supported by a first transfer exchange between packet network and circuit network from the first transfer exchange via a signaling network to a second exchange between packet network and circuit network - Selection of a transfer procedure supported by both the first exchange and also the second exchange for the DTMF signal tones by the second exchange and Notification of the transfer procedure selected by the second transfer exchange to the first transfer exchange.
This object is further achieved by a device designed to execute the procedure and a computer program product designed to execute the procedure.
With the method in accordance with the invention the transfer procedure supported by the first exchange is notified to the second exchange by the first exchange with the aid of the signaling network during the connection setup between a first and a second transfer exchange. The second exchange can select a transfer procedure which is supported by both transfer exchanges and can notify the first exchange of its choice. The transfer exchanges can then for example set up a voice connection over the packet network, taking into consideration the selected transfer procedure for the DTMF signal tones. The method in accordance with the invention ensures that the DTMF signal tones can always be transmitted, provided both transfer exchanges support a common transfer procedure for DTMF signal tones.
Without use of the method in accordance with the invention there would in most cases be no transmission of DTMF signal tones. The invention also ensures that for different transfer procedures of different quality the transfer procedure is always selected which is most suitable for transfer of DTMF signal tones.
In a preferred embodiment of the method in accordance with the invention transfer exchanges with a converter and a converter control each are used which communicate with each other using a modified standard protocol. Communication between the converter controls should also be undertaken using a modified standard protocol. For communication between the converters and the associated converter control MGCP in accordance with RFC2705 is used for example and for communication between the converter controls the BICC protocol in accordance with Q.763/Q.765.5 is used in a modified 5 form.
This embodiment offers the advantage that existing protocols have to be only slightly modified for execution of the method in accordance with the invention. Accordingly it can be made possible without any great effort for existing transfer exchanges to execute the method in accordance with the invention.
Further details are the subject of the dependent claims.
The invention is explained in detail below using the enclosed drawing. The diagrams show:
Figure 1 a block diagram showing a first part of the execution sequence of a method for transmission of digital DTMF
signal tones;
Figure 2 a further block diagram showing the second part of the execution sequence of the method from Figure 1;
Figure 3 a diagram of the data structure of a message sent from a first Media Gateway Controller to a second Media Gateway Controller;
Figure 4 a diagram of the data structure of an information element contained in the message from Figure 3;
Figure 5 a diagram of the data structure of the message transferred from the second Media Gateway Controller to the first Media Gateway Controller;
Figure 6 a diagram of the data structure of a confirmation sent from the first Media Gateway Controller to the second Media Gateway Controller;
Figure 7 a block diagram with the first part of the sequence of a method for transmission of DTMF signal tones in heterogeneous networks;
Figure 8 a block diagram, showing the second part of the execution sequence of the Method from Figure 7. and Figure 9 a diagram of the data structure of a message from the second Media Gateway Controller to the first Media Gateway Controller, which contains the transfer procedure selected by the second Media Gateway controller.
Figure 1 shows two circuit networks 1 and 2 each connected via a Media Gateway 3 and 4 with an IP network 5. In IP network 5 Media Gateways 3 and 4 have IP addresses GwA and GwB and issue IP
addresses 6 and 7 for a voice connection. Media Gateways 3 and 4 are connected via PCM (Pulse Code Modulation) lines 8 and 9 to circuit networks 1 and 2 which are addressed via SS7 signaling. Media Gateways 3 and 4 operate as converters between circuit networks 1 and 2 and the IP network 5, since they convert the data formats of circuit networks 1 and 2 into the data format of IP network 5 and vice versa. Media Gateways 3 and 4 are also abbreviated below to MG
3 and 4.
Figure 6 a diagram of the data structure of a confirmation sent from the first Media Gateway Controller to the second Media Gateway Controller;
Figure 7 a block diagram with the first part of the sequence of a method for transmission of DTMF signal tones in heterogeneous networks;
Figure 8 a block diagram, showing the second part of the execution sequence of the Method from Figure 7. and Figure 9 a diagram of the data structure of a message from the second Media Gateway Controller to the first Media Gateway Controller, which contains the transfer procedure selected by the second Media Gateway controller.
Figure 1 shows two circuit networks 1 and 2 each connected via a Media Gateway 3 and 4 with an IP network 5. In IP network 5 Media Gateways 3 and 4 have IP addresses GwA and GwB and issue IP
addresses 6 and 7 for a voice connection. Media Gateways 3 and 4 are connected via PCM (Pulse Code Modulation) lines 8 and 9 to circuit networks 1 and 2 which are addressed via SS7 signaling. Media Gateways 3 and 4 operate as converters between circuit networks 1 and 2 and the IP network 5, since they convert the data formats of circuit networks 1 and 2 into the data format of IP network 5 and vice versa. Media Gateways 3 and 4 are also abbreviated below to MG
3 and 4.
Media Gateways 3 and 4 are assigned to Media Gateway Controllers 10 and 11 which communicate with each other via a signaling network 12.
Signaling network 12 can for example be the normal SS7 network. MGs 3 and 4 are controlled via Media Gateway Controllers 10 and 11.
Media Gateway Controllers 10 and 11 thus function as converter controls. Media Gateway Controllers are abbreviated below to MGC 10 and 11.
MG 3 together with MGC 10 forms a transfer exchange connecting packet network 5 with circuit network 1, which is located on the side subsequently referred to as the A-side of the voice connection via IP network 5.
Likewise MG 4 together with MGC 11 forms a further transfer exchange connecting packet network 5 with circuit network 2, which is located on the side subsequently referred to as the B-side of the voice connection.
At the beginning of the call setup MGC 10 on the A-side transmits to MG 3 on the A-side a request 13 in the form of a CRCX (Create Connection) command in accordance with RFC2705 (MGCP). The standardized parameters of this command are shown in Figure 1 and are not explained in greater detail. MG 3 responds with a message 14, in which both the transfer procedure supported and also the codecs used are notified to MGC 10. The data structure of notification 14 is in governed by RFC2705 (MGCP), in which case this data structure has been expanded by a parameter X-DTMFCA containing information on the transfer procedure supported by MG 3 on the A-side. Parameter XDTMFCA should be able to assume the following values:
X-DTMFCA: RFC2833 the MG supports the transmission of DTMF signal tones with the aid of an RTP data stream in accordance with RFC2833;
X-DTMFCA: OUTBAND the MG supports OUTBAND
transmission of DTMF signal tones;
X-DTMFCA: RFC2833 + OUTBAND the MG supports RTP transmission in accordance with RFC2833 and OUTBAND transmission and X-DTMFCA: NONE the MG does not support any special transmission procedure for DTMF signal tones.
Notification 14 contains the parameter X-DTMFCA, which in this case is set to the value RFC2833 + OUTBAND. In addition notification 14 contains the coders supported by MG 3. The supported codecs are specified within an SDP description unit (SDP session in accordance with RFC2327) in parameter m = Audio 3456 RTP/AVP 8 4. The "8" means that a non-compressing codec in accordance with G. 6.711 is supported whereas the "4" refers to a compressing codec in accordance with G.723. In addition port 3456 is also specified in parameter m. Notification 14 also contains, in parameter c, IP
address 6, which the MG 3 on the A-side has issued for the voice connection.
Subsequently MGC 10 on the A-side sends a notification 15 to MGC 11 on the B-side, in which MGC 11 on the B-side is notified about the transfer procedures for DTMF signal tones supported by MG 3 on the A-side. The data structure of this notification is explained in more detail below.
Subsequently MGC 11 on the B-side sends a request 16 to the assigned MG 4 on the B-side to set up a voice connection via the Internet to the MG 3 on the A-side. This is done in the form of a CRCX (Create Connection) command in accordance with RFC2705 (MGCP). In notification 15 the MG 4 on the B-side is notified about IP address 6 issued by MG 3 on the A-side for the voice connection and about the codecs supported by MG 3 on the A-side. In response to request 16 MG 4 on the B-side sends a message 17 which, like message 14, contains the parameter X-DTXFCA. Message 17 also contains the IP
address 7 of the MG 4 on the B-side as well as the codes supported by MG 4. From message 17 MGC 11 on the B-side deduces that only one compressing codec in accordance with G.723 and the OUTBAND
transmission of DTMF signal tones are supported by MG 4 on the B-side.
MGC 11 on the B-side then selects OUTBAND transmission since in the case discussed here only OUTBAND transmission is supported by MG 3 on the A-side and MG 4 on the B-side.
In accordance with Figure 2 MGC 11 then sends from the B-side a request 18 to MG 4 on the B-side, to notify it about the occurrence of digital signal tones at MGC 11 on the B-side. This is done in the form of a RQNT (Notification Request) command in accordance with RFC2705 (MGCP). In this command parameter R contains the request to the MG 4 on the B-side to notify DTMF signal tones occurring on the B-side to the MGC 11 on the B-side, so that the latter can send a corresponding message to the MGC 10 on the A-side, so the DTMF
signal tones extracted from the data stream by the MG 4 on the B-side can be reinserted into the data stream by MG 3 on the A-side.
The request 18 of MGC 11 on the B-side to MG 4 on the B-side is executed by MG 4 on the B-side and acknowledged with a confirmation 19 in accordance with RFC2705 (MGCP).
MGC 11 on the B-side then sends a notification 20 to MGC 10 on the A-side. This notification 20 is a message in accordance with the BICC protocol according to Q.763/Q.765.5 which can thus also be referred to as an ISUP+ message. The data structure of notification 5 20 is explained in greater detail below, as is the data structure of notification 15.
In response to notification 20, MGC 10 on the A-side issues a request 21 to MG 3 on the A-side to modify the voice connection via the IP network 5 according to the transfer procedure selected by MGC
Signaling network 12 can for example be the normal SS7 network. MGs 3 and 4 are controlled via Media Gateway Controllers 10 and 11.
Media Gateway Controllers 10 and 11 thus function as converter controls. Media Gateway Controllers are abbreviated below to MGC 10 and 11.
MG 3 together with MGC 10 forms a transfer exchange connecting packet network 5 with circuit network 1, which is located on the side subsequently referred to as the A-side of the voice connection via IP network 5.
Likewise MG 4 together with MGC 11 forms a further transfer exchange connecting packet network 5 with circuit network 2, which is located on the side subsequently referred to as the B-side of the voice connection.
At the beginning of the call setup MGC 10 on the A-side transmits to MG 3 on the A-side a request 13 in the form of a CRCX (Create Connection) command in accordance with RFC2705 (MGCP). The standardized parameters of this command are shown in Figure 1 and are not explained in greater detail. MG 3 responds with a message 14, in which both the transfer procedure supported and also the codecs used are notified to MGC 10. The data structure of notification 14 is in governed by RFC2705 (MGCP), in which case this data structure has been expanded by a parameter X-DTMFCA containing information on the transfer procedure supported by MG 3 on the A-side. Parameter XDTMFCA should be able to assume the following values:
X-DTMFCA: RFC2833 the MG supports the transmission of DTMF signal tones with the aid of an RTP data stream in accordance with RFC2833;
X-DTMFCA: OUTBAND the MG supports OUTBAND
transmission of DTMF signal tones;
X-DTMFCA: RFC2833 + OUTBAND the MG supports RTP transmission in accordance with RFC2833 and OUTBAND transmission and X-DTMFCA: NONE the MG does not support any special transmission procedure for DTMF signal tones.
Notification 14 contains the parameter X-DTMFCA, which in this case is set to the value RFC2833 + OUTBAND. In addition notification 14 contains the coders supported by MG 3. The supported codecs are specified within an SDP description unit (SDP session in accordance with RFC2327) in parameter m = Audio 3456 RTP/AVP 8 4. The "8" means that a non-compressing codec in accordance with G. 6.711 is supported whereas the "4" refers to a compressing codec in accordance with G.723. In addition port 3456 is also specified in parameter m. Notification 14 also contains, in parameter c, IP
address 6, which the MG 3 on the A-side has issued for the voice connection.
Subsequently MGC 10 on the A-side sends a notification 15 to MGC 11 on the B-side, in which MGC 11 on the B-side is notified about the transfer procedures for DTMF signal tones supported by MG 3 on the A-side. The data structure of this notification is explained in more detail below.
Subsequently MGC 11 on the B-side sends a request 16 to the assigned MG 4 on the B-side to set up a voice connection via the Internet to the MG 3 on the A-side. This is done in the form of a CRCX (Create Connection) command in accordance with RFC2705 (MGCP). In notification 15 the MG 4 on the B-side is notified about IP address 6 issued by MG 3 on the A-side for the voice connection and about the codecs supported by MG 3 on the A-side. In response to request 16 MG 4 on the B-side sends a message 17 which, like message 14, contains the parameter X-DTXFCA. Message 17 also contains the IP
address 7 of the MG 4 on the B-side as well as the codes supported by MG 4. From message 17 MGC 11 on the B-side deduces that only one compressing codec in accordance with G.723 and the OUTBAND
transmission of DTMF signal tones are supported by MG 4 on the B-side.
MGC 11 on the B-side then selects OUTBAND transmission since in the case discussed here only OUTBAND transmission is supported by MG 3 on the A-side and MG 4 on the B-side.
In accordance with Figure 2 MGC 11 then sends from the B-side a request 18 to MG 4 on the B-side, to notify it about the occurrence of digital signal tones at MGC 11 on the B-side. This is done in the form of a RQNT (Notification Request) command in accordance with RFC2705 (MGCP). In this command parameter R contains the request to the MG 4 on the B-side to notify DTMF signal tones occurring on the B-side to the MGC 11 on the B-side, so that the latter can send a corresponding message to the MGC 10 on the A-side, so the DTMF
signal tones extracted from the data stream by the MG 4 on the B-side can be reinserted into the data stream by MG 3 on the A-side.
The request 18 of MGC 11 on the B-side to MG 4 on the B-side is executed by MG 4 on the B-side and acknowledged with a confirmation 19 in accordance with RFC2705 (MGCP).
MGC 11 on the B-side then sends a notification 20 to MGC 10 on the A-side. This notification 20 is a message in accordance with the BICC protocol according to Q.763/Q.765.5 which can thus also be referred to as an ISUP+ message. The data structure of notification 5 20 is explained in greater detail below, as is the data structure of notification 15.
In response to notification 20, MGC 10 on the A-side issues a request 21 to MG 3 on the A-side to modify the voice connection via the IP network 5 according to the transfer procedure selected by MGC
10 11 on the B-side. A command in the form of an MDCX (Modified Connection) command in accordance with RFC2705 (MGCP) is used for this purpose, with the parameter R containing the request to the MG
3 on the A-side to notify the occurrence of DTMF signal tones to MGC
10 on the A-side so that MGC 10 on the A-side can send a corresponding notification to MGC 11 on the B-side, so that MG 4 on the B-side is in a position to reinsert into the data stream the DTMF signal tones extracted from the data stream by MG 3 on the A-side.
MG 3 on the A-side executes request 21 and acknowledges request 21 of MGC 10 on the A-side with a message 22 in accordance with RFC2705 (MGCP).
MGC 10 on the A-side then sends a notification 23 to MGC 11 on the B-side to notify MGC 11 on the B-side that call setup on the A-side is completed. With this notification 23 the call setup of a voice connection over IP network 5 is ended.
The data structure of notifications 15, 20 and 23 will be explained in more detail below.
3 on the A-side to notify the occurrence of DTMF signal tones to MGC
10 on the A-side so that MGC 10 on the A-side can send a corresponding notification to MGC 11 on the B-side, so that MG 4 on the B-side is in a position to reinsert into the data stream the DTMF signal tones extracted from the data stream by MG 3 on the A-side.
MG 3 on the A-side executes request 21 and acknowledges request 21 of MGC 10 on the A-side with a message 22 in accordance with RFC2705 (MGCP).
MGC 10 on the A-side then sends a notification 23 to MGC 11 on the B-side to notify MGC 11 on the B-side that call setup on the A-side is completed. With this notification 23 the call setup of a voice connection over IP network 5 is ended.
The data structure of notifications 15, 20 and 23 will be explained in more detail below.
Figure 3 shows the data structure of notification 15 in greater detail. This notification is a modified IAM (initial Address Message) in accordance with the BICC protocol as defined in Q.763/Q.765.5 (ISUP+). In particular the information is sent via the MG 3 on the A-side with the aid of the APP (Application Transport Parameter) which is specified within the framework of Recommendation Q.763 of ITU-T. A precise description of the APP can be found in document ITU-T Q.763/AND.1 (03/2001), Prepublished Version. As well as the data header shown in Figure 3, the APP contains a list of information elements.
A first information element 24 contains the IP address 6 which MG 3 on the A-side has specified for the voice connection. A second information element 25 contains the number the RTP port used by MG 3 on the A-side, while a further information element 26 contains a list of the codecs supported by MG 3 on the A-side. The information elements 24 to 26 are already specified in Standard Q.763/Q.765.5.
On the other hand there is a new information element 27 which describes the transfer procedure supported by MG3 on the A-side and is identified in Figure 5 by "DTMF Capability".
Figure 4 shows the data structure of information element 27 in detail. At the beginning there is an identification mark 28, followed by a length indicator 29. In addition information element 27 contains information 30 for compatibility and specifications 31 about the transfer procedure for die DTMF signal tones supported by MG 3 on the A-side. The following code is proposed for specification 31:
00000001 the OUTBAND transmission of DTMF signal tones with the aid of signaling network 12 is supported;
A first information element 24 contains the IP address 6 which MG 3 on the A-side has specified for the voice connection. A second information element 25 contains the number the RTP port used by MG 3 on the A-side, while a further information element 26 contains a list of the codecs supported by MG 3 on the A-side. The information elements 24 to 26 are already specified in Standard Q.763/Q.765.5.
On the other hand there is a new information element 27 which describes the transfer procedure supported by MG3 on the A-side and is identified in Figure 5 by "DTMF Capability".
Figure 4 shows the data structure of information element 27 in detail. At the beginning there is an identification mark 28, followed by a length indicator 29. In addition information element 27 contains information 30 for compatibility and specifications 31 about the transfer procedure for die DTMF signal tones supported by MG 3 on the A-side. The following code is proposed for specification 31:
00000001 the OUTBAND transmission of DTMF signal tones with the aid of signaling network 12 is supported;
00003010 RTP transmission in accordance with RFC2833 is supported;
03000011 OUTBAND transmission with the aid of signaling network 12 and RTP transmission in accordance with RFC2833 is supported.
In the example shown here entry 31 is set to 00000011. This means that MG 3 on the A-side supports both RTP transmission and also OUTBAND transmission.
Figure 5 shows the data structure of notification 20. Notification 20 is sent like notification 15 in the BICC protocol according to Standard Q.763/Q.765.5 (ISUP+). In particular the information is sent via the MG 4 on the B-side with the aid of the APP (Application Transport Parameter) which is specified as part of Recommendation Q.763 of the ITU-T As already mentioned, the APP contains, in addition to a data header not shown in Figure 5, a list of information elements.
A first information element 32 contains a description of the action whereas further information elements 33 and 34 contain the IP
address 7 issued by MG 4 on the B-side and the number of the RTP
port used by MG 4 on the B-side for the actual voice connection over IP network 5. A further information element 35 contains the codec selected by MGC 11 on the B-side. In the example shown here this is the compressing codec in accordance with G.723.1. Since DTMF signal tones cannot simply be transmitted over IP network 5 by a compressing codec, notification 23 additionally contains a further information element 36 which describes the transfer procedure selected by MGC 11 on the B-side. This information element 36, like information element 27 in Figure 3, is designated in Figure 5 by "DTMF Capability" and correspondingly encoded.
It should be mentioned that if a non-compressing codec, for example in accordance with G.711, is selected by MGC 11 on the B-side, information element 36 is omitted since in this case the DTMF signal tones are sent directly without the use of special methods over the IP network 5.
Figure 6 finally shows the data structure of notification 23, which in APP features an individual information element 37 which indicates the call setup status.
Figures 7 and 8 show block diagrams of a further exemplary embodiment. The exemplary embodiments of Figures 7 and 8 differ from the exemplary embodiments of Figures 1 and 2 in that, with the exemplary embodiments shown in Figures 7 and 8, MG 4 on the B-side not only supports OUTBAND transmission, but also RTP transmission in accordance with RFC2833. Accordingly MG 4 on the B-side responds to request 16 of MGC 11 on the B-side with a message 38, in which the parameter X-DTXFCA has been set to the value RFC2833 OUTBAND.
Since with the OUTBAND transmission of DTMF tones delays in the millisecond range between the sending and receipt of the DTMF signal tones occur, RTP transmission of the DTMF signal tones in accordance with RFC2833 is preferred. Accordingly MGC 11 on the B-side now selects RTP transmission in accordance with RFC2333 and directs a modified request 39 in accordance with RFC2135(MGCP) to the MG 4 on the B-side, with, in the options for parameter L an additional option dtmfsq:rfc2833 ensuring that MG 4 on the B-side transfers the digital DTMF signal tones directly over IP network 5 by means of RTP
in accordance with RFC2833.
03000011 OUTBAND transmission with the aid of signaling network 12 and RTP transmission in accordance with RFC2833 is supported.
In the example shown here entry 31 is set to 00000011. This means that MG 3 on the A-side supports both RTP transmission and also OUTBAND transmission.
Figure 5 shows the data structure of notification 20. Notification 20 is sent like notification 15 in the BICC protocol according to Standard Q.763/Q.765.5 (ISUP+). In particular the information is sent via the MG 4 on the B-side with the aid of the APP (Application Transport Parameter) which is specified as part of Recommendation Q.763 of the ITU-T As already mentioned, the APP contains, in addition to a data header not shown in Figure 5, a list of information elements.
A first information element 32 contains a description of the action whereas further information elements 33 and 34 contain the IP
address 7 issued by MG 4 on the B-side and the number of the RTP
port used by MG 4 on the B-side for the actual voice connection over IP network 5. A further information element 35 contains the codec selected by MGC 11 on the B-side. In the example shown here this is the compressing codec in accordance with G.723.1. Since DTMF signal tones cannot simply be transmitted over IP network 5 by a compressing codec, notification 23 additionally contains a further information element 36 which describes the transfer procedure selected by MGC 11 on the B-side. This information element 36, like information element 27 in Figure 3, is designated in Figure 5 by "DTMF Capability" and correspondingly encoded.
It should be mentioned that if a non-compressing codec, for example in accordance with G.711, is selected by MGC 11 on the B-side, information element 36 is omitted since in this case the DTMF signal tones are sent directly without the use of special methods over the IP network 5.
Figure 6 finally shows the data structure of notification 23, which in APP features an individual information element 37 which indicates the call setup status.
Figures 7 and 8 show block diagrams of a further exemplary embodiment. The exemplary embodiments of Figures 7 and 8 differ from the exemplary embodiments of Figures 1 and 2 in that, with the exemplary embodiments shown in Figures 7 and 8, MG 4 on the B-side not only supports OUTBAND transmission, but also RTP transmission in accordance with RFC2833. Accordingly MG 4 on the B-side responds to request 16 of MGC 11 on the B-side with a message 38, in which the parameter X-DTXFCA has been set to the value RFC2833 OUTBAND.
Since with the OUTBAND transmission of DTMF tones delays in the millisecond range between the sending and receipt of the DTMF signal tones occur, RTP transmission of the DTMF signal tones in accordance with RFC2833 is preferred. Accordingly MGC 11 on the B-side now selects RTP transmission in accordance with RFC2333 and directs a modified request 39 in accordance with RFC2135(MGCP) to the MG 4 on the B-side, with, in the options for parameter L an additional option dtmfsq:rfc2833 ensuring that MG 4 on the B-side transfers the digital DTMF signal tones directly over IP network 5 by means of RTP
in accordance with RFC2833.
In addition MGC 11 on the B-side transfers a notification 40 over the signaling network 12 to MG 10 on the A-side. In notification 40 MGC 10 on the A-side is notified of the selection of MGC 11 on the B-side. Accordingly MGC 10 on the A-side directs a request 41 according to RFC2705 (MGCP) to MG 3 on the A-side Request 41, like request 39, contains in parameter L the additional option x-dtmfsg:rfc2833, whereby it is indicated to MG 3 on the A-side that it is to transfer the DTMF signal tones directly over the IP network 5 buy means of RTP in accordance with RFC2833.
MG 3 on the A-side and MG 4 on the B-side react to request 39 and 41 in each case with the usual messages 19 and 22 in accordance with RFC2705 (MGCP).
Figure 9 again shows the data structure of notification 40. As regards information elements 32 to 35, notification 40 corresponds to notification 20 of the exemplary embodiment from Figures 1 and 2.
An information element 42, corresponding to information element 27 in Figure 3 and labeled "DTMF Capability" now merely contains the notification that the digital DTMF signal tones are to be transferred by means of RTP in accordance with RFC2833.
It should be noted that the method described does not necessarily have to be implemented in accordance with the MGCP Standard according to RFC2705. An analog implementation by modifying the Megaco (H.248) Standards is also possible. With this type of implementation communication between Media Gateway 3 and 4 and Media Gateway Controller 10 and 11 would be undertaken in accordance with the Megaco protocol (H.248). Parameter expansions X-DTMFCA and x-dtmfsg are then to be implemented similarly in the procedural steps which correspond to messages 14 and 17 and requests 39 and 41.
Basically an implementation in further standards corresponding to the MGCP Standard or the Megaco Standard is also possible.
The only important factor for the method described here is that MGC
11 on the B-side selects a possible combination of transfer 5 procedure for the DTMF signal tones and MGC 10 on the A-side signals via signaling network 12. If MG 3 on the A-side and MG 4 on the B-side feature a common transfer procedure for digital DTMF signal tones, a correction is always established for transfer by MGC 10 and 11. Of particular advantage here is the fact that the transfer 10 procedure for the DTMF signal tones which appears most suitable in each case can be selected.
Finally it should be noted that terms such as transfer exchange, converter, converter control, Media Gateway and Media Gateway Controller are to be understood in a functional sense. These logical 15 units do not necessarily have to form physical units but can also be realized in a physical unit in the form of software or conversely be distributed over a number of physical units.
MG 3 on the A-side and MG 4 on the B-side react to request 39 and 41 in each case with the usual messages 19 and 22 in accordance with RFC2705 (MGCP).
Figure 9 again shows the data structure of notification 40. As regards information elements 32 to 35, notification 40 corresponds to notification 20 of the exemplary embodiment from Figures 1 and 2.
An information element 42, corresponding to information element 27 in Figure 3 and labeled "DTMF Capability" now merely contains the notification that the digital DTMF signal tones are to be transferred by means of RTP in accordance with RFC2833.
It should be noted that the method described does not necessarily have to be implemented in accordance with the MGCP Standard according to RFC2705. An analog implementation by modifying the Megaco (H.248) Standards is also possible. With this type of implementation communication between Media Gateway 3 and 4 and Media Gateway Controller 10 and 11 would be undertaken in accordance with the Megaco protocol (H.248). Parameter expansions X-DTMFCA and x-dtmfsg are then to be implemented similarly in the procedural steps which correspond to messages 14 and 17 and requests 39 and 41.
Basically an implementation in further standards corresponding to the MGCP Standard or the Megaco Standard is also possible.
The only important factor for the method described here is that MGC
11 on the B-side selects a possible combination of transfer 5 procedure for the DTMF signal tones and MGC 10 on the A-side signals via signaling network 12. If MG 3 on the A-side and MG 4 on the B-side feature a common transfer procedure for digital DTMF signal tones, a correction is always established for transfer by MGC 10 and 11. Of particular advantage here is the fact that the transfer 10 procedure for the DTMF signal tones which appears most suitable in each case can be selected.
Finally it should be noted that terms such as transfer exchange, converter, converter control, Media Gateway and Media Gateway Controller are to be understood in a functional sense. These logical 15 units do not necessarily have to form physical units but can also be realized in a physical unit in the form of software or conversely be distributed over a number of physical units.
Claims (14)
1. Method for selecting a transfer procedure for DTMF signal tones in heterogeneous networks, the method comprising:
notification of the transfer procedure that can be used for the signal tones which are supported by a first transfer exchange between a packet network and a circuit network from the first transfer exchange over a signaling network to a second transfer exchange between the packet network and the circuit network;
selection by the second transfer exchange of a transfer procedure for the DTMF signal tones supported both by the first transfer exchange and the second transfer exchange; and notification of the transfer procedure selected by the second transfer exchange to the first transfer exchange.
notification of the transfer procedure that can be used for the signal tones which are supported by a first transfer exchange between a packet network and a circuit network from the first transfer exchange over a signaling network to a second transfer exchange between the packet network and the circuit network;
selection by the second transfer exchange of a transfer procedure for the DTMF signal tones supported both by the first transfer exchange and the second transfer exchange; and notification of the transfer procedure selected by the second transfer exchange to the first transfer exchange.
2. Method in accordance with claim 1, in which for the first transfer exchange and the second transfer exchange, a first converter and a second converter, each connecting the packet network and the circuit network, are used.
3. Method in accordance with claim 2, in which for the first transfer exchange and the second transfer exchange, a first converter control and a second converter control assigned to the first converter and second converter, respectively, and connected to the signaling network, are used.
4. Method in accordance with claim 3, in which the second converter control is notified by the first control, via the signaling network, about the transfer procedure supported by the first converter.
5. Method in accordance with claim 4, in which the second converter control selects the transfer procedure for the DTMF
signal tones.
signal tones.
6. Method in accordance with claim 5, in which the second converter control sends a notification containing information about the selected transfer procedure for the DTMF signal tones via the signaling network to the first converter control.
7. Method in accordance with any one of claims 4 to 6, in which notifications in respect of the transfer procedure for the DTMF signal tones between the first converter control and the second converter control comprise a first information element which is listed in a specified parameter and a second information element for codecs supported by the first and second converters.
8. Method in accordance with any one of claims 3 to 6, in which the first converter or the second converter sends a notification containing information about the selected transfer procedure for DMTF signal tones by means of a specific parameter within a message, with which the first converter control or the second converter control is notified about codecs supported by the first converter or the second converter.
9. Method in accordance with any one of claims 3 to 6, in which the first converter control or second converter control is notified of the transfer procedure to be set by a specified parameter (x-dtmfsg) within a respective request, with which the relevant converter is notified by the associated converter control about codecs supported by the converters at the distant end.
10. Method in accordance with any one of claims 1 to 9, in which a transfer via the packet network is selected as the method of transfer for the DTMF signal tones.
11. Method in accordance with any one of claims 2 to 10, in which a transfer procedure is selected in which the DTMF signal tones are extracted by the converters from the data stream and transmitted via the converter controls over the signaling network.
12. Device for conversion of information streams between a packet network and a circuit network, the device comprising means to execute a method in accordance with any one of claims 1 to 11.
13. Device in accordance with claim 12 comprising a converter connected to the packet network and to the circuit network and a converter control connected to the signaling network.
14. Computer-readable medium having embodied thereon a computer program for operating a transfer exchange between a packet network and a circuit network, the computer program containing program code comprising instructions which, when executed by processing structure, carry out the method in accordance with any one of claims 1 to 11.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP01125074A EP1304845A1 (en) | 2001-10-22 | 2001-10-22 | Method, device and computer program for transmission of signal tones in heterogeneous networks |
| EP01125074.3 | 2001-10-22 | ||
| PCT/EP2002/009692 WO2003036905A1 (en) | 2001-10-22 | 2002-08-30 | Method for the transmission of signal tones in heterogeneous networks, device and computer programme product |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2464296A1 CA2464296A1 (en) | 2003-05-01 |
| CA2464296C true CA2464296C (en) | 2013-01-15 |
Family
ID=8179035
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA2464296A Expired - Fee Related CA2464296C (en) | 2001-10-22 | 2002-08-30 | Method for transmission of signal tones in heterogeneous networks, device and computer program product |
Country Status (8)
| Country | Link |
|---|---|
| EP (2) | EP1304845A1 (en) |
| CN (1) | CN100505740C (en) |
| AT (1) | ATE448622T1 (en) |
| AU (1) | AU2002337040B2 (en) |
| CA (1) | CA2464296C (en) |
| DE (1) | DE50213995D1 (en) |
| NZ (1) | NZ532954A (en) |
| WO (1) | WO2003036905A1 (en) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1836432B (en) | 2003-06-17 | 2011-01-26 | 诺基亚西门子通信有限责任两合公司 | More economical resource application on the user interaction with a speech dialogue system in a packet network by means of a simplifying processing of signalling information |
| CN100531194C (en) * | 2004-09-07 | 2009-08-19 | 华为技术有限公司 | Service signal processing system and method for group domain |
| CN100413351C (en) * | 2005-08-31 | 2008-08-20 | 华为技术有限公司 | Processing method for bearing control |
| FR2927291B1 (en) | 2008-02-07 | 2016-03-04 | Livbag | GAS GENERATOR FOR A SAFETY DEVICE, THE LOAD OF WHICH IS INITIATED BY A HEAT GENERATING MEANS. |
| CN101552846B (en) * | 2008-03-31 | 2013-03-20 | 华为技术有限公司 | Method and device for processing dialing information in media stream |
| CN101651759B (en) * | 2008-08-13 | 2011-04-20 | 华为技术有限公司 | Method, system and equipment for controlling media player |
| CN101489156B (en) | 2008-12-17 | 2011-11-16 | 华为技术有限公司 | Multiplexing method for communication signal, radio communication system and radio equipment controller |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6259691B1 (en) * | 1998-07-24 | 2001-07-10 | 3Com Corporation | System and method for efficiently transporting dual-tone multi-frequency/multiple frequency (DTMF/MF) tones in a telephone connection on a network-based telephone system |
| US6842447B1 (en) * | 1999-06-14 | 2005-01-11 | Mci, Inc. | Internet protocol transport of PSTN-to-PSTN telephony services |
| US7039044B1 (en) * | 1999-10-14 | 2006-05-02 | Mindspeed Technologies, Inc. | Method and apparatus for early detection of DTMF signals in voice transmissions over an IP network |
| US6771641B1 (en) * | 1999-12-10 | 2004-08-03 | Nortel Networks Limited | DTMF digit collection and transportation for a packet network |
-
2001
- 2001-10-22 EP EP01125074A patent/EP1304845A1/en not_active Withdrawn
-
2002
- 2002-08-30 CA CA2464296A patent/CA2464296C/en not_active Expired - Fee Related
- 2002-08-30 WO PCT/EP2002/009692 patent/WO2003036905A1/en not_active Application Discontinuation
- 2002-08-30 DE DE50213995T patent/DE50213995D1/en not_active Expired - Lifetime
- 2002-08-30 EP EP02772238A patent/EP1438823B1/en not_active Expired - Lifetime
- 2002-08-30 NZ NZ532954A patent/NZ532954A/en unknown
- 2002-08-30 AU AU2002337040A patent/AU2002337040B2/en not_active Ceased
- 2002-08-30 CN CN02820984.2A patent/CN100505740C/en not_active Expired - Fee Related
- 2002-08-30 AT AT02772238T patent/ATE448622T1/en active
Also Published As
| Publication number | Publication date |
|---|---|
| AU2002337040B2 (en) | 2005-10-27 |
| EP1304845A1 (en) | 2003-04-23 |
| EP1438823A1 (en) | 2004-07-21 |
| CA2464296A1 (en) | 2003-05-01 |
| NZ532954A (en) | 2006-11-30 |
| DE50213995D1 (en) | 2009-12-24 |
| ATE448622T1 (en) | 2009-11-15 |
| CN1575576A (en) | 2005-02-02 |
| EP1438823B1 (en) | 2009-11-11 |
| WO2003036905A1 (en) | 2003-05-01 |
| CN100505740C (en) | 2009-06-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6885658B1 (en) | Method and apparatus for interworking between internet protocol (IP) telephony protocols | |
| US9356973B2 (en) | Method for the transmission of signalling data in a network interface unit and in a control unit and corresponding devices | |
| US7746845B2 (en) | Support for fax and modem in SIP/SIP-T networks and the interworking of these networks with ISUP+/BICC | |
| EP2114049B1 (en) | Video interworking gateway, system and method for realizing video call service | |
| US20030193696A1 (en) | Voice and fax over IP call establishment in a communications network | |
| US7778243B2 (en) | Method for DTMF transfer by RTP | |
| US20040125791A1 (en) | Method for transmitting fax data via a packet transmission network | |
| US7385964B2 (en) | System, method and computer program for changing over between a voice transmission and a fax transmission | |
| CA2464296C (en) | Method for transmission of signal tones in heterogeneous networks, device and computer program product | |
| EP1302046B1 (en) | System and method for controlling a media gateway | |
| US7508821B2 (en) | Method for setting up a data connection between terminal devices | |
| US6449285B1 (en) | Device for matching dissimilar telecommunications protocols | |
| US20040042409A1 (en) | Method for defining the coding for useful information generated according to different coding laws between at least two subscriber terminals | |
| US7359320B2 (en) | Method for supporting quality of service features in heterogeneous communications networks | |
| US7792143B1 (en) | Method and apparatus for interworking dissimilar text phone protocols over a packet switched network | |
| CN100505656C (en) | Modem relay aggregator device | |
| US7539177B2 (en) | Call hold/terminal portability in H.323/ISUP-BICC-SIP networks | |
| KR19990083853A (en) | Gateway system and controlling method for voice communication | |
| US20030076820A1 (en) | Signaling method for transmitting working data over different types of data transmission networks | |
| US20030026274A1 (en) | Switching process and apparatus for the transmission of user data packets | |
| EP1650928B1 (en) | Method for interworking between internet protocol (IP) telephony protocols | |
| US20040105437A1 (en) | Method for transmitting data of different applications via packet transmission network, corresponding units and corresponding program | |
| JP2005286971A (en) | Gateway device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |
Effective date: 20190830 |