Enhanced session initiation protocol recording

The systems and methods disclosed herein relate to call recording and in particular to call recording in a Session Initiation Protocol (SIP) environment.

Recording a call when the call enters an enterprise, such as a corporate network, has an advantage over other solutions. One advantage is that the media stream of a call can be forked at a Session Border Controller (SBC). The advantage of using a SBC is that all incoming/outgoing calls have to traverse the SBC. This provides enhanced security for recording a media stream. In a SIP environment, call recording is typically based on the Internet Engineering Task Force (IETF) RFC 6341, the entire contents of which are hereby incorporated herein by reference. In addition, (IETF) RFCs 6665 (July 2012) and 3903 (October 2004) disclose the use of standard SIP messaging, which are also incorporated herein in their entirety by reference. However, the solution proposed in the IETF RFC 6341 has problems when selective recording needed. When a media stream enters the enterprise at the SBC, the media stream is always streamed to a media recorder. This works fine when all calls are being recorded. However, if an individual call is not being recorded, the media is still streamed to the media recorder. This results in the sending of unnecessary media streams to the media recorder.

Systems and methods are provided to solve these and other problems and disadvantages of the prior art. To limit the sending of unrecorded media streams, when a first SIP INVITE is received by a Session Border Controller (SBC) to establish a communication session between communication devices, a second SIP INVITE message is also sent by the SBC to a media recorder without a media line or a media attribute set to inactive. The second SIP INVITE message without the media line or the media attribute set to inactive indicates that there is currently no media associated with the communication session to the media recorder. The SBC receives one of a SIP PUBLISH message or a SIP NOTIFY message that indicates whether to start or stop recording the voice or video communication session. The SBC sends or does not send a media stream of the communication session between the communication devices based on whether the SIP PUBLISH or the SIP NOTIFY indicates whether to start or stop recording the voice or video communication session.

In another embodiment, a media recording application sends a SIP SUBSCRIBE message to be notified of an event associated with a User Agent (UA). The media recording application receives a SIP NOTIFY message that indicates the detection of an event associated with the UA. In response, a media recorder receives a media stream for a communication session that includes the UA. The media recorder records the media stream of the communication session.

FIG. 1 is a block diagram of a first illustrative system for managing media recording at a Session Border Controller (SBC).

FIG. 2 is a block diagram of a second illustrative system for managing media recording with a Back-to-Back User Agent (B2BUA).

FIG. 3 is a flow diagram of a process for managing media recording at a SBC.

FIG. 4 is a flow diagram of a process for detecting Dual Tone Multi-Frequency (DTMF) to start or stop a call recording.

FIG. 5 is a flow diagram of a process for managing a media recording with a B2BUA.

FIG. 1 is a block diagram of a first illustrative system 100 for managing media recording at a Session Border Controller (SBC) 120 . The first illustrative system 100 comprises communication devices 101 A- 101 N, communication networks 110 A- 110 B, the SBC 120 , a media recorder 121 , a communication manager 130 , and agent terminals 140 A- 140 N. The first illustrative system 100 is for of an exemplary call center environment. However, the first illustrative system may be implemented a non-call center environment where the agent terminals 140 A- 140 N are communication devices 101 for users.

The communication devices 101 A- 101 N can be or may include any device that can communicate on the communication network 110 A, such as a Personal Computer (PC), a telephone, a video system, a cellular telephone, a Personal Digital Assistant (PDA), a tablet device, a notebook device, a smart phone, a media server, and/or the like. As shown in FIG. 1 , any number of communication devices 101 A- 101 N may be connected to the communication network 110 A, including only a single communication device 101 .

The communication device 101 A further comprises a User Agent (UA) 102 . The UA 102 can be or may include any hardware/software that can handle SIP messages for the communication device 101 A. Although the communication devices 101 B- 101 N are not shown comprising a UA 102 , each of the communication devices 101 B- 101 N can also include a respective UA 102 . In some embodiments, the UA 102 may process messages for other types of communication sessions, such as video protocols, H.323. Web Real-Time Communication (WebRTC) protocol and/or the like.

The communication networks 110 A- 110 B can be or may include any collection of communication equipment that can send and receive electronic communications, such as the Internet, a Wide Area Network (WAN), a Local Area Network (LAN), a Voice over IP Network (VoIP), the Public Switched Telephone Network (PSTN), a packet switched network, a circuit switched network, a cellular network, a combination of these, and the like. The communication networks 110 A- 110 B can use a variety of electronic protocols, such as Ethernet, Internet Protocol (IP), Session Initiation Protocol (SIP), Integrated Services Digital Network (ISDN), Real-Time Protocol (RTP), and/or the like. Thus, the communication networks 110 A- 110 B are electronic communication networks configured to carry messages via packets and/or circuit switched communications. In a typical environment, the communication network 110 A is a public network, such as the Internet and the communication network 110 B is a private network, such as a corporate or enterprise network.

The SBC 120 can be or may include any hardware/software that can provide security services for the communication network 110 B, such as a firewall, a gateway, a Network Address Translator (NAT), and/or the like. The SBC 120 has the ability to fork any number media streams for call recording.

The media recorder 121 can be any device that can record a media stream. The media recorder 121 can record a digital media stream and/or an analog media stream. The media recorder 121 can record a video media stream, an audio media stream, a text media stream (e.g., an Instant Messaging media stream), and/or the like. The media recorder 121 may record a portion of a media stream. The media recorder 121 may record any number of media streams. The media recorder 121 may run on a media recording server.

The media recorder 121 also includes a user agent 122 . The user agent 122 can be similar to the user agent 102 . The user agent 122 can process SIP messages for recording a media stream.

The communication manager 130 can be any hardware coupled with software that can manage communications, such as a Private Branch Exchange (PBX), a proxy server, a router, a call processor, a network switch, a central office switch, and/or the like. The communication manager 130 further comprises a communication processor 131 , a media recording application 132 , and an Interactive Voice Response (IVR) system 133 .

The communication processor 131 can be any processor that can process communications, such as, a microprocessor, a Digital Signaling Processor (DSP), a microcontroller, and/or the like. The communication processor 131 is typically coupled with firmware and/or software to process communications.

The media recording application 132 can be or may include any hardware/software that can manage how media sessions are recorded. The media recording application 132 may have a user interface that allows an administrator to determine specific media sessions to record. For example, the administrator can elect to record all media streams for a specific UA 102 , record all media streams for a specific user, record all media streams for a contact center, record a media based on an address, such as a telephone number, record a media stream based on a word or phrase spoken in the media stream, record a video stream based on a gesture in a video call, record an Instant Messaging stream based on a word or phrase sent in the IM stream, record a media stream based on a call transfer, record a media stream based on call forking, record a media stream based on a conference call, record a media stream based on a conference call with a specific user, record a media stream based on a type of media stream, record a media stream based on a group of agents in a contact center, record a media stream based on a specific agent, record a media stream based on a product supported by a group of agents in the contact center, record a media stream based on information selected by the user from the IVR system 133 , record a media stream based on an address range, record a media stream based on a Dual Tone Multi-Frequency (DTMF) tone, record a media stream based on a call to a specific number, and/or the like.

The IVR system 133 can be or may include any hardware/software that can interact with a person. The IVR system 133 can present different selections for a user to select. For example, the IVR system 133 may be a front end to a contact center, which enables a customer to select a specific service or product supported by the contact center. The IVR system 133 may be a means for a user to select recording of a media stream of a communication session. The IVR system 133 may also function as a video IVR system 133 that can take input from a user in a video call.

The agent terminals 140 A- 140 N can be any device that can be used in a communication session, such as a communication device 101 . The agent terminals 140 A- 140 N may comprise a plurality of communication devices 101 , such as a telephone and a personal computer that is used by an agent in a contact center. Although not shown, the agent terminals 140 A- 140 N can also include a user agent 102 .

FIG. 2 is a block diagram of a second illustrative system 200 for managing media recording with a Back-to-Back User Agent (B2BUA) 234 . The second illustrative system 200 comprises the communication devices 101 A- 101 N, the communication network 110 , the media recorder 121 , the communication manager 130 , and a SIP proxy server 250 .

In this embodiment, the media recorder 121 includes a media recording application 232 , the user agent 122 , and the IVR system 133 . The media recording application 232 is similar to the media recording application 132 . In this embodiment, the media recording application 232 may include additional features and/or different features from the media recording application 132 .

The communication manager 130 further comprises the communication processor 131 and a B2BUA 234 . The B2BUA 234 is an application that gets inserted into the signaling stream and/or media stream of a communication session. For example, the B2BUA 234 can be inserted into each media stream of each communication session (or a subset of the communication sessions) in order to facilitate recording of a media stream.

The SIP proxy server 250 may be or can include any hardware/software that can provide communication services for the communication devices 101 A- 101 N. The SIP proxy server 250 is shown in FIG. 2 as being separate from the communication manager 130 . However, in another embodiment, the SIP proxy server 250 is part of the communication manager 130 or vice versa.

FIG. 3 is a flow diagram of a process for managing media recording at a SBC 120 . Illustratively, the communication devices 101 A- 101 N, the user agent 102 , the SBC 120 , the media recorder 121 , the user agent 122 , the communication manager 130 , the communication processor 131 , the media recording application 132 , the IVR system 133 , the agent terminals 140 A- 140 N, the media recording application 232 , the B2BUA 234 , and the SIP proxy server 250 are stored-program-controlled entities, such as a computer or processor, which performs the method of FIGS. 3-5 and the processes described herein by executing program instructions stored in a non-transitory computer readable storage medium, such as a memory or disk. Although the methods described in FIGS. 3-5 are shown in a specific order, one of skill in the art would recognize that the steps in FIGS. 3-5 may be implemented in different orders and/or be implemented in a multi-threaded environment. Moreover, various steps may be omitted or added based on implementation. The process of FIG. 3 is based on the embodiment described in FIG. 1 .

The process starts in step 300 A when the user agent 102 in the communication device 101 A sends a SIP INVITE message with a media line to establish a communication session to an agent in a contact center. For example, when a user of the communication device 101 A makes a call to a 1-800 number of a call center. In one embodiment, the SIP INVITE message may be a direct communication session to an agent at an agent terminal 140 . A media line is where the SIP INVITE message includes media lines that describe the type of media that will be used in the communication session. This is typically conveyed by using the Session Description Protocol (SDP). For example, using SDP, the SDP lines can include information on a codec for the communication session, the type of media (e.g., voice, video, or text), the type of protocol that will be used to send the media (e.g., Real-Time Protocol (RTP), and the like.

The SIP INVITE message of step 300 A is received by the SBC 120 . The SBC 120 sends the SIP INVITE message with the media lines in step 300 B to the communication manager 130 in step 300 B. The communication manager 130 sends the SIP INVITE message with the media lines to the agent terminal 140 A in step 300 C. For example, the SIP INVITE message of step 300 C may be sent to the agent terminal 140 A from a call center queue when the agent becomes available. Alternatively, the SIP INVITE message of step 300 C may be sent directly to the agent terminal 140 A.

The agent terminal 140 A responds by sending a SIP 200 OK message to the communication manager 130 in step 302 A. For example, the SIP 200 OK message is sent when the agent answers the phone (agent terminal 140 A). The SIP 200 OK message is sent by the communication manager 130 to the SBC 120 in step 302 B. The SBC 120 sends the SIP 200 OK message to the UA 102 in the communication device 101 A in step 302 C. The UA 102 in the communication device 101 A responds by sending a SIP ACK message in step 304 A to the SBC 120 . The SBC 120 sends the SIP ACK message to the communication manager 130 in step 304 B. The communication manager 130 sends the SIP ACK message to the agent terminal 140 A in step 304 C. At this point, the media stream of steps 312 A- 312 B can be setup (e.g., using RTP) to stream media between the user agent 102 in the communication device 101 A and the agent terminal 140 A. For example, the media may be media for a video call between the communication device 101 A and the agent terminal 140 A.

In response to receiving the SIP INVITE message of step 300 A, the SBC 120 also sends a SIP INVITE message with no media lines (e.g., no SDP information) to the communication manager 130 in step 306 A. The SIP INVITE message of step 306 A may also include meta-data identifying the media stream (i.e., that is setup in step 312 ). Alternatively the SIP INVITE message of step 300 A may have a media line that indicates that the media is inactive. For example, the media line a=inactive may be sent to indicate that the media stream is inactive. The communication manager 130 sends the SIP INVITE message with no media lines or the inactive media line to the media recorder 121 in step 306 B. The media recorder 121 responds by sending a SIP 200 OK message to the communication manager 130 in step 308 A. The communication manager 130 sends the SIP 200 OK message to the SBC 120 in step 308 B. The SBC 120 responds in step 310 A by sending a SIP ACK message to the communication manager 130 . The communication manager 130 sends the SIP ACK message to the media recorder 121 in step 310 B. At this point a communication session has been established between the SBC 120 and the call recorder 121 without a media stream. The steps of 306 - 310 may occur after or intermixed with step 316 .

The media recording application 132 , in the communication manager 130 , sends a SIP PUBLISH message or a SIP NOTIFY message to the SBC 120 in step 314 . The process of sending a SIP PUBLISH message or a SIP NOTIFY message can vary based on implementation. In one embodiment, the media recording application 132 can send the SIP PUBLISH message to the SBC 120 based on an event. For example, an administrator of the media recording application 132 may setup an event to record any voice call from the user agent 102 in the communication device 101 A. In this example, the SIP PUBLISH message of step 314 is sent before the SIP INVITE message of step 300 A is sent. The SIP PUBLISH message indicates to the SBC 120 to start sending media as soon as the communication session between the SBC 120 and the media recorder 121 has been established (steps 306 , 308 , and 310 ).

Alternatively, the SIP PUBLISH message may be sent during the communication session as shown in FIG. 3 . For example, where the event is based on the detection of a word or phrase spoken during the communication session (e.g., if an agent is using profanity during a call with a customer). In this example, the SIP PUBLISH message indicates to start sending the media stream to the media recorder 121 for the communication session established in step 306 , 308 , and 310 .

In another embodiment, the SIP PUBLISH message may be a combination of the above two events. For example, the SIP PUBLISH message may indicate to record the media stream when the communication session begins. If the word or phrase is detected in the communication session, the recording is stored. Otherwise, if the word or phrase is not detected in the communication session, the recording is automatically deleted. This way, the whole communication session is recorded if the event occurs.

In one embodiment, the media recording application 132 may send a SIP PUBLISH message to an event state compositor (not shown). The event state compositor can then send a SIP NOTIFY message (based on a previous SIP SUBSCRIBE message sent by the SBC 120 ) to the media recording application 132 .

In another embodiment, the SBC 120 can send the SIP SUBSCRIBE message of step 313 to the media recording application 132 based on the SIP INVITE of step 300 A being received. Step 313 is not used if a SIP PUBLISH is sent in step 314 (indicated by the dashed lines). The media recorder 121 can then send the SIP NOTIFY message of step 314 . The SIP NOTIFY message can indicate whether to start or stop sending media to the media recorder 121 . For example, the SIP NOTIFY message can work for any of the events described previously.

Upon receipt of the SIP PUBLISH message or the SIP NOTIFY message in step 314 , the SBC 120 sends a SIP 200 OK to the media recording application 132 in step 316 . The media recording application 132 responds by sending a SIP ACK message to the SBC 120 in step 318 .

The SBC 120 sends a SIP INVITE message that identifies the media session of step 312 to the media recorder 121 via the communication manager 130 in steps 320 A- 320 B. The SIP INVITE of step 320 A can include the SDP information. The media recorder 121 responds by sending a SIP 200 OK message to the SBC 120 via the communication manager 130 in steps 322 A- 322 B. The SBC 120 responds by sending a SIP ACK message to the media recorder 121 via the communication manager 130 in steps 324 A- 324 B.

The SBC 120 sends the media stream in step 326 if the SIP PUBLISH message or the SIP NOTIFY message indicates to send the media stream. For example, the SIP PUBLISH message (e.g., sent after the media stream is started in step 312 A- 312 B) can indicate that media monitor=on for the UA 102 in the communication device 101 A. At this point, the SBC 120 will send the media stream to the media recorder 121 in step 316 . At a later point in the communication session, a second SIP PUBLISH message or SIP NOTIFY message may be received that indicates that the media monitor=off. The SBC 120 will then stop sending the media stream to the media recorder 121 .

The above process is described using voice and video calls. However, the above process will also work for text media streams, such as Instant Messaging media streams. For example, using the Message Session Relay Protocol (MSRP) described in Network Working Group RFC 4975, which is incorporated herein by reference, a separate media path for an IM session can be sent through the SBC 120 and recorded using the above process.

In one embodiment, the communication session in steps 306 , 308 , and 310 are optionally setup. For example, the SIP INVITE of step 306 may not be sent based on an administered configuration of where a call between the UA 102 and the agent terminal 140 A is not to be recorded. In another embodiment, steps 306 , 308 , and 310 are setup for each communication that traverses the SBC 120 .

FIG. 4 is a flow diagram of a process for detecting Dual Tone Multi-Frequency (DTMF) to start or stop a call recording. The process starts in step 400 when a call (a communication session) is established. For example, a thread or daemon can be started for each call.

The SBC 120 determines if a DTMF tone(s) has been detected in the media stream in step 402 . For example, once the call is established, the user may by able to enter a *7 to start recording a call and a *8 to stop recording the call. If a DTMF tone(s) has not been detected in step 402 , the process goes to step 410 . The process determines if the call has ended in step 410 . If the call has ended in step 410 , the process ends in step 412 . Otherwise, if the call has not ended in step 410 , the process goes back to step 402 .

If a DTMF tone(s) has been detected in step 402 , the SBC 120 determines in step 404 if the DTMF tone(s) are to start recording or stop recording a call. If the DTMF tone(s) are not to record or stop recording a call, the process determines if the call has ended in step 410 .

If the DTMF tone(s) are to stop recording a call in step 404 , SBC 120 sets a flag to stop recording in step 408 and the process goes to step 414 . Otherwise, if the DTMF tone(s) are to start recording in step 408 , the SBC 120 sets the flag to start recording in step 406 . The SBC gets the session ID of the communication session in step 414 (e.g., the session ID for communication session established in steps 300 - 304 ). The SBC 120 builds a SIP REINVITE message using the flag and session ID in step 416 . The SBC 120 sends the SIP REINVITE message to the media recorder 121 in step 418 . The process then goes back to step 402 . The SBC 120 then sends the media stream in step 326 if the flag is set to record or stops sending the media stream if the flag is set to stop recording.

FIG. 5 is a flow diagram of a process for managing a media recording with a B2BUA 234 . The flow diagram of FIG. 5 is based on the embodiment described in FIG. 2 . The process starts in step 500 when an administrator defines an event that will cause a media stream to be recorded. For example, the administrator may elect to record all media streams for a specific UA 102 , record a media stream for a specific user, record a media stream based on an address, such as a telephone number, record a media stream based on a word or phrase spoken in the media stream, record a video stream based on a gesture in a video call, record a media stream based on a word or phrase sent in an Instant Messaging (IM) session, record a media stream based on a call transfer, a media stream based on call forking, record a media stream based on a conference call, record a media stream based on a conference call with a specific user, record a media stream based on a type of media stream, record a media stream based on a group of agents in a contact center, record a media based on a specific agent, record a media stream based on a product supported by a group of agents in the contact center, record a media stream based on information selected by the user from the IVR system 133 , record a media stream based on an address range, record a media stream based on a Dual Tone Multi-Frequency (DTMF) tone, record a media stream based on a call to a specific number, and/or the like.

The media recording application 232 in the media recorder 121 sends a SIP SUBSCRIBE message to the B2BUA 234 via the SIP proxy server 250 in steps 502 A- 502 B. The SIP SUBSCRIBE message indicates the particular event(s) that cause the B2BUA 234 to stream a media stream to the media recorder 121 . For example, the SIP SUBSCRIBE may indicate that the B2BUA 234 is to send a media stream for recording a call to the media recorder 121 when a phrase is detected in the media stream of the call and stop recording the call when a second phrase is detected in the media stream of the call. The B2BUA 234 responds by sending a SIP NOTIFY message via the SIP proxy server 250 in steps 504 A- 504 B. The SIP NOTIFY message of step 504 A- 504 B can indicate that none of the events are currently occurring or indicate that one or more of the events are currently occurring.

The media recording application 232 sends a SIP PUBLISH message for media monitoring to the B2BUA 234 via the SIP proxy server 250 in steps 506 A- 506 B. The SIP PUBLISH message of steps 506 A- 506 B is to tell the B2BUA 234 to create a communication session between the B2BUA 234 and the media recorder 121 when the event(s) sent in the SIP SUBSCRIBE message of step 502 occurs.

The process described in steps 508 - 526 are based on a recording event of where the UA 102 in the communication device 101 A accepts a communication session. One of skill in the art would recognize that the flow of FIG. 5 may vary based on different events. For example, any of the events described above. The process of steps 508 - 526 assume that the B2BUA 234 has been sequenced into the communication session between the UA 102 in the communication device 101 A.

The UA 102 in the communication device 101 B sends a SIP INVITE message to the UA 102 in the communication device 101 A via the SIP proxy server 250 and the B2BUA 234 in steps 508 A- 508 C. The UA 102 in the communication device 101 A sends a SIP 200 OK to the UA 102 in the communication device 101 B, via the B2BUA 234 and the SIP proxy server 250 in steps 510 A- 510 C. The UA 102 in the communication device 101 B sends a SIP ACK message to the UA 102 in the communication device 101 A via the SIP proxy server 250 and the B2BUA 234 in steps 514 A- 514 C. A media stream is then established between the UA 102 in the communication device 101 A and the UA 102 in the communication device 101 B, via the B2BUA 234 in steps 516 A- 516 B (e.g., using Real-Time Protocol (RTP)).

The B2BUA 234 , in step 512 , detects that the UA 102 in the communication device 101 A has accepted the communication session (e.g., the user of the communication device 101 A answered the call) when the B2BUA 234 receives the SIP 200 OK message of step 510 A. Since the UA 102 in the communication device 101 A has accepted a communication session in step 512 (the event for which the media recording application 232 subscribed to in step 502 ), the B2BUA 234 sends a SIP NOTIFY message via the SIP proxy server 250 to the media recording application 232 indicating that the UA 102 in the communication device 101 A has accepted a communication session in steps 518 A- 518 B.

In addition, because of the SIP PUBLISH message received in step 506 B, the B2BUA 234 sends a SIP INVITE message with auto answer to the media recording application 232 via the SIP proxy server 250 in steps 520 A- 520 B. The media recording application 232 responds by sending a SIP 200 OK message to the B2BUA 234 via the SIP proxy server 250 in steps 522 A- 522 B. The B2BUA 234 responds by sending a SIP ACK to the media recording application 232 via the SIP proxy server 250 in steps 524 A- 524 B. Since the media recording application 232 has been administered to record all calls answered by the UA 102 in the communication device 101 A, the B2BUA 234 sends the media stream of the call to the call recorder 121 in step 526 . The media stream is then recorded by the call recorder 121 . If the SIP notify of step 518 was to stop recording, the media stream of step 516 would be discontinued.

In another embodiment, the media recording application 232 does not send the SIP PUBLISH message of steps 506 A- 506 B, resulting in steps 520 , 522 , and 522 not occurring. Instead, when the SIP NOTIFY message of step 518 B is received by the media recording application 232 , the media recording application 232 initiates a communication session to the B2BUA 234 (not shown, but is the opposite of step 520 , 522 , and 524 ). The media recording application 232 sends a SIP INVITE message (with auto answer) to the B2BUA 234 . The B2BUA 234 sends a SIP 200 OK message to the media recording application 232 . The media recording application 232 sends a SIP ACK message to the B2BUA 234 . The B2BUA 234 then sends the media stream as described in step 526 .

The process described in FIG. 5 can also be used with the process of FIG. 4 of where DTMF tones are used to start and stop recording a call. In addition, the process of FIG. 5 can be used to record the media stream of an IM session.

Of course, various changes and modifications to the illustrative embodiment described above will be apparent to those skilled in the art. These changes and modifications can be made without departing from the spirit and the scope of the system and method and without diminishing its attendant advantages. The following claims specify the scope of the invention. Those skilled in the art will appreciate that the features described above can be combined in various ways to form multiple variations of the invention. As a result, the invention is not limited to the specific embodiments described above, but only by the following claims and their equivalents.