NZ532954A

NZ532954A - Method for the transmission of signal tones in heterogeneous networks, device and computer programme product

Info

Publication number: NZ532954A
Application number: NZ532954A
Authority: NZ
Inventors: Thomas Baumann
Original assignee: Siemens Ag
Priority date: 2001-10-22
Filing date: 2002-08-30
Publication date: 2006-11-30
Also published as: EP1438823A1; CA2464296A1; DE50213995D1; CA2464296C; ATE448622T1; AU2002337040B2; WO2003036905A1; EP1438823B1; CN1575576A; EP1304845A1; CN100505740C

Abstract

A method for selecting a transfer procedure for DTMF signal tones in heterogeneous networks is disclosed. The method includes the steps of: (a) notifying of the transfer procedure that can be used for the signal tones, whereby the signal tones are supported by a first transfer exchange located between a packet network and a circuit network, from the first transfer exchange over a signalling network to a second transfer exchange between the packet network and the circuit network, (b) the second transfer exchange selects a transfer procedure for DTMF signal tones which is supported both by the first transfer exchange and the second transfer exchange, and (c) notifying the first transfer exchange of the transfer procedure that is selected by the second transfer exchange.

Description

532954 method for the transmission of signal tones in heterogeneous networks, device and computer programme 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 15 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 20 form of packet switched network.

In classical rii cui-. notwoi ks not only intorma'.i.nn is ^xohari't^! between the parties to the call but also information relating io t.no 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 13 SEP 2006 leivfdi WO 03/036905 PCT/EP02/09692 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-15 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 20 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 25 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 RFC2B33 whereas others only support OUTBAND transmission and yet others do not support either of the two options.

Thus, a need exists to provide a method and also a device and a computer program product for selecting a transfer procedure for signal tones in heterogeneous networks.

According to a first aspect of the present disclosure, there is provided a method for selecting a transfer procedure for DTMF signal tones in heterogeneous networks, said method comprising the steps of: notifying 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 signalling network to a second transfer exchange between packet network and circuit network; selecting by the second transfer exchange of a transfer procedure for DTMF signal tones supported both by the first transfer exchange and also the second transfer exchange; and notifying of the transfer procedure selected by the second transfer exchange to the first transfer exchange.

[R:\LIBQ]2960.doc:MIC INTELLECTUAL PROPERTY OFFICE OF N.Z. f 3 SEP 2006 R F a P I \/ c n There is also provided a device designed to execute the procedure and a computer program product designed to execute the procedure.

With the method in accordance with an embodiment of 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 an embodiment of 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 suing a modified standard.

[R:\LlBQ12960.doc .MIC INTELLECTUAL PROPERTY OFFICE OF N.Z. t 3 SEP 2006 D CO r I \/ r- r\ 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 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. In the example of Fig. 1, IP address 6 is 128.95.33.2, and IP address 7 is 129.25.34.1. PCM line 8 is addressed as mopcl/pal/17, and PCM line 9 is addressed as mopc5/pa3/12. Media Gateways 3 and 4 operate as converters between circuit networks 1 and 2 and the IP network 5, since they convert the data foraiats 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.

[R:\LI BQJ3034.doc: MIC INTELLECTUAL PROPERTY OFFICE OF N.Z. 13 SEP 2006 RECEIVED 7 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 s 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 13 are shown in Table 1 below and are not 20 explained in greater detail.

Table 1 RFC 2705: CRCX 4711 mopcl/pal/17@agwl.ipop.net MGCP 1.0 C:1234 L: p:30, a:PCMA; G723;G729, e.on, s:off, gc;0, t:0 M: inactive X-MaJiBu:10 [R:\i.IBQ13034.doc: MIC INTELLECTUAL PROPERTY OFFICE OF N.2. 13 SEP 2006 1-1 l"~ I— ■ i i ■— K 8 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 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 5 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 X-DTMFCA: RFC2833 +OUTBAND the MG supports OUTBAND transmission of DTMF signal tones; 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 codecs 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" 30 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.

[R:\LIBQJ3034.doc MIC INTELLECTUAL PROPERTY OFFICE OF N.2. 13 SEP 2006 RECEIV E D Parameters of the notification 14 are shown in Table 2 below.

Table 2 RFC 2705: 200 4711 OK LFD2E28 X-DTMFCA: RFC2833 + OUTBAND v = 0 c = IN IP4 128.95.33.2 m = audio 3456 RTP/A VP 8 4 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.

[R.\UBQJ3034.doc: MIC INTELLECTUAL PROPERTY OFFICE OF N.Z. 1 3 SEP 2006 RCTClX/rrN Parameters of request 16 are shown in Table 3 below.

Table 3 RFC 2705: CRCX4712 mopc5/pa3/l2@agw2.ipop.net MGCP 1.0 C:1234 L: p:30, a:PCMA;G723, e:on, s:off, gc:0, to:0: M: senrecv X-MaJiBu:10 v = 0 c = IN IP4 128.95.33.2 m = audio3456 RTP/AVP 8 4 Parameters of message 17 are shown in Table 4 below.

Table 4 RFC 2705: 200 4712 OK I: E23D48 X-DTMF C A: OUTBAND v = 0 c = IN IP4 129.25.34.1 m = audio 4442 RTP/AVP 4 INTELLECTUAL PROPERTY OFFICE OF N.Z. 1 3 SEP 2006 RFnpix/cn 11 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.

Parameters of the request 18 are shown in Table 5 below.

Table 5 RFC 2705: RQNT 4713 mopc5/pa3/l 2@agw2.ipop.net MGCP 1.0 X: A38B R: D/[0-9#*A-D](N) ;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). ;Parameters of the confirmation 19 are shown in Table 6 below. ;Table 6 ;RFC 2705: 200 4713 OK ;INTELLECTUAL PROPERTY ;OFFICE OF N.Z. ;13 SEP 2006 ;[R:\LlBQ]3034.doc:MlC ;n r ;12 ;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 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 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. ;Parameters of the request 21 are shown in Table 7 below. ;Table 7 ;RFC 2705: ;MDCX 4714 mopcl/pal/17@agwl.ipop.net MGCP 1.0 ;C:1234 ;I: FD2E28 ;L: p:30, a: G723; e:on, ;s:off; gc:0, t:0 ;M: sendrecv ;X: 27C8 ;R: D/["0-9#*A-D](N) v = 0 c = IN IP4 129.25.34.1 m = audio 4442 RTP/AVP 4 [R:\LI BQ]3034.doc:MIC INTELLECTUAL PROPERTY OFFICE OF N.Z. 13 SEP 2006 13 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).

Parameters of the message 22 are shown in Table 8 below.

Table 8 RFC 2705: 200 4714 OK 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-20 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 30 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". 1R:\UBQ]3034 doc:M!C INTELLECTUAL PROPERTY OFFICE OF N.Z. 13 SEP 2006 nr^nx/cn 14 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 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 RFC2S33 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.

[R:\L1 BQJ3034.doc: MIC INTELLECTUAL PROPERTY OFFICE OF N.Z. 1 q ccp onnfi 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.

Parameters of message 38 are shown in Table 9 below.

Table 9 RFC 2705: 200 4712 OK I: E23D48 X-DTMFCA: RFC2833 + OUTBAND v = 0 c = IN IP4 129.25.34.1 m = audio 4442 RTP/AVP 4 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 [R:\LI BQJ3034.doc: MIC INTELLECTUAL PROPERTY OFFICE OF N.2. 13 SEP 2006 16 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 5 means of RTP in accordance with RFC2833.

Parameters of the request 39 are shown in Table 10 below.

Table 10 RFC 2705: RQNT 4713 mopc5/pa3/l 2@agw2.ipop.net MGCP 1.0 C:1234 I: E23D48 L: p:30, aG723, e:on, s:off, gc:0, t:0, x-dtmfsg: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 15 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 by means of RTP in accordance with RFC2833.

[R:\LlBQ13034.doc: MIC INTELLECTUAL PROPERTY OFFICE OF N.Z. 1 3 SEP 2006 RECEIVED 17 Parameters of the request 41 are shown in Table 11 below.

Table 11 RFC 2705: MDCX 4714 mopcl/pal/17@agwl.ipop.net MGCP 1.0 C:1234 I: FD2E28 L: p:30, a:G723; e:on, s:off, gc:0, t:0 x-dtmfsg:rfc2833 M: sendrecv v = 0 c - IN IP4 129.25.34.1 m = audio 4442 RTP/AVP 4 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).

Parameters of the message 19 are shown in Table 12 below.

Table 12 RFC 2705: 200 4713 OK INTELLECTUAL PROPERTY OFFICE OF N.Z. 13 SEP 2006 RECEIVED [K:\L1BQ]3034 doc:MIC 18 Parameters of the message 22 are shown in Table 13 below.

Table 13 RFC 2705: 200 4714 OK 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.

INTELLECTUAL PROPERTY OFFICE OF N.Z. ' 3 SEP 2006 RECEIVED [R:\LIBQJ3034.doc: MIC

Claims

19 The claims defining the invention are as follows:

1. A method for selecting a transfer procedure for DTMF signal tones in heterogeneous networks, said method comprising the steps of: notifying 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 signalling network to a second transfer exchange between packet network and circuit network; selecting by the second transfer exchange of a transfer procedure for DTMF signal tones supported both by the first transfer exchange and also the second transfer exchange; and notifying of the transfer procedure selected by the second transfer exchange to the first transfer exchange.

2. The method according to Claim 1, wherein for the first transfer exchange and the second transfer exchange a first converter and second converter each connecting a packet network and circuit network are used.

3. The method according to Claim 2, wherein for the first transfer exchange and the second transfer exchange a first converter control and second converter control assigned to the first converter and second converter in each case and connected to the signalling network are used.

4. The method according to Claim 3, wherein the transfer procedure supported by the first converter is notified by the first converter control via the signalling network to the second converter control.

5. The method according to Claim 4, wherein the second converter control selects the transfer procedure for the DTMF signal tones.

6. The method according to Claim 5, wherein the second converter control notifies the selected transfer procedure for the DTMF signal tones via the signaling network to the first converter control. |R:\LIBQ]2960.doc:MIC INTELLECTUAL PROPERTY OFFICE OF N.Z. 13 SEP 2006 20

7. The method according to any one of Claims 4 to 6, wherein communications concerning the transfer procedure for the signal tones between the first converter control and the second converter control comprise, in addition to an information element for the codecs supported by the converters, a further information element which is listed in a specified parameter in addition to the information element.

8. The method according to any one of Claims 3 to 7, wherein the first converter or second converter of the converter control or second converter control assigned in each case notifies the transfer procedure for DTMF signal tones supported by a specified parameter within a message in each case, with which the relevant converter control is notified about the codecs supported by the relevant converter.

9. The method according to any one of Claims 3 to 8, wherein the first converter control or the second converter control of the first converter or second converter assigned in each case is notified of the transfer procedure to be set by a specified parameter within a request in each case, with which the relevant converter is notified by the associated converter control about the codecs supported by the converter at the distant end.

10. The method according to any one of Claims 1 to 9, wherein a transfer via the packet network is selected as the method of transfer for the DTMF signal tones.

11. The method according to any one of Claims 1 to 10, wherein 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. A device for converting information streams between a packet-based network and a circuit based network, comprising means configured for practising a method according to any one of Claims 1 to 11. [R:\LIBQ]2960.doc:MIC INTELLECTUAL PROPERTY OFFICE OF N.Z. 1 3 SEP 2006 RECEIVED 21

13. The device according to Claim 12, featuring a converter connected to the packet network and to the circuit network and a converter control connected to a signalling network.

14. A computer program product for operating a transfer exchange between a packet network and a circuit network which contains program code for executing a method in accordance with any one of the Claims 1 to 11.

15. A method for selecting a transfer procedure for DTMF signal ones on hetergenous networks, said method being substantially as described herein with reference to the accompanying drawings.

16. A device for converting information streams between a packet-based network and a circuit-based network, said device being substantially as describe herein with reference to the accompanying drawings.

17. A computer program product for operating a transfer exchange between a packet network and a circuit network, said computer program product being substantially as described herein with reference to the accompanying drawings. DATED this eighth Day of September, 2006 Siemens Aktiengesellschaft Patent Attorneys for the Applicant SPRUSON & FERGUSON j INTELLECTUAL PROPERTY I OFFICE OF N.Z. I ' 3 SEP 2006 IR E C Eiv f n [R:\LIBQ]2960.doc:MIC