RTP transparent transmission method based on IPPBX and IPPBX

Abstract

The invention provides an RTP (Real Time Protocol) transparent transmission method based on IPPBX (Internet Protocol Private Branch Exchange) and the IPPBX, and the method comprises the following steps: after a calling party calls a called party and the called party answers, the IPPBX judges whether two channels exist in bridging; when two channels exist and both the two channels meet the RTP transparent transmission capability, the IPPBX judges whether an activity process needing audio exists in the two channels or not; and when the two channels do not have an active process needing audio, the IPPBX obtains all codes supported by the calling client and the called client, and when the codes supported by the calling client and the called client have an intersection, at least one code in the intersection is used for performing intelligent negotiation between the calling client and the called client for communication. By means of the technical scheme, the codes supported by both the calling client and the called client are obtained in the conversation process, and after RTP transparent transmission is triggered, it can be guaranteed that the silent problem caused by inconsistent codes cannot occur after RTP transparent transmission.

Description

Technical Field

[0001] The present invention relates to communication technologies based on IPPBX, and particularly to an RTP transparent transmission method based on IPPBX and the IPPBX. Background Art

[0002] RTP transparent transmission is a technology used to directly forward RTP data packets in intermediate devices such as SIP proxies or media gateways without decoding or processing the packet content. This technology is very useful in various real-time audio and video communication scenarios, especially when it is necessary to reduce processing latency and improve transmission efficiency.

[0003] The disadvantages of traditional RTP transparent transmission include:

[0004] 1. Encoding inconsistency problem: In RTP transparent transmission, the encoding formats of the calling and called parties may be inconsistent, resulting in no sound after transparent transmission.

[0005] 2. Unable to use feature codes after RTP transparent transmission: After RTP transparent transmission, since RTP does not pass through the IPPBX, the IPPBX end cannot receive the DTMF sent by the phone, resulting in the phone being unable to use the feature code function of the IPPBX.

[0006] 3. The Secure Real-time Transport Protocol (SRTP) cannot support key updates: In the scenario of traditional RTP transparent transmission, the SRTP keys sent to the calling and called parties after RE-INVITE are pre-written and fixed by the IPPBX; when the client initiates RE-INVITE to change the key, there is a possibility of problems such as key management confusion. Summary of the Invention

[0007] Embodiments of the present invention provide an RTP transparent transmission method based on IPPBX and the IPPBX to solve the problem of encoding inconsistency existing in existing RTP transparent transmission methods.

[0008] To achieve the above object, on the one hand, an RTP transparent transmission method based on IPPBX is provided, including:

[0009] After the calling party calls the called party and the called party answers, the IPPBX determines whether there are two channels in the bridge.

[0010] When there are two channels and both of these channels meet the RTP transparent transmission capability, the IPPBX determines whether there is an active process that requires audio in these two channels.

[0011] When there is no active process that requires audio in these two channels, the IPPBX obtains all the encodings supported by the calling and called clients, and when there is an intersection in the encodings supported by the calling and called clients respectively, at least one encoding in the intersection is used for intelligent negotiation between the calling and called clients to communicate.

[0012] Preferably, the RTP transparent transmission method further includes:

[0013] During a call, the IPPBX saves the SRTP encryption keys sent by the calling and called clients, and after triggering RTP transparent transmission, exchanges the SRTP encryption keys sent by the calling and called clients between the calling and called clients.

[0014] Preferably, the RTP transparent transmission method further includes:

[0015] When there is an activity that requires audio in these two channels and the RTP bonding type of these two channels is the local type, the IPPBX determines whether the DMTF modes of these two channels are the same; if so, binds DMTF-HOOK to these two channels respectively, and sets the DMTF modes of these two channels to INFO after binding DMTF-HOOK.

[0016] Preferably, before performing RTP transparent transmission, the RTP transparent transmission method further includes:

[0017] The IPPBX determines whether the PTIME parameter settings of these two channels are the same; if so, performs RTP transparent transmission; otherwise, exits the process.

[0018] Preferably, for the RTP transparent transmission method, the IPPBX determines whether there is an intersection between the encodings supported by the calling and called clients respectively through the following steps:

[0019] After receiving the INVITE request from the caller, the IPPBX saves the encoding carried in the SDP in the INVITE request;

[0020] Calls the called party, and after the called party answers, saves the encoding carried in the SDP in all 200OK replies of the called party;

[0021] After the calling and called parties join the bridge and RTP transparent transmission is allowed, determine whether there is an intersection between the encoding carried in the SDP in the INVITE request and the encoding carried in the SDP in all 200OK replies of the called party; if so, allow RTP transparent transmission, and carry the first encoding in the intersection in the RE-INVETE request sent to the calling and called parties; otherwise, do not allow RTP transparent transmission.

[0022] Preferably, for the RTP transparent transmission method, determining whether a channel meets the transparent transmission capability includes the following steps:

[0023] Judge whether the calling client or the called client is registered through a locally deployed session border controller; if so, determine that the channel corresponding to the calling client or the called client does not meet the transparent transmission capability; otherwise, continue to the next step;

[0024] Determine whether the session border controller routing is enabled for the channel corresponding to the calling client or the called client; if so, determine that the channel corresponding to the calling client or the called client does not meet the pass-through capability; otherwise, proceed to the next step;

[0025] Determine whether the calling client or the called client is registered through FQDN; if so, determine that the channel corresponding to the calling client or the called client does not meet the pass-through capability.

[0026] On the other hand, an IPPBX is provided, including a memory and a processor, where the memory stores at least one program, and the at least one program is executed by the processor to implement the RTP pass-through method as described in any of the above.

[0027] The above technical solution has the following technical effects:

[0028] The technical solution of the present invention obtains the encoding supported by both the calling and called clients during the call. After triggering RTP pass-through, the encoding supported by both parties is carried in the RE-INVITE, which can ensure that there will be no silent problem caused by inconsistent encoding after RTP pass-through;

[0029] Furthermore, the embodiment of the present invention saves the SRTP encryption keys sent by the calling and called clients to the IPPBX during the call. After triggering RTP pass-through, instead of generating keys by the IPPBX, the keys of the calling and called parties are exchanged, which can support SRTP key update and avoid the problem of key management confusion at the IPPBX end;

[0030] Furthermore, after the client such as an extension enables support for RTP pass-through in the embodiment of the present invention, the DTMF mode of the client such as a telephone is automatically changed to INFO, which can ensure that the DMTF of the telephone can be sent to the IPPBX together with the INFO packet after pass-through, so that the feature code can be supported after RTP pass-through. Description of the Drawings

[0031] Figure 1 It is a flowchart of the RTP pass-through method based on IPPBX according to an embodiment of the present invention;

[0032] Figure 2 It is a flowchart of the RTP pass-through method based on IPPBX according to another embodiment of the present invention;

[0033] Figure 3 It is a flowchart of determining whether the channel meets the pass-through capability in the RTP pass-through method based on IPPBX according to an embodiment of the present invention;

[0034] Figure 4In the RTP transparent transmission method based on IPPBX according to an embodiment of the present invention, it is a schematic flow chart for determining whether there is any process requiring audio activity in a channel;

[0035] Figure 5 In the RTP transparent transmission method based on IPPBX according to an embodiment of the present invention, it is a schematic flow chart for determining the RTP bonding type of two channels;

[0036] Figure 6 In the RTP transparent transmission method based on IPPBX according to an embodiment of the present invention, it is a schematic flow chart for determining whether there is an intersection in the encodings of two channels. Detailed implementation manners

[0037] To further illustrate each embodiment, the present invention provides accompanying drawings. These drawings are part of the disclosure of the present invention, mainly used to illustrate the embodiments, and can be combined with the relevant descriptions in the specification to explain the operating principles of the embodiments. With reference to these contents, those of ordinary skill in the art should be able to understand other possible implementation manners and the advantages of the present invention. The components in the drawings are not drawn to scale, and similar component symbols are usually used to represent similar components.

[0038] Now, the present invention will be further described in combination with the accompanying drawings and specific implementation manners.

[0039] Embodiment 1:

[0040] Figure 1 It is a schematic flow chart of the RTP transparent transmission method based on IPPBX according to an embodiment of the present invention. As Figure 1 , the RTP transparent transmission method based on IPPBX in this embodiment includes:

[0041] After the calling party calls the called party and the called party answers, the IPPBX determines whether there are two channels in the bridge;

[0042] When there are two channels and both of these two channels meet the RTP transparent transmission capability, the IPPBX determines whether there is a process requiring audio activity in these two channels;

[0043] When there is no process requiring audio activity in these two channels, the IPPBX obtains all the encodings supported by the calling and called clients, and when there is an intersection in the encodings supported by the calling and called clients respectively, at least one encoding in the intersection is used for intelligent negotiation between the calling and called clients for communication.

[0044] Among them, the processes requiring audio activity include: normal / whisper / forced insertion monitoring, call recording, automatic gain or automatic noise reduction, etc.

[0045] Figure 2 It is a schematic flow chart of the RTP transparent transmission method based on IPPBX according to another embodiment of the present invention. AsFigure 2 , the RTP transparent transmission method based on IPPBX in this embodiment includes:

[0046] After the calling party calls the called party and the called party answers, the IPPBX determines whether there are two channels in the bridge; these two channels are namely a calling party channel such as channel 1 and a called party channel such as channel 2; if so, execute the next step, otherwise, exit the process;

[0047] Confirm whether the two channels meet the transparent transmission capability? If so, continue to the next step; otherwise, exit the process;

[0048] Confirm whether there is any active process that requires audio in the two channels? If so, exit the process; otherwise, continue to the next step;

[0049] Confirm the RTP adhesion type of the two channels? Among them, the RTP adhesion type refers to the processing method or path of the RTP stream; if the RTP adhesion type of the two channels is LOCAL or REMOTE, then continue to the next step; otherwise, exit the process;

[0050] Respectively determine whether channel 1 and channel 2 are bound with DTMFHOOK? And when they are respectively bound with DTMFHOOK, continue to determine whether the DTMF modes of channel 1 and channel 2 are INFO; if not, set the DTMF modes of channel 1 and channel 2 to INFO; among them, binding DMTF-HOOK means that this channel can receive and process the DTMF signals input by phone keys; in a specific implementation, it may also include: confirm whether the DMTF modes of the two channels are consistent? If it is judged from the SDP carried by the client that the DMTF modes are both INFO, then DMTF_HOOK can be ignored. If the RTP adhesion type is local and the DMTF modes are inconsistent, that is, incompatible, then the channel cannot be bound with DMTFHOOK and the process exits;

[0051] Obtain the encodings of the two channels, that is, obtain the encoding capabilities of the calling and called clients, and determine whether there is an intersection in the encodings of the two channels?

[0052] Judge whether the SRTP encryption methods of the two channels are consistent? If so, continue to the next step; otherwise, exit the process; in a specific implementation, it also includes, after judging that the SRTP encryption methods of the two channels are consistent, saving the SRTP keys of the two channels, and after triggering RTP transparent transmission, exchanging the SRTP encryption keys sent by the calling and called clients between the calling and called clients;

[0053] Judge whether the PTIME parameter values of the two channels are consistent. Specifically, judge according to the SDP carried by the client; if so, transparent transmission between the two channels can be performed, otherwise, exit the process.

[0054] Figure 3 In the RTP transparent transmission method based on IPPBX according to an embodiment of the present invention, it is a schematic flowchart for determining whether a channel meets the transparent transmission capability. As Figure 3 , determining whether a channel meets the transparent transmission capability includes the following steps:

[0055] Determine whether the client, such as the calling and called clients, is registered through a locally deployed session border controller (on-premise SBC, On-Premise Session Border Controller), that is, whether the client forwards SIP to the IPPBX through the SBC; if so, it is determined that the channel does not meet the RTP transparent transmission capability, and the process ends; otherwise, continue to the next step; specifically, when the client is registered through the on-premise SBC, all packet interactions between the client and the IPPBX need to be forwarded through the SBC; in this case, if RTP transparent transmission is performed, the two clients cannot normally perform RTP packet interactions; in the specific implementation, the judgment method is: make the above judgment according to whether the User-Agent in the client registration packet carries the identifier of the SBC;

[0056] Determine whether SBC routing is enabled for the channel; if so, it is determined that the channel does not meet the RTP transparent transmission capability, and the process ends; otherwise, continue to the next step; specifically, the configuration for enabling SBC routing of the channel exists in the relay, and the packet transmission of some relays depends on the SBC for forwarding; if the corresponding relay has this option enabled, RTP transparent transmission is ignored;

[0057] Determine whether the client is registered through FQDN (Fully Qualified Domain Name); if so, the address for RTP interaction of the terminal registered through FQDN needs to be obtained through ICE negotiation, so RTP transparent transmission cannot be performed, that is, it is determined that the corresponding channel does not meet the RTP transparent transmission capability.

[0058] Figure 4 In the RTP transparent transmission method based on IPPBX according to an embodiment of the present invention, it is a schematic flowchart for determining whether there is any process that requires audio activity in the channel. As Figure 4 , determining whether there is any process that requires audio activity in the channel includes the following steps:

[0059] Is there a call recording, that is, Monitor, in the channel? If so, it is determined that there is a process that requires audio activity, and the process ends; otherwise, continue to the next step;

[0060] Determine whether there is a hook related to audio stream processing, namely audiohooks, in the channel. If so, determine that there is a process that requires audio activity and end the process; otherwise, continue to the next step. Among them, the hooks related to the voice stream include, for example: the IPPBX receives the RTP stream sent by the client and performs other processing such as normal monitoring, whisper monitoring, forced insertion monitoring, and mixing recording before forwarding.

[0061] Determine whether framehook(voice) is not empty. If so, determine that there is a process that requires audio activity and end the process; otherwise, continue to the next step. Among them, framehook is a frame hook that does not distinguish between voice and video, such as the jitter buffer on the IPPBX; framehook(voice) not being empty means that the voice frame contains valid data and the system is processing the voice stream normally.

[0062] Figure 5 In the RTP transparent transmission method based on IPPBX according to an embodiment of the present invention, it is a schematic flowchart for determining or confirming the RTP bonding type of two channels. As Figure 5 , the process of confirming the RTP bonding type of two channels includes the following steps:

[0063] Obtain the RTP bonding types of audio and video of two channels. Among them, for audio, if RTP transparent transmission is enabled, the RTP transparent transmission is in the remote mode, in which RTP does not pass through the IPPBX and is directly transparently transmitted; otherwise, RTP is in the local mode and RTP is forwarded through the IPPBX. For video, if RTP transparent transmission is enabled, the RTP transparent transmission is in the remote mode, in which RTP does not pass through the IPPBX and is directly transparently transmitted; otherwise, RTP is in the local mode and RTP is forwarded through the IPPBX.

[0064] Determine whether one end, that is, one of the two channels, has video enabled. If so, change the RTP bonding type of the audio of both ends, that is, the master and called channels, to FORBID, and continue to the next step; otherwise, change the RTP bonding type of the audio of both ends to FORBID and continue to the next step.

[0065] Determine whether the audio bonding type of one of the two channels is FORBID. If so, return FORBID; otherwise, continue to determine whether the audio bonding type of one of the two channels is LOCAL, that is, the local mode? If so, return the local mode; otherwise, return the remote mode.

[0066] By obtaining the RTP bonding types of audio and video of two channels in the above process, it can be determined whether the corresponding extension has enabled the option to support RTP transparent transmission.

[0067] Figure 6 In the RTP transparent transmission method based on IPPBX according to an embodiment of the present invention, it is a schematic flowchart for determining whether there is an intersection in the encodings of two channels. As Figure 6 , the IPPBX determines whether there is an intersection in the encodings supported by the calling and called clients respectively through the following steps:

[0068] After receiving the INVITE request from the caller, the IPPBX saves the encoding carried in the SDP in the INVITE request, for example, saves it in the corresponding channel;

[0069] Call the called party, and after the called party answers, save the encoding carried in the SDP in all 200OK replies of the called party;

[0070] After the calling and called parties join the bridge and RTP transparent transmission is allowed, determine whether there is an intersection in the encoding carried in the SDP in the INVITE request and the encoding carried in the SDP in all 200OK replies of the called party; if so, allow RTP transparent transmission, and carry the first encoding in the intersection in the RE-INVETE request sent to the calling and called parties; otherwise, do not allow RTP transparent transmission.

[0071] The RTP transparent transmission method based on IPPBX in this embodiment of the present invention collects all encodings sent by the client through the IPPBX; the IPPBX retains the encryption key sent by the client; determines whether the network architectures of the calling and called parties support RTP transparent transmission after the two parties establish a call; performs intelligent negotiation according to all encodings supported by the client; and exchanges the encryption keys of SRTP of both parties' clients to realize intelligent negotiation of encodings between the calling and called parties' clients and update the keys for SRTP support.

[0072] Embodiment Three:

[0073] The present invention also provides an IPPBX, including a memory and a processor, where the memory stores at least one segment of program, and the at least one segment of program is executed by the processor to implement the RTP transparent transmission method embodiment as described in any one of the above.

[0074] The memory can be used to store the computer program and / or module. The processor realizes various functions of the computer unit by running or executing the computer program and / or module stored in the memory, and calling the data stored in the memory. The memory mainly includes a program storage area and a data storage area. Among them, the program storage area can store an operating system and applications required for at least one function.

[0075] Although the present invention has been specifically shown and described in connection with preferred embodiments, those skilled in the art should understand that various changes in form and detail may be made to the present invention without departing from the spirit and scope of the present invention as defined by the appended claims, and all such changes are within the scope of protection of the present invention.

Claims

1. An RTP transparent transmission method based on IPPBX, characterized in that, including: After the calling party calls the called party and the called party answers, the IPPBX determines whether there are two channels in the bridge; When there are two channels and both of these two channels meet the RTP passthrough capability, the IPPBX determines whether there is an active process that requires audio in these two channels; When there is no active process that requires audio in these two channels, the IPPBX obtains all the encodings supported by the calling and called clients, and when there is an intersection in the encodings supported by the calling and called clients respectively, at least one encoding in the intersection is used to perform intelligent negotiation between the calling and called clients for communication.

2. The RTP transparent transmission method according to claim 1, characterized in that, It also includes: The IPPBX saves the SRTP encryption keys sent by the calling and called clients during the call, and after triggering RTP passthrough, exchanges the SRTP encryption keys sent by the calling and called clients between the calling and called clients.

3. The RTP transparent transmission method according to claim 1, characterized in that It also includes: When there is an active process that requires audio in these two channels and the RTP bonding type of these two channels is the local type, the IPPBX determines whether the DMTF modes of these two channels are the same; if so, DMTF-HOOK is bound to these two channels respectively, and after binding DMTF-HOOK, the DMTF modes of these two channels are both set to INFO.

4. The RTP transparent transmission method according to claim 1, wherein Before performing RTP passthrough, it also includes: The IPPBX determines whether the PTIME parameter settings of these two channels are the same; if so, RTP passthrough is performed; otherwise, the process exits.

5. The RTP transparent transmission method according to claim 1, characterized in that The IPPBX determines whether there is an intersection in the encodings supported by the calling and called clients respectively through the following steps: After the IPPBX receives the INVITE request from the calling party, it saves the encoding carried in the SDP in the INVITE request; Calls the called party, and after the called party answers, saves the encoding carried in the SDP in all 200OK replies of the called party; When the calling and called parties join the bridge and RTP passthrough is allowed, it is determined whether there is an intersection in the encoding carried in the SDP in the INVITE request and the encoding carried in the SDP in all 200OK replies of the called party; if so, RTP passthrough is allowed, and the first encoding in the intersection is carried in the RE-INVETE request sent to the calling and called parties; Otherwise, RTP passthrough is not allowed.

6. The RTP transparent transmission method according to claim 1, wherein Determining whether a channel meets the passthrough capability includes the following steps: Judging whether the calling client or the called client is registered through a locally deployed session border controller; if so, it is determined that the channel corresponding to the calling client or the called client does not meet the passthrough capability; otherwise, continue to the next step; Judging whether the session border controller routing is enabled for the channel corresponding to the calling client or the called client; If so, it is determined that the channel corresponding to the calling client or the called client does not meet the passthrough capability; otherwise, continue to the next step; Judging whether the calling client or the called client is registered through FQDN; If so, it is determined that the channel corresponding to the calling client or the called client does not meet the passthrough capability.

7. An IPPBX, characterized in that, It includes a memory and a processor, and the memory stores at least one segment of program, and the at least one segment of program is executed by the processor to implement the RTP passthrough method as described in any one of claims 1 to 5.

Images