Patent Application
20100057860
This application relates to telecommunications and, more particularly, to transmission feedback.
Telecommunication refers to the transmission of information using technology such as radio, telephones, or computers. Some telecommunications protocols do not have feedback mechanisms built in. For example, most multicast communication techniques do not have built in feedback mechanisms.
Multicast is an example of a one-to-many communication technique in which a sender transmits a message for simultaneous delivery to multiple receivers. Not requiring feedback means that a multicast sender need not know specific details of each receiver or potential receiver. Instead, a multicast sender can simply send a message once and it will be transmitted to those receivers who have chosen to receive messages from the sender.
However, not requiring feedback can be disadvantageous in a number of contexts. For example, consider a police dispatcher who sends a message summoning all available patrol cars to a crime scene. If the dispatcher does not receive a reply from any patrol cars, and in the absence of any built in feedback mechanism, the dispatcher may have no way to determine whether the message was received, heard, and will be complied with, i.e., whether any patrol cars heard the message and will proceed to the crime scene.
The present invention may be better understood, and its numerous objects, features and advantages made apparent to those skilled in the art by referencing the accompanying drawings.
While the invention is susceptible to various modifications and alternative forms, specific embodiments of the invention are provided as examples in the drawings and detailed description. It should be understood that the drawings and detailed description are not intended to limit the invention to the particular form disclosed. Instead, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the invention as defined by the appended claims.
A computing device connected to a network detects whether a message that was transmitted using a one-to-many protocol was received by one or more receiver computing devices. An indication of whether the message was received is generated and presented via an interface included in or coupled to the computing device.
One or more computing devices 112(1)-112(3) (collectively referred to as computing devices 112, discussed in more detail with reference to
In the illustrated embodiment, confirmation and acknowledgement modules 120(1), 120(2), and 120(3) are shown as being included in computing devices 112(1), 112(2), and 112(3), respectively. It is to be understood that confirmation and acknowledgement modules 120 may be implemented separately from computing devices 112 in alternative embodiments. Each confirmation and acknowledgement module 120 determines what type of feedback is appropriate, if any, generates the feedback, and transmits the feedback onto network 102. This is typically done in response to receiving a message, for example, via network 102, but each confirmation and acknowledgement module 120 may also provide feedback when no message is received.
Computing devices 112(1), 112(2), and 112(3) communicate with computing device 130 via network 102. Computing device 130 is shown as sending a message 140 and receiving feedback 150 via network 102. Computing device 130 (discussed in more detail with reference to
Message 140 is typically sent using a one-to-many transmission protocol, such as multicast or broadcast. Message 140 can include audio, video, still images, and/or data. Feedback 150 includes information regarding the reception and disposition of a message, for example, message 140.
In one embodiment, an administrator of system 100 can configure system 100 to use real-time transport protocol (RTP) messages to request and transmit feedback, as described in more detail with respect to
When message 140 is received by a receiver, the receiver can send feedback in another message in response to the request. For example, if feedback 150 contains an RTP message, a tone or event can be embedded in the RTP message in feedback 150. The tone or event can be used to encode information. A message containing such a tone or event can be configured such that a user of a sending or receiving device is unaware of the presence of the tone or event. That is, the feedback request and return can be configured such that the tone or event is not noticeable to a user and the user's experience is unaffected.
An administrator can configure each receiver to handle feedback in a variety of ways. In some embodiments, a receiver provides feedback only when feedback is requested by a sender. In other embodiments, feedback need not be requested by a sender. Instead a receiving device, such as computing device 112, automatically provides feedback for messages the receiver receives. For example, a receiver can be configured to always transmit feedback when a message is received.
When there are many receivers, it may be desirable to configure feedback handling so that the number of feedback messages is less than the number of receivers. For example, a receiver can be configured to transmit feedback after a randomized interval of silence, or only if no other receivers transmit feedback. In order to determine whether other receivers are providing feedback for a message, a receiver can monitor other receivers in a system. This monitoring can be done by directly monitoring other receivers, or can be done by monitoring a communication channel (e.g., a LAN). For example, if all traffic for a given set of receivers goes through a particular network element (e.g., a particular gateway), a receiver can be configured to monitor that element to detect whether feedback has been provided for a given message. If a receiver detects that feedback has not been provided by any of the receivers of a given message, that receiver can then send feedback. If, on the other hand, feedback is already sent for a given message, the receiver can avoid sending feedback. Each receiver can be configured to wait a specified period of time to determine if other receivers are providing feedback. The problem of multiple receivers simultaneously responding to a message can be avoided by configuring receiver to wait different amount of time than the other receivers a message is sent to.
In another embodiment, one specific receiver is configured to transmit feedback, and the other receivers a message is sent to are configured to not transmit feedback. This avoids the need for a receiver to monitor other receivers to determine if feedback is being provided. Instead, a particular receiver is configured to provide feedback for a group of receivers and the other receivers are configured to not provide feedback. An example of this is when receivers in a group have different authority levels, such as in a company, a request may be sent to an entire group, but only a computing device used by the group leader is configured to provide feedback, as only the group leader's response is desired or allowed.
In another embodiment, a middlepoint, that is an entity in the network that is able to inspect and may optionally be required to retransmit (restream) communication packets (e.g., a router or a voice over IP conferencing bridge) generates and transmits feedback based on the feedback messages it observes from individual receivers. In order to do so, the middlepoint must monitor receivers to determine which of the receivers has received a message. This may be done by actively detecting when a feedback message is transmitted by a receiver. In alternative embodiments, the middlepoint may use feedback provided by receivers that is not contained in normal feedback messages to determine which receivers have received a message. In the case where the middlepoint monitors feedback, the middlepoint can intercept and aggregate feedback sent by receivers. This reduces network congestion and may facilitate providing feedback to a sender in a more useful format.
The previous embodiments disclose providing feedback using in-band methods, i.e. feedback is transmitted along the same communication channels as the message to which the feedback pertains. In alternative embodiments, feedback is sent using an out of band method. Examples of out-of-band methods which can be utilized to provide feedback include any of a variety of well-known instant messaging, file transfer, or email protocols. Examples of out-of-band mechanisms which can be utilized to provide feedback are real-time transfer control protocol RTCP reports, SIMPLE (session initiation protocol for instant messaging and presence leveraging extensions), Jabber, SFTP (secure shell file transfer protocol), or SMTP (simple mail transfer protocol), to name a few.
In one embodiment, feedback is provided using RTCP reports. RTCP receiver reports (RRs) ordinarily carry mainly usage statistics, and are used to insure quality of service in a network environment. According to one embodiment, a system administrator can configure the system such that RRs are modified to carry feedback information, as discussed with respect to
A request for feedback can specify how the feedback is to be transmitted, i.e., in-band or out-of-band. Feedback for a given message may be provided using an in-band mechanism, e.g., RTP messages, an out-of-band mechanism, e.g., RTCP reports, hypertext transfer protocol (HTTP) messages posted to a common server, or some combination of in-band and out-of-band mechanisms.
As discussed above, feedback, such as feedback 150, can be generated and transmitted in a number of ways. Feedback can also include a variety of information and types of information. Consider the case where a sender sends a message to potentially numerous receivers. The sender may wish to know whether the message was received by any receivers. An indication that no receivers got the message could indicate a problem with the sender's ability to send messages, or could indicate that no receivers are available to receive the message. The sender may also want to know which receivers received the message. Information about specific receivers can include information such as the receiver's name, title, location, level of authority within an organization, and the like. Tile sender may wish to know not only that a message reached a certain receiver, but whether the message was accessed by the receiver. For instance, in the case of an audio message, a sender may wish to know whether the message was played in part or in its entirety, or whether the message was partially or entirely unusable due, for example, to transmission problems. The sender may also wish for a response containing information concerning the receiver's evaluation of the message, such as whether the user agrees or disagrees with the content. For example, if the message is a request for the receiver to perform an action, the sender may desire an indication of whether the receiver will or will not perform the action. For example, if the message is a message dispatching an emergency response team to a particular location, feedback may be provided indicating that the emergency response team has received and heard the dispatch and that the team is en route or that the team is unable to comply with the request. In this example, computing device 112 may correspond to a computer in an emergency vehicle. Computing device 130 may correspond to a dispatch station. The types of feedback described herein are merely examples of information that may be transmitted, for example, using feedback 150.
Storage 230, which contains log information 235, can include one or more tapes, hard drives, compact discs (CDs) or digital video discs (DVDs), and the like, as well as one or more arrays of individual storage devices (e.g., an optical storage jukebox, a “Just a Bunch of Disks” (JBOD) array, or a Redundant Array of Independent Disks (RAID) system).
In this example, program instructions executable to implement sending module 210, feedback module 220, and log access module 240 are stored in memory 208. It is noted that the program instructions and/or data executable to implement sending module 210, feedback module 220, and log access module 240 can be stored on various computer readable storage media such as a memory (e.g., RAM (Random Access Memory)). In some embodiments, such software is stored on a computer readable storage medium such as a CD (Compact Disc), DVD (Digital Versatile Disc), hard disk, optical disk, tape device, floppy disk, and the like. In order be executed, the software is loaded into memory from another computer readable storage medium. The instructions and/or data can also be transferred to a computing device for storage in memory via a network such as the Internet or upon a carrier medium. In some embodiments, the instructions and/or data are conveyed using a carrier medium such as a network and/or a wireless link upon which signals such as electrical, electromagnetic, or digital signals.
Sending module 210 sends messages and requests feedback. Sending module 210 may also specify certain receivers to provide feedback. For example, a user may only wish to receive feedback from high-level users, or from a particular user within an organization. For example, a request for feedback, such as an RTP message embedded in outgoing media, can specify that only receivers who meet certain criteria should send feedback. When a receiver receives the request, the receiver determines whether the criteria are satisfied and feedback should be sent. For example, if the request for feedback specifies that only group managers, or the head of a certain department should reply, a receiver who does not fulfill that specification does not transmit feedback. Alternatively, the sender or some other network element can be configured to store the criteria specified in an outgoing message and to compare incoming feedback with the criteria. If incoming feedback does not meet the requirements, for example, the feedback is not from a group manager, the feedback is filtered out, meaning information regarding the feedback is not stored in storage 230 or presented to a user of computing device 130.
Feedback module 220 receives and processes feedback. Feedback module 220 then provides feedback information to interface 204 for presentation via display console 206 and storage in storage 230. Feedback information can be stored in a searchable database, allowing a user to search, for example, by keyword
Feedback module 220 may need to extract, translate, or format incoming feedback, depending on the feedback mechanism used. In the example where feedback is provided using tones or events embedded in an RTP message, for example, feedback module 220 extracts the events from the RTP message and converts the events to a format that can be stored in storage 230. Feedback module 220 can then transfer the converted feedback information to interface 204 so that the information is stored in storage 230 in a format that is readily accessible by a user of computing device 130.
In the case where computing device 130 receives feedback from more than one source, feedback module 220 can aggregate the feedback before the feedback is stored and presented to a user of computing device 130. Feedback module 220 can analyze the feedback and compile statistics concerning the feedback to make the feedback more useful to senders. For example, a sender may be interested to know how many total receivers received and accessed a message and how many of those were above a certain organizational authority level. Feedback module 220 can be configured to automatically generate such information, or other information which may be useful.
Display console 206 presents various types of information relating to feedback received or expected at computing device 130. Both audible and visual information can be presented. Notification may be visually displayed using various lights, LCDs (liquid crystal displays), LEDs (light emitting diodes), and the like. In one embodiment, various colors of LEDs and various shapes of an LED display have meaning. For example, a transmit indicator may change from a blinking red dot to a lightning bolt to indicate that feedback has been received indicating a message was received by at least one receiver. An LED display in the shape of an ear may turn green to indicate a message was accessed, may be orange to indicate partial access of a message, or may be red to indicate that a message was not accessed. Feedback information may also be presented using a pop-up window on a computer screen which displays feedback information. The pop-Lip contains (optionally) the name or ID of a receiver, and indicates not only that a message was received, but also indicates whether the message was accessed, and also whether the message was acknowledged. The various examples of audio and visual displays are examples of user interfaces
Additionally (or alternatively), a speaker (not shown, but which may be included in or coupled to display console 206) can play tones, beeps, recorded messages, and the like to present feedback information to a user. Different tones are used to indicate transmission, reception, and acknowledgement of a message. Display console 206 can also provide feedback information without having received a feedback response. For example, a warning icon can be used to notify a sender that no potential receivers are available to receive messages.
As noted, computing device 130 is connected to storage 230, which stores information about sent messages and received feedback. For each message sent, or each feedback message received, sending module 210 or feedback module 220 uses interface 204 to store log information 235 in storage 230. Log information 235 includes such information as the time the message was sent and received, source, destination, and the like. Such information is accessible by log access module 240. Example log information is shown below.
Log information may be aggregated or summarized, for example, as follows:
Log access module 240 is used to present information to a user of computing device 130 via display 206, for example. Log access module 240 organizes log information 235 into entries. Entries correspond to a message and can be displayed using color coding, or including flags to indicate various information about the message, for example, reception and acknowledgement of the message.
Log access module 240 and log information 235 can be used to determine when messages were sent and when feedback was received. For instance, a list of receivers of a given message and when each receiver received the message can be recorded in log information 235. Log information 235 can also include detailed information, such as whether a message was accessed by a receiver, the authority level of the receiver and the like. A user can access log information 235 via log access module and perform various searches. The user can also select what information the user wishes to view. For example, a user can use log access module 240 to request a list of all messages sent during a given time period for which feedback indicating assent was received from a group manager. Or, the user can request a list of all feedback received by a certain receiver.
Log information 235 can be used for forensic purposes. For example, if a user wishes to know which receivers received and acknowledged a given message, the user can access log information 235 via log access module 240. The user can specify the message or other criteria desired to return a list of entries which match those criteria. Log information 235 can also be used to troubleshoot a network. For example, log access module 240 can be used to analyze log information 235 to determine that messages sent on a particular communication channel are only received at certain times, and are dropped at other times. That information can be compared with information about a specific network to find out what the problem is.
While computing device 130 has been described as a sending device, computing device 130 can also be a receiver. For example, computing device 130 may send a message to a receiver, and await feedback for that message. The receiver may send a reply message and request feedback indicating that computing device 130 received the reply. In such a case, computing device 130 can be configured to provide feedback to the original receiver.
Confirmation and acknowledgement module 120 provides feedback generation and transmission functionality for computing device 112. Messages typically are received from a network such as network 102 of
Confirmation and acknowledgement module 120 communicates the content, or media, contained in a received message to interface 304. Interface 304 transfers the message content to storage 330, and also causes the message to be made available for playout, for example via speakers or a display screen (not shown) included with computing device 112. The messages sent to storage 330 can be organized and made accessible by a storage manager. Messages can be stored, for example, in a searchable database. A user of computing device 112 can search for messages, for example, by keyword, intended receiver, date, or priority. For example a user may wish to view all high-priority messages received in a certain period of time. Other messages may be viewed significantly later than the messages are received. The user can preferably query storage 330 (via a storage manager) to retrieve only those messages which match those criteria. The user can then select from among the retrieved messages which to play.
Confirmation and acknowledgement module 120 also communicates with interface module 304 to detect when messages are played. When a message is played or accessed, for example, when a video is watched using a display screen, interface 304 sends a notification to confirmation and acknowledgement module 120. Confirmation and acknowledgement module 120 then generates and transmits feedback indicating playout of the message.
A user of computing device 112 can acknowledge a received message either by affirming or denying the message. For example, the user may select and view a video message containing instructions. If the user does not intend to comply with the instructions, for example, if the user is unable or unwilling to follow the instructions, the user can indicate that the message is denied. Such indication can be provided by, for example, selecting “Deny” on a menu of options which is displayed at the end of the message. Indication of the user's acknowledgement is captured by interface 304 and transmitted to confirmation and acknowledgement module 120. Confirmation and acknowledgement module 120 then generates feedback containing the acknowledgment. Confirmation and acknowledgement module 120 may also transmit information such as the identity of computing device 112 or a user of computing device 112, the authority level of the user, or other such information. Such information may be stored in a system profile, or a user profile loaded when the user logs in to computing device 112. Confirmation and acknowledgement module 120 can extract that information and transmit it along with other feedback information.
Feedback indicating receipt, playout, and acknowledgment can be sent separately, as each event occurs, or can be sent all together. That is, confirmation and acknowledgement module 120 may hold feedback indicating receipt of a message until the message is played and/or acknowledged. Confirmation and acknowledgement module 120 may then send all feedback together in a single message. Each type of feedback can be sent using a different method. For example, feedback indicating receipt of a message can be sent using a customized RTP message and feedback indicating the same message was affirmed can be sent by encoding feedback information in one or more tones or events. Additionally, confirmation and acknowledgment module 120 may not provide feedback for each message received, but may send a single feedback message for a several received messages. This is generally applicable when several messages are received which are part of a single group or stream.
Computing device 112 also includes monitor module 122, which has the ability to monitor other receivers. Monitor module 122 can detect whether the other receivers send feedback. Monitor module 122 can also detect what authority level the receivers have. For example, a receiver could be required to register with an authority level and ID when the user logs into a computing device, such as computing device 112. Monitor module 122 could be connected to a network device assigned to monitor the network topology and could therefore know what receivers are signed in and available to receive messages, and the authority level of those receivers.
Another way monitor module 122 may detect feedback sent by other receivers is that monitor module 122 includes the capability to poll other receivers. Such polling allows monitor module 122 to detect whether a given receiver has responded with feedback to a given message.
Monitor module 122 can communicate with confirmation and acknowledgement module 120 to notify confirmation and acknowledgement module 120 which receivers, if any, have sent feedback. The behavior of confirmation and acknowledgement module 120 can be configured by an administrator such that confirmation and acknowledgement module 120 sends feedback only if no other receivers do or if no high-level receivers do, as determined by information generated by monitor module 122. A receiver monitoring other receivers can be configured by an administrator to send feedback if, after a certain period of time, feedback has not been sent by another receiver. The amount of time a receiver is configured to wait to detect if feedback is sent by other receivers depends on the characteristics of the network and computing devices 112, and is determined by an administrator. For example, computing devices 112 may be configured such that they must send feedback, if at all, within 200 milliseconds of receiving a message.
Monitor module 122 is excluded from some embodiments, for example if feedback is sent by all receivers, of if monitoring is performed by an intermediate network element, such as middlepoint 106 of
While computing device 112 is described as receiving a message and transmitting feedback, computing device 112 can also be configured to transmit a messages and process feedback for the message. For example, when computing device 112 receives a message, computing device 112 may be configured to send feedback for the received message. However, a user of computing device 112 may wish to send a message, either to the sender of the received message, or to another entity. In that case, computing device 112 can transmit a message. Computing device 112 can also request feedback for the message. Computing device 112 can also receive and process feedback from one or more receivers of the message computing device 112 sent.
Monitor module 410 monitors receivers. This can be accomplished in a variety of ways. In one embodiment, middlepoint 106 (shown in
In another embodiment, middlepoint 106 is connected to the same LAN as the sender and receiver, and thus has access to the same messages and feedback. When middlepoint 106 receives feedback, for example, from a computing device 112 of
Middlepoint 106, can use polling to monitor receivers For example, a receiver may periodically poll other receives to determine whether they have received or provided feedback for a given message. An alternative monitoring technique is the use of listening threads. For example, middlepoint 106 can establish a listening thread on a given communication channel. Thus the middlepoint detects messages and feedback transmitted on the given channel. Alternative methods of monitoring are contemplated.
Once a message is transmitted, the process of
When feedback indicating a message was received arrives at a feedback module, the feedback module processes the message. Processing received feedback can include verifying and removing headers, decrypting the received data, and error checking. The feedback module can also translate the received feedback, for example, by consulting a table or key indicating whether the message was received intact, with errors, and/or in a timely fashion. The processed feedback information can then be presented to a user via a display console. The processed feedback data may also be placed in storage.
If no feedback message is received, or if feedback is received indicating the message did not reach a receiver, the method of
If feedback is received indicating that a transmitted message was received by at least one receiver, the receipt is indicated to a user at operation 516, and the method of
If feedback is received indicating a message was played out, the method of
The stored information is added to a body of information (e.g., log information 235) which can be used to construct a log. The information is added by, for example, a storage manager (not shown) included with the data storage facility. It is understood that the storage manager need not wait until the end of the flow to store the information for each operation, but may store the log information for each operation as the operation occurs.
As an example of the method of
A computing device, particularly a confirmation and acknowledgement module included therewith, also detects, at operation 620, if a message was accessed, or played out. If a message is played out, the confirmation and acknowledgement module generates and transmits feedback indicating the playout at operation 625. If the message is not played out, the confirmation and acknowledgement module provides feedback indicating no message was played out at operation 655. The confirmation and acknowledgement module has the capability to determine, via a communications interface, if a message was partially played, if there were errors associated with the attempt to play the message, or if the message was not played at all. The confirmation and acknowledgement module generates and transmits feedback which is indicative of each of the above scenarios.
As noted, where there are multiple receivers of a message, the provision of feedback in the operations above may be contingent on the behavior of other receivers of the message. Feedback may be transmitted by a receiver using any of the in-band or out-of-band mechanisms previously discussed, or some combination of those mechanisms. For example, a receiver may send an RTP message indicating a message was received and then provide playout feedback in an RTCP report. The various types of feedback, i.e., reception, playout, and acknowledgement, may each be transmitted separately, utilize the same or different paths, e.g., RTP or RTCP. Alternatively, the types of feedback may be consolidated by a confirmation and acknowledgement module and sent in one or more combined messages utilizing the same or different paths.
At operation 720, the monitoring device monitors receivers to detect which receivers receive the message and provide feedback. This can be accomplished, for example, by polling receivers, or by listening to network channels receivers use to transmit feedback.
The monitoring device, at operation 730, controls transmission of feedback. This may be done by suppressing transmission of feedback by certain receivers or by capturing and filtering transmitted feedback. For example, in the embodiment where the monitoring device is a receiver, the monitoring device may elect to not send feedback if the monitoring device detects that feedback has already been transmitted for a given message. Alternatively, the monitoring device may transmit feedback to a sender of a message, and also transmit a signal to other receivers to not send feedback for the message. In another embodiment, feedback messages may have to traverse monitoring device, for example, if monitoring device acts as a network gateway. In that embodiment, the monitoring device may capture all feedback sent by receivers which corresponds to a given message. The monitoring device can than consolidate the feedback, for example, compiling statistics on the number, identity, and authority levels of receivers who transmitted feedback. The monitoring device can then send an aggregated feedback message to the sender.
A user may access the log information to determine the status of messages. Such information is useful in a variety of contexts, for example, as a forensic tool to determine which messages were received by which receivers, and when the messages were received, as a communications tool to determine whether messages need to be resent or have been heard, and as a network troubleshooting tool to identify areas of impaired network operation.
In one embodiment, the log information is presented to a user via a display console. The log information can be stored in a database and is preferably searchable, for example by keyword or by the date or time a message was sent or feedback was received. A user can enter information identifying one or more messages. The system will retrieve information concerning messages which match the entered information. For example, if a user enters “521”, information concerning message number 521 is retrieved. The information may include any and all information stored, such as when the message was sent, any receivers who received the message, whether the message was affirmed or denied, and the like.
In one embodiment, the display renders the he log information to users as entries. An entry can be configured by an administrator to include information concerning a message and all feedback received in response to the message. For example, an entry, such as entry 822 includes the address of the sender, the time a message was sent, the address the message was sent to, and the priority of the message. Entry 822 also includes information about the reception of the message, such as whether it was received by any receivers, whether it was accessed, and whether it was acknowledged. Entry 822 can also include the identity and authority level of one or more receivers of the message. The status of a message, i.e., received, accessed, acknowledged, may be displayed separately from an entry, for example, in a field such as 832, for quick reference. For example, for a message that was sent but not received, a field 832 can display an icon, for example, a red exclamation point. For a message which has been received and accessed, field 832 can change to display, for example, a green ear. An entry 822 can also be color coded to quickly indicate status to a user.
Although the present invention has been described in connection with several embodiments, the invention is not intended to be limited to the specific forms set forth herein. On the contrary, it is intended to cover such alternatives, modifications, and equivalents as can be reasonably included within the scope of the invention as defined by tile appended claims.
