Patent Publication Number: US-10320972-B2

Title: Enhanced session initiation protocol recording

Description:
TECHNICAL FIELD 
     The systems and methods disclosed herein relate to call recording and in particular to call recording in a Session Initiation Protocol (SIP) environment. 
     BACKGROUND 
     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. 
     SUMMARY 
     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. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         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. 
     
    
    
     DETAILED DESCRIPTION 
       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.