Systems and methods for providing one-way video calls

Systems and methods for enabling one-way video calling are disclosed. The system can enable user equipment (UE) with varying capabilities to communicate in an asymmetrical manner. A UE receiving an incoming two-way video call can request that the call be “downgraded” to a one-way video-in call, a one-way video-out call, or even an audio-only call. The system can include a multi-way video graphical user interface (GUI) to enable the user to choose between accepting an incoming two-way video call or requesting a different type of call (e.g., a one-way video call or an audio-only call). The system can also include a call initiation GUI to enable users to select between two-way video, one-way video, or audio-only for outbound calls. The system can also include a call modification GUI to enable users to modify the parameters for an incoming call prior to initiating the call.

BACKGROUND

Video calls are available on a number of networks and systems, including on some cellular networks. For business use, video calls can enable users to attend meetings virtually, see presentations, and talk “face-to-face” with colleagues. For personal use, video calls can enable distant family members to visit in a way that is not possible on voice-only calls. For a soldier on deployment, for example, this may be his or her only option to see family for months or years at a time.

One drawback to current video conferencing technologies, however, is that if one of the participants is unable to participate in a video call, an attempted video call is automatically “dropped” to an audio-only call. There may be situations, however, where it would be desirable to provide a one-way video call—i.e., a call where only the sender sends, and the recipient receives, video. The recipient may have a user equipment (UE), for example, that has a functioning screen, but a non-functioning (or non-existent) camera. The recipient may nonetheless wish to receive the video from the sender, yet send only audio in return.

DETAILED DESCRIPTION

Examples of the present disclosure can comprise systems and methods for sending and receiving one-way video calls. The system can enable a sender to initiate a one-way video call. The system can also enable a recipient to establish a one-way video call, rather than being forced to drop down to an audio-only call. The system can enable users to choose between a two-way video call, a one-way video call, or an audio-only call using an updated graphical user interface (GUI).

For clarity, the systems and methods provided herein are described in terms of session initiation protocol (SIP) messages. One of skill in the art will recognize, however, that the systems and methods described herein are equally applicable to other protocols such as, for example, hypertext transfer protocol (HTTP), message session relay protocol (MSRP), or other current or future messaging protocols. The system is also described below for use with current technology networks (e.g., 4G LTE networks, 5G networks, etc.). One of skill in the art will recognize, however, that similar solutions could be used for establishing one-way video calls on 5G, Internet of Things (IoT), machine-to-machine (M2M), and even future network technologies that have yet to be invented. Thus, the use of 2G, 3G, 4G LTE, and 5G in the examples below is simply a reflection of current technologies and is not meant to limit the application. Indeed, one of ordinary skill in the art will see that the system could also be used, with little or no modification, with online video conferencing and other technologies.

As mentioned above, video calls can enable users to have a “face-to-face” experience. This can be useful for both business and personal purposes. Video conferencing and video calls, for example, enable users to work remotely and to virtually attend meetings and seminars, among other things. Grandparents who live separately from their children and grandchildren, on the other hand, can use video calling features (e.g., Facetime®) to stay in touch in a way that audio-only calls cannot provide.

Standard SIP session based video calling, however, does not have a provision for one-way video calls. If a user attempts to place a call to a user that does not have video capabilities, for example, the recipient user equipment (UE) simply replies to the initial SIP request with a response to initiate an audio-only call. This may be because the recipient UE does not have a camera, for example, or does not have sufficient signal strength or signal quality for a video call, among other things. Indeed, using current technology, if a user accepts a video call, the only way to simulate a one-way video call is for the recipient to turn off their camera. This has the effect of providing a black screen to the sender, but this is not technically the same as a one-way video call. In other words, the two-way video channel for the call remains open, with the recipient camera merely sending a black “picture.” Thus, while only the recipient sees a video image of the sender, the bandwidth required for two-way video is still being utilized.

There are several scenarios where one-way video calling could be useful. If the recipient UE has a functioning screen, but does not have a camera, for example, the recipient UE would normally automatically establish an audio-only call in response to a request to initiate a video call. Yet, the recipient may wish to receive, and the sender may wish to send, one-way video. Indeed, a user who is virtually attending a meeting or a seminar, especially a large one, may wish to see the presentation of the sender, for example, yet a return video feed may be unnecessary or undesirable (e.g., the user is still in pajamas!). Establishing a seminar or meeting with tens or hundreds of participants with a one-way video feed out (from the presenter) and audio-only in (from the participants), could also significantly reduce the bandwidth requirements for the meeting.

FIG. 1depicts conventional call establishment between a user equipment (UE) of a sender102and the UE of a recipient104via a call applications server106. The UEs102,104can be any type of electronic device capable of various types of communications (e.g., audio, video, text messaging, etc.) including, but not limited to, cell phones, smart phones, tablet computers, and laptop computers. For ease of explanation, the message is shown going straight from the sender UE102to the call application server106to the recipient UE104. One of skill in the art will recognize that, in reality, connections can involve several additional network entities such as, for example, a home subscriber service (HSS) and/or a proxy call session control function (P-CSCF) server, which are discussed below in more detail with reference toFIG. 10.

At108, the sender UE102can send an “INVITE” to the recipient UE104, via the call application server106, to participate in a video call with the recipient UE104. The invite can include, for example, the phone number or IP address of the sender (from), the phone number or IP address of the recipient (to), the conversation ID, contribution ID, user agent (UA), call ID, etc. The INVITE can also include a header indicating the desire to establish a video call. As such, the INVITE can include an audio send and receive (“SENDRECV”) and a video send and receive (“SENDRECV”), indicating that the sender UE102wishes to establish a bidirectional audio channel and a bidirectional video channel. At110, the INVITE can be sent from the call application server106to the recipient UE104for acceptance.

At112, the recipient UE104sends a message indicating that it has received the INVITE and that the recipient UE104is ringing—e.g., a 180 RINGING SIP message. At114, the call application server106can relay the 180 RINGING to the sender UE102. At116, the sender UE102can acknowledge the 180 RINGING with a 200 OK. This is simply an acknowledgement that the sender UE102has received the 180 RINGING and is standing by. At118, the call application server106can relay the 200 OK to the recipient UE104.

At120, if the recipient UE104has video call capability, the recipient UE104can establish a new session and send another acknowledgement. In this case, the recipient UE104can send a 183 SESSION IN PROGRESS, establishing a session between the recipient UE104and the sender UE102. At122, the call application server106can relay the 183 SESSION IN PROGRESS to the recipient UE104.

At124, the sender UE102can acknowledge the 183 SESSION IN PROGRESS with another 200 OK. At126, the call application server106can relay the 200 OK to the recipient UE104. Finally, at128, the recipient UE can send a final 200 OK that includes its willingness and ability to establish the video call. Thus, the recipient UE104can send a 200 OK message that includes an audio “SENDRECV” and a video “SENDRECV.” This informs the sender UE102that the recipient UE104is establishing the session with audio and video in both directions—i.e., both UEs102,104are sending and receiving both audio and video. At130, the call application server106can relay the 200 OK to the sender UE102and the video call is established.

The only other alternative that is available using current technology is for the recipient UE104to establish a voice-only call. This may be necessary when, for example, the recipient UE104does not have a camera, has a low battery, or poor signal quality, among other things. This alternative configuration is shown in dashed lines inFIG. 1.

At132, instead of sending the final 200 OK (at step128), the recipient UE104essentially “renegotiates” the call. Thus, while the initial INVITE included a request for audio and video send and receive, at132, the recipient UE responds with a new INVITE to establish an audio-only call. The INVITE includes the requested audio SENDRECV, but for video, the recipient UE104sends INACTIVE. This indicates to the sender UE102that the recipient UE104is willing and able to establish a bidirectional audio channel, but unwilling or unable to establish a bidirectional video channel. And since currently the only two choices are to (1) establish a two-way video call or (2) establish an audio-only call—i.e., one-way audio and/or video are not available—the call automatically drops down to an audio-only call.

At134, the call application server106passes the message, with the new parameters, to the sender UE102. At136, the sender UE102replies with a 200 OK, but with the new configuration (audio—SENDRECV; video—INACTIVE). At138, the call application server106relays the 200 OK to the recipient UE104and the audio-only call is established.

In many cases, however, it may be desirable for the recipient UE104to establish one-way communications for audio and/or video. The recipient UE104way wish to receive audio or video, for example, but not send audio or video, or vice-versa. If the recipient UE104does not have a camera (or it is broken), for example, the recipient may nonetheless wish to receive video from the sender UE102. Using current technology, however, the recipient UE104would automatically establish an audio-only call, as shown in steps132-138ofFIG. 1.

To this end, as shown inFIG. 2, examples of the present disclosure can include a system200for providing one-way audio and/or one-way video communications between two UEs. The system200can enable one UE to send video, and the other UE to receive the video, without requiring two-way video communications. Using a similar method, the UEs can also connect with audio only going one-way. As before, the method is described in terms of a sender UE102, a recipient UE104, and a call application server106. Of course, in reality, other UEs and other network entities could also be included.

At202, the sender UE102can send an INVITE to the recipient104, via the call application server106, in an attempt to initiate a two-way video call with the recipient UE104. The invite can include, for example, the phone number or IP address of the sender (from), the phone number or IP address of the recipient (to), the conversation ID, contribution ID, user agent (UA), call ID, etc. The INVITE can also include a header indicating the desire to establish a video call. As shown, the INVITE can include a request for audio—SENDRECV and video—SENDRECV indicating that the sender UE102wishes to establish a bidirectional audio channel and a bidirectional video channel. At204, the INVITE can be sent from the call application server106to the recipient UE104for acceptance.

At206, the recipient UE104can send a message indicating that it has received the INVITE and that the recipient UE104is ringing—e.g., a 180 RINGING SIP message. At208, the call application server106can relay the 180 RINGING to the sender UE102. At210, the sender UE102can acknowledge the 180 RINGING with a 200 OK. This is simply an acknowledgement that the sender UE102has received the 180 RINGING and is standing by. At212, the call application server106can relay the 200 OK to the recipient UE104.

At214, the recipient UE104can establish a new communications session with the sender UE102. To acknowledge this, the recipient UE104can send a 183 SESSION IN PROGRESS, which establishes a session (e.g., a real-time transport protocol, or RTP, session) between the recipient UE104and the sender UE102. At216, the call application server106can relay the 183 SESSION IN PROGRESS to the recipient UE104. At218, the sender UE102can acknowledge the 183 SESSION IN PROGRESS with another 200 OK. This is simply an acknowledgment that the sender UE102has received the 183 SESSION IN PROGRESS. At220, the call application server106can relay the 200 OK to the recipient UE104.

In this case, although the sender UE102has requested a two-way video call, the recipient UE104is unable or unwilling to establish two-way video communications. As a result, at222, the recipient UE sends a 200 OK with modified parameters. The recipient UE104can send a 200 OK that establishes two-way audio—Audio—SENDRECV—but one-way video—Video—RECVONLY. Thus, in this example, the recipient UE104can send and receive audio, but only receive video. As mentioned above, this may be because the recipient UE104does not have a camera or simply because the recipient does not want to provide video (e.g., they are working from home). At224, the call application server106can relay the updated 200 OK to the sender UE102and the session is established with two-way audio and one-way video.

Of course, the session can be established with many combinations of parameters. In other words, each UE102,104can establish one-way or two-way audio and/or one-way or two-way video, as long as there is at least a one-way channel. If neither UE102,104wants to send video (e.g., each sends a Video—RECVONLY), for example, then the call can automatically be dropped to an audio-only call. If both UEs102,104send RECVONLY for both audio and video, then the call can fail. In other words, if neither UE102,104is sending data, then no call can take place. Thus, while many combinations are possible, some are not complementary as shown in Table 1:

As shown inFIG. 3, examples of the present disclosure can also comprise a system300for starting a two-way call after at least one part of the call (i.e., either audio or video) has initially been established one-way only. This may be useful, for example, to enable one caller to make a presentation and then later, enable the other to make a presentation. Or, a recipient can answer a call (video—RECVONLY) because they are getting dressed, for example, and then convert to a two-way video call once they are dressed. As discussed below, the UEs102,104may include a graphical user interface (GUI) to enable the user to choose how to set up the call and when to change the set up.

Switching back and forth between one-way and two-way calling may also be an automatic process. In other words, the call may have initially been set up with one-way video due to network or UE conditions that have since improved. Thus, the sender UE102or the call application server106may monitor network and/or UE conditions; and, when the conditions reach a threshold, automatically renegotiate the call. If the call was initially set up with one-way video because the battery on one of the UEs102,104was low, but the UE102,104with the low battery has now been plugged in to charge, for example, this may trigger the renegotiation. Similarly, changes in signal strength or signal quality may also trigger a renegotiation.

In this example, the UEs102,104have initially established a two-way audio call and a one-way video call with the video going from the sender UE102to the recipient UE104. During the call, however, the recipient would like to convert to a two-way video call. To this end, at302, the recipient UE104can send a new INVITE to the sender UE102to essentially “renegotiate” the session. Thus, the new INVITE can contain headers to set (audio—SENDRECV) and (video—SENDRECV)—i.e., as opposed to RECVONLY. At304, the call application server can relay the INVITE to the sender UE102.

Assuming that the sender UE102is willing and able to convert to two-way video, at306, the sender UE102can send a 200 OK including headers that acknowledge the new parameters—i.e., (audio=SENDRECV) and (video=SENDRECV). At308, the call application server106can relay the 200 OK to the recipient UE104. At310, an RTP session can be established between the UEs102,104to enable two-way audio and two-way video to begin. In this example, the call has moved “up” from a one-way video call to a two-way video call.

Of course, in some situations, it may be necessary to move “down” from a two-way video call to a one-way video call or even an audio-only call. To this end, as shown inFIG. 4, examples of the present disclosure can also comprise a system400for moving from a two-way video call to a one-way video call. This may be because one user has finished their presentation, for example, or due to changing UE or network conditions, among other things.

In this example, a two-way video call has already been established, but the sender UE102now needs to renegotiate the call to a one-way video call with video going from the recipient UE104to the sender UE102only. At402, therefore, the sender UE102can send a new INVITE (within the same session) to renegotiation the parameters (audio—SENDRECV) and (video—RECVONLY). Thus, the sender UE102is attempting to establish a call on which there is a two-way audio channel, but only a one-way video channel (to the sender UE102).

At404, the call application server106can relay the INVITE to the recipient UE104. As mentioned above, in some applications, the decision to switch the call up or down may be made automatically based on UE and/or network conditions. In other examples, the user may choose to move the call up or down via a GUI provided during calls, as discussed below in more detail with reference toFIGS. 6-8.

Regardless, at406if the recipient UE104accepts the new INVITE, the recipient UE104can response with a 200 OK acknowledging the new parameters (audio—SENDRECV) and (video—SENDONLY). At408, the call application server106can relay the 200 OK to the sender UE102. At this point, the call has been renegotiated to have two-way audio, but one-way video (from the recipient UE104to the sender UE102).

As shown inFIG. 5, examples of the present disclosure can comprise a system500of dropping from a two-way video call to an audio-only call. After establishing a two-way video call, for example, one of the UEs102,104may request to drop to an audio-only call. This may be because the signal strength or signal quality at one or both of the UEs102,104has fallen below a threshold, for example, or because the battery on one or both of the UEs102,104is low. This may also simply be by the user's choice—e.g., they no longer wish to send or receive video.

In this example, after establishing a two-way video call, the recipient UE104(or the user) wants to renegotiate from the two-way video call to an audio-only call. At502, the recipient UE104can send a new INVITE including the new parameters (audio—SENDRECV) and (video—INACTIVE). This maintains the two-way audio channel, but cancels the video channel altogether. AT504, the call application server106can relay the INVITE to the sender UE102.

At506, the sender UE102can send a 200 OK acknowledging the new parameters. At508, the call application server106can relay the 200 OK to the recipient UE104and the call is transitioned to an audio-only call. As before, this may be in response to changing conditions or simply because the users no longer need the video connection.

As shown inFIG. 6, examples of the present disclosure can also comprise a multi-way video GUI600to provide users with multiple options when receiving a video call. Thus, rather than just providing accept or decline for video calls, the multi-way video GUI600can provide additional options for two-way, one-way, and audio only calls. These new features can be provided on a touchscreen or keyboard of the UEs102,104, for example, with each button corresponding to a different combination of features.

As shown inFIG. 6, the multi-way video GUI600can include multiple buttons or other input elements to enable users to place and receive two-way video calls, one-way video calls, and audio-only calls, among other things. In this example, the recipient UE104is receiving a video call from Caller 1 and is presented with multiple options on the multi-way video GUI600. In some examples, the multi-way video GUI600can include a two-way video call button602to enable the user to establish a conventional two-way video call—i.e., a bidirectional video channel and a bidirectional audio channel are both established.

In this case, however, the user is also provided with additional options. To this end, the multi-way video GUI600can also include a video-in button604. With the video-in button604, the recipient UE104can establish a call that establishes a bidirectional audio channel, but a video channel that only receives video. As discussed above, if the recipient UE104received an INVITE for a two-way video call (audio—SENDRECV, video—SENDRECV), but the user selects the video-in button604, the recipient UE104can respond to the call with a 200 OK with updated parameters (audio—SENDRECV, video—RECVONLY). Assuming that the sender UE102accepts the modified call, the multi-way video GUI600has enabled the user to establish a one-way video (in) call. This may be useful when the user is attending a seminar, for example, and wants to receive, but not send, video.

Similarly, the multi-way video GUI600can also include a video-out button606. As the name implies, the video-out button606can enable the user to establish a two-way audio call, but a one-way video call with the video going from the recipient UE104to the sender UE102. Thus, if the recipient UE104received an INVITE for a video call (audio—SENDRECV, video—SENDRECV), but the user selects the video-out button606, the recipient UE104can respond to the call with a 200 OK with updated parameters (audio—SENDRECV, video SENDONLY). This may be useful when the user is making a presentation to a large group, for example, and does not need video in from the group.

The multi-way video GUI600can also include an audio-only button608. This can enable the user to establish an audio-only call despite the fact that the recipient UE104has requested a video call. Thus, if the recipient UE104received an INVITE for a video call (audio—SENDRECV, video—SENDRECV), but the user selects the audio-only button608, the recipient UE104can respond to the call with a 200 OK with updated parameters (audio—SENDRECV, video—INACTIVE). Assuming the recipient UE104accepts the new parameters, an audio-only call can be established. This may be useful if the battery is low on the recipient UE104, for example, or the recipient UE104has poor signal strength, among other things.

Finally, the multi-way video GUI600can include a voicemail button610. When selected, the voicemail button610can essentially decline the video call and send Caller 1 directly to voicemail. If the recipient UE104has video voicemail, then Caller 1 can be sent to video voicemail to leave a video and audio message for the user. In many cases, the recipient UE104may only have audio voicemail, however; thus, the recipient UE104can first renegotiate the call and then send Caller 1 to voicemail. In this case, the recipient UE104essentially sends the same response that is used to establish an audio-only call—200 OK (audio—SENDRECV; video INACTIVE)—and then sends the sender UE102to voicemail. This can enable Caller 1 to leave an audio-only voicemail message for the user.

As shown inFIG. 7, examples of the present disclosure can also comprise a call modification GUI700to enable the sender to renegotiate or decline the call when an initial INVITE is modified by the recipient. In other words, if the sender initially attempts to establish a video call with the recipient, but the recipient downgrades the call in some way, the sender can be provided with the call modification GUI700with one or more choices in response. If the recipient is unavailable for a video call and attempts to downgrade to an audio-only call, for example, the recipient may decline the call altogether—e.g., because video is essential to the call for some reason. This may be because the sender wants visual approval of something (e.g., a paint color) or simply because the sender wants to have a “face-to-face” discussion.

In this example, the sender UE102is attempting to place a video call to the recipient UE104, but the recipient UE104has responded with a one-way video call. Thus, the sender UE102sent an INVITE (audio—SENDRECV; video—SENDRECV) to the recipient UE104, but the recipient UE104responded with a one-way video call 200 OK (audio—SENDRECV, video—RECVONLY).

In response to the change in parameters, therefore, the call modification GUI700can provide a notification702to the sender detailing the new parameters. In this example, the notification702can inform the sender that the recipient wishes to establish a one-way video call with video going from the sender to the recipient only—“Caller 2 would like to establish a video-in only call.” Of course, the notification702can be different based on how the recipient UE104replies and the desired language. If the recipient UE104reply requests an audio-only call, for example, then the notification702can read, “Caller 2 would like to establish an audio-only call.”

In this example, since the recipient UE104has requested a one-way video call, the sender has at least three choices—accept the one-way video call, drop to an audio-only call, or decline the call altogether. To this end, the one-way video button704can enable the recipient UE104top accept the call with the new, requested parameters. In this case, selecting the one-way video button704can cause the sender UE102to send a 200 OK with the new parameters (audio—SENDRECV; video—SENDONLY) to establish the one-way video call.

If the sender wishes to drop to an audio-only call, on the other hand, then the sender can select the audio-only button706. The selection of the audio-only button706can cause the sender UE102to attempt to renegotiate the call with yet another set of parameters (audio—SENDRECV; video—INACTIVE). On the recipient UE104, this may cause the multi-way video GUI600to display the audio-only button608to prompt the recipient to assent to the second, new set of parameters (i.e., by pressing the audio-only button608). This may be useful when the sender feels that two-way video is preferred, and that one-way video will not be any more useful than an audio-only call. This may also be useful to enable the users to quickly touch base to set up a later time for a video call (e.g., when only a video call will suffice).

In some examples, the call modification GUI700can also include a decline button708. This may be selected because the sender believes that a two-way video call is the only acceptable method of communications, for example, or that that sender will simply try again later. Thus, in response to the modified parameters (audio—SENDRECV; video RECVONLY), for example, when the decline button708is selected, the sender UE102can send an appropriate message to the recipient UE104(e.g., 403 FORBIDDEN) to terminate the call.

As shown inFIG. 8, examples of the present disclosure can also comprise a call initiation GUI800. As the name implies, the call initiation GUI800can provide the user with the ability to place multiple types of calls. Thus, the call initiation GUI800can be similar to the multi-way video GUI600, but on an outgoing basis. The call initiation GUI can have some of the same functions as the multi-way video GUI600, but with some services removed and some added, as appropriate. As can be understood, for example, in some cases the call initiation GUI800may include the voicemail button610as an optional element.

In some examples, to facilitate placing calls, the call initiation GUI800can include a facility to enable the sender to dial or to select the appropriate contact. Thus, the call initiation GUI800can include a standard number pad802and dialer window804to display the selected number or contact. In some examples, the call initiation GUI800can also include a contacts button806to enable the user to select an existing contact to call.

Like the multi-way video GUI600, the call initiation GUI800can also include various combinations of video and audio directionality. Unlike the multi-way video GUI600, however, the call initiation GUI800includes buttons for placing calls, rather than accepting calls. Thus, rather than having a single send button, for example, the call initiation GUI800can include multiple send buttons to establish different types of calls.

In some examples, the call initiation GUI800can include a two-way video send button808. After selecting a contact or dialing a number, the selection of the two-way video send button808will cause the sender UE102to send an INVITE to the recipient UE104with the parameters for a video call (audio—SENDRECV; video—SENDRECV). If the recipient UE104accepts the video call—i.e., sends a 200 OK (audio—SENDRECV; video—SENDRECV)—then a two-way video call is established with bidirectional video and bidirectional audio channels.

Similarly, selecting the one-way video out send button810causes the sender UE102to try to establish a call with two-way audio, but one-way video (from the sender UE102to the recipient UE104). Thus, selecting the one-way video out send button810causes the sender UE102to send an INVITE (audio—SENDRECV; video—SENDONLY). The one-way video call is then established if the recipient UE104responds with the expected 200 OK (audio—SENDRECV; video—RECVONLY).

Selecting the one-way video in send button812, on the other hand, causes the sender UE102to try to establish a call with two-way audio, but one-way video (from the recipient UE104to the sender UE102). Thus, selecting the one-way video in send button812causes the sender UE102to send an INVITE (audio—SENDRECV; video—RECVONLY). The one-way video call is then established if the recipient UE104responds with the expected 200 OK (audio—SENDRECV; video—SENDONLY). This may be useful if the sender is connecting to a seminar or a video conference in which the sender is not the presenter, for example.

Finally, the call initiation GUI800can also include an audio-only send button814. The audio-only send button814can function similarly to a standard send button. Thus, the audio-only send button814can enable the sender to establish a standard audio-only phone call. Selection of the audio-only send button814, therefore, can cause the sender UE102to send an audio-only INVITE (audio—SENDRECV; video—INACTIVE). Thus, an appropriate 200 OK (audio—SENDRECV; video—INACTIVE) can establish a conventional voice call.

Of course, some users may find other combinations and permutations useful. A user who wishes to connect silently to a video seminar, for example, may wish to connect with one-way video and one-way audio. Thus, using similar logic, the sender UE102can send an INVITE to the presenter with the appropriate parameters (audio RECVONLY; video—RECVONLY). The recipient UE104can then send the appropriate 200 OK (audio—SENDONLY; video—SENDONLY) to establish the call. This may be useful for the sender to attend a video conference, for example, without other attendees hearing a dog barking or a baby crying in the background.

Indeed, in the case of a seminar, the recipient (e.g., the presenter) may already have the recipient UE104configured to automatically send a response with these parameters regardless of what the INVITE from the sender UE102contains. In other words, even if the sender UE102attempts to establish a two-way video call, the response from the recipient UE104can automatically include the appropriate parameters—in this example, (audio—SENDONLY; video—SENDONLY). This can eliminate the need for participants to mute their microphones during the call, which is a common problem during conference calls and video conferences.

Thus, while several combinations and permutations have been discussed above, other combinations and permutations are available. The users can choose many combinations of one-way (in either direction) or two-way video and one-way (in either direction) or two-way audio to suit a variety of needs. A similar GUI could also be used to change call types during a call—i.e., essentially the counterpart to the call modification GUI700. The GUIs600,700,800, therefore, can be used both to establish new types of calls and to renegotiate calls in real-time as requested by the users. Users can establish one-way and two-way video and one-way and two-way audio for use in various applications. As used herein, “real time” simply denotes that the calls are carried out (negotiated, renegotiated, connected, etc.) in as little time as is practical given the inherent involvement of humans, electronics, networks, etc. One of skill in the art will recognize that, due to user, UE, and network delays, among other things, these processes are not “instantaneous.”

FIG. 9is an example of a method900for handling the above-mentioned calling options. The method900enables UE (e.g., the sender UE102) to attempt to establish a two-way video call and then take appropriate actions based on the response from the recipient (e.g., the recipient UE104). The method900could be implemented as an application on the UEs102,104, for example, or could be implemented on an application server (e.g., the call application server106or another network entity), a cloud server, or other entity.

At902, the sender UE102can send an INVITE to the recipient UE104requesting a two-way video call. As mentioned above, the INVITE can include the appropriate parameters (audio—SENDRECV; video SENDRECV) to request a two-way video call.

At904, the sender UE102can determine whether the parameters in the response (e.g., a 200 OK) received from the recipient UE104are associated with a two-way video call. The response from the recipient UE104may be based on many factors including current network conditions (e.g., signal strength and signal quality), current UE conditions (e.g., battery life, processor availability, camera status, etc.). The response from the recipient UE104can also be based on user preference based on the recipient's input on the multi-way video GUI600.

Either way, if the response includes the correct parameters for a video call (audio—SENDRECV; video SENDRECV), then at906the sender UE102can send any final signaling (e.g., an additional 200 OK) and the sender UE102and the recipient UE104can establish a two-way video call. The two-way video call can include a bidirectional video channel and a bidirectional audio channel.

If, on the other hand, the response does not include the correct parameters for a two-way video call, then at908the sender UE102can determine if the response is associated with a one-way video-in call (audio—SENDRECV; video SENDONLY), indicating the recipient UE104wants to send video to the sender UE102, but does not want to receive video from the sender UE102. As mentioned above, this may be useful when the sender is dialing in to a video conference or seminar at which they are not presenting.

If the sender UE102determines the response is associated with a one-way video-in call, the at910the sender UE102can send a 200 OK with the complementary parameters—in this case, Audio—SENDRECV; video RECVONLY. This establishes a bidirectional audio channel and a one-way video channel from the recipient UE104to the sender UE102.

If the sender UE102determines the response is not associated with a one-way video-in call, then at912, the sender UE102can determine if the response from the recipient UE104is associated with a one-way video-out call (audio—SENDRECV; video RECVONLY). This may be useful when the sender is a presenter on a call, for example, or simply when the recipient is not dressed, or otherwise indisposed, and does not want to provide video.

If the sender UE102determines the response is associated with a one-way video-out call, then at914the sender UE102can send a 200 OK with the complementary parameters—in this case, Audio—SENDRECV; video SENDONLY. This established a bidirectional audio channel and a one-way video channel from the sender UE102to the recipient UE104.

If the sender UE102determines the response is not associated with a one-way video-out call, then at916, the sender UE102can determine if the response from the recipient UE104is associated with an audio-only call (audio—SENDRECV; video INACTIVE). This may be useful when the recipient UE104does not have a functioning camera, for example, based on user preferences, or due to network or other conditions that prevent the use of video.

If the sender UE102determines the response is associated with an audio-only call, then at918the sender UE102can send a 200 OK with the complementary parameters—in this case, Audio—SENDRECV; video INACTIVE. This established a bidirectional audio channel, but no video channel.

At920, if none of the expected 200 OK responses is received, the method900can determine if an error code has been received (e.g., a 4XX, 5XX, or 6XX error code) or if no response is received at all. If, for example, the sender UE102receives a 403 FORBIDDEN, then, at922the sender UE102may simply disconnect from the call and display an error message. If, on the other hand, the sender UE102receives a 504 SERVER TIMEOUT, then at922the sender UE102may retry the call again after a predetermined amount of time.

Any of these responses could be due to user preference, as indicated by an input by the recipient on the recipient UE104(e.g., selecting a button on the multi-way video GUI600). These responses could also be caused by the network “downgrading” calls due to unfavorable conditions. A network entity (e.g., the call application server106) could include an algorithm that downgrades calls in a stepwise manner based on current network traffic, available bandwidth, maintenance issues, etc.

FIG. 10includes the internet protocol multimedia subsystem (IMS)1000for the 4G LTE1010and 5G1036networks. As shown, the IMS1000includes several network components for routing signals, storing subscriber information, and connecting across various subsystems and network types. The IMS1000is built on SIP as is the base to further support packaging of voice, video, data, fixed, and mobile services on a single platform to end users. It enables communications across multiple types of networks, including cellular, satellite, broadband, cable, and fixed networks, and enables the creation of efficient interoperating networks. The IMS1000can also enable the new SIP commands for providing one-way video calling discussed above with respect toFIGS. 2-9.

The IMS1000also provides interoperability for UEs1002,1004(e.g., the sender UE102and the recipient UE104) and other devices across multiple platforms including, for example, 2G1006, 3G1008, 4G1010, 5G1036, and IP1012networks. The IMS1000also includes a variety of network entities for providing a variety of services, including the one-way video calling services discussed herein. In some examples, the IMS1000can include, for example, a home location register/home subscriber service (HLR/HSS)1014, service architecture evolution gateway (SAE GW)1016, and a policy and charging rules function (PCRF)1018.

The HLR/HSS1014is a central database that contains user-related and subscription-related information. The functions of the HLR/HSS1014include functionalities such as mobility management, call and session establishment support, user authentication and access authorization. The HSS, which is used for LTE connections, is based on the previous HLR and authentication center (AuC) from CGMA and GSM technologies, with each serving substantially the same functions for their respective networks.

To this end, the HLR/HSS1014can also serve to provide routing instructions (e.g., IP addresses or phone numbers for the various call types), and provide any billing associated with video calls, for example. So, for example, the sender UE102can send the messages to the call application server106, which can then provide information to the HLR/HSS1014with the necessary credentials to enable the sender UE102to access the IMS1000. Once authenticated, the HLR/HSS1014can then ensure the user is authorized to make video calls, for example, or send an authorization request to a third-generation partnership project authentication, authorization, and accounting (3GPP AAA) server, among other things.

The SAE GW1016routes and forwards user data packets, while also acting as the mobility anchor for the user plane during inter-eNodeB handovers and as the anchor for mobility between 4G LTE1010, 5G1036, and other 3GPP technologies including, for example, terminating the S4 interface and relaying the traffic between 2G1006/3G1008systems and the packet data network gateway (PGW). For idle state UEs, the SAE GW1016terminates the downlink data path and triggers paging when downlink data arrives for the UEs1002,1004. It manages and stores UE1002,1004contexts such as, for example, parameters of the IP bearer service and network internal routing information.

The PCRF1018is a software node that determines policy rules in the overall cellular network, and the IMS1000specifically. The PCRF1018generally operates at the network core and accesses subscriber databases (e.g., the HLR/HSS1014) and other specialized functions, such as content handling (e.g., whether the user has sufficient data left in their plan to receive a video call), in a centralized manner. The PCRF1018is the main part of the IMS1000that aggregates information to and from the IMS1000and other sources. The PCRF1018can support the creation of rules and then can automatically make policy decisions for each subscriber active on the IMS1000. The PCRF1018can also be integrated with different platforms like rating, charging, and subscriber databases or can also be deployed as a standalone entity.

The IMS1000also includes the P-CSCF1020. The P-CSCF1020is the entry point to the IMS1000and serves as the outbound proxy server for the UEs1002,1004. The UEs1002,1004attach to the P-CSCF1020prior to performing IMS registrations and initiating SIP sessions. The P-CSCF1020may be in the home domain of the IMS operator, or it may be in the visiting domain, where one or more of the UEs1002,1004are currently roaming. For attachment to a given P-CSCF1020, the UEs1002,1004perform P-CSCF1020discovery procedures. Attachment to the P-CSCF1020enables the UEs1002,1004to initiate registrations and sessions with the IMS1000.

The IMS1000also includes an interrogating-call session control function (I-CSCF)1022. The I-CSCF1022acts as an inbound SIP proxy server in the IMS1000. During IMS registrations, the I-CSCF1022queries the HLR/HSS1014to select the appropriate serving-call session control function (S-CSCF1024), discussed below, which can serve the UEs1002,1004. During IMS sessions, the I-CSCF1022acts as the entry point to terminating session requests. The I-CSCF1022routes the incoming session requests to the S-CSCF1024of the called party.

The S-CSCF1024acts as a registrar server, and in some cases, as a redirect server. The S-CSCF1024facilitates the routing path for mobile-originated or mobile-terminated session requests. The S-CSCF1024also interacts with various components for playing tones and announcements, among other things. For the systems200,300,400,500, discussed above, the S-CSCF1024can receive messages from the UEs1002,1004or the HLR/HSS1014, for example, and establish the appropriate sessions with the call application server106or other telephony applications servers (TASs)1026according to the services requested by the UEs1002,1004.

The IMS1000also includes a breakout gateway control function (BGCF)1028. The BGCF1028is the IMS1000element that selects the network in which public switched telephone network (PSTN)1030(discussed below) breakout is to occur. If the breakout is to occur in the same network as the BGCF1028, for example, then the BGCF1028selects a media gateway control function (MGCF)1032(also discussed below) that will be responsible for interworking with the PSTN1030. The MGCF1032then receives the SIP signaling from the BGCF1028.

The IMS1000also includes a subscriber location function (SLF)1034. The SLF1034provides information about the HLR/HSS1014that is associated with a particular user profile. It is generally implemented using a database. If the IMS1000contains more than one HLR/HSS1014, then the I-CSCF1022and S-CSCF1024will communicate with SLF1034to locate the appropriate HLR/HSS1014based on the user profile.

The IMS1000also includes the aforementioned TAS(s)1026(e.g., the call application server106). As the name implies, the TAS1026, sometimes known in a telephony context merely as an application server (AS), is a component used to provide telephony applications and additional multimedia functions. The TAS1026can include any entity in a telephone network that carries out functions that are not directly related to the routing of messages through the network. Such functions can include, for example, in-network answering machines, automatic call forwarding, conference bridges and other types of applications. And, while shown as a single entity inFIG. 10, multiple TASs1026are generally used to provide multiple services. Based on the services requested by the UE1002,1004to the S-CSCF1024, for example, the S-CSCF1024can establish sessions with one or more TASs1026, one TAS1026for each service.

The IMS1000also includes the MGCF1032. The MGCF1032is a SIP endpoint that handles call control protocol conversion between SIP and ISDN user part (ISUP)/bearer-independent call control (BICC) and interfaces with the SAE GW1016over stream control transmission protocol (SCTP). The MGCF1032also controls the resources in a media gateway (MGW)1038across an H.248 interface. The MGW1038is a translation device or service that converts media streams between disparate telecommunications technologies such as POTS, SS7, next generation networks (2G1006, 3G1008, 4G LTE1010, and 5G1036) or private branch exchange (PBX) systems.

Finally, the IMS1000also includes the PSTN1030. The PSTN1030is the world's collection of interconnected voice-oriented public telephone networks, both commercial and government-owned. In some cases, the PSTN1030can also be referred to as the plain old telephone service (POTS). With respect to IP phones1012, for example, the PSTN1030furnishes much of the Internet's long-distance infrastructure. Because internet service providers (ISPs) pay long-distance providers for access to their infrastructure and share the circuits among many users through packet-switching (discussed above), internet users avoid having to pay usage tolls to anyone other than their ISPs.

FIG. 11depicts a component level view of a UE1100(e.g., the sender UE102or the recipient UE104) for use with the systems200,300,400,500,1000; GUIs600,700,800; and methods900described herein. The UE1100could be any UE able to send and receive video and/or audio calls in the cellular network. For clarity, the UE1100is described herein generally as a cell phone or smart phone. One of skill in the art will recognize, however, that the systems200,300,400,500,1000; GUIs600,700,800; and methods900described herein can also be used with a variety of other electronic devices, such as, for example, tablet computers, laptops, desktops, and other network (e.g., cellular or IP network) connected devices.

The UE1100can comprise several components to execute the above-mentioned functions. As discussed below, the UE1100can each comprise memory1102including an operating system (OS)1104and one or more standard applications1106. The standard applications1106can include many features common to UE such as, for example, contacts, calendars, call logs, voicemail, etc. In this case, the UE1100can also comprise a multi-way video application1108.

The UE1100can also comprise one or more processors1110and one or more of removable storage1112, non-removable storage1114, transceiver(s)1116, output device(s)1118, and input device(s)1120. In some examples, such as for cellular communication devices, the UE1100can also include a SIM1122and/or an eSIM1124, which can include a mobile country code (MCC), mobile network code (MNC), international mobile subscriber identity (IMSI), and other relevant information. In some examples, one or more of the functions (e.g., standard applications1106and/or the multi-way video application1108) can be stored on the SIM1122or the eSIM1124in addition to, or instead of, being stored in the memory1102.

In various implementations, the memory1102can be volatile (such as random access memory (RAM)), non-volatile (such as read only memory (ROM), flash memory, etc.), or some combination of the two. The memory1102can include all, or part, of the functions1106,1108and the OS1104for the UE1100, among other things. In some examples, rather than being stored in the memory1102, some, or all, of the functions1106,1108, as well as other information (e.g., call history, contacts, etc.) can be stored on a remote server or cloud of servers accessible by the UE1100such as the call application server106.

The memory1102can also include the OS1104. Of course, the OS1104varies depending on the manufacturer of the UE1100and currently comprises, for example, iOS 11.4.1 for Apple products and Pie for Android products. The OS1104contains the modules and software that support a computer's basic functions, such as scheduling tasks, executing applications, and controlling peripherals. In some examples, the OS1104can receive signals from the multi-way video application1108, for example, to enable the UE1100to make one-way, two-way, and audio-only calls, among other things. The OS1104can also enable the UE1100to send and retrieve data via a cellular data connection or internet connection and perform other functions.

The UE1100can also include a multi-way video application1108capable of performing some, or all, of the functions associated with one or more of the systems200,300,400,500,1000and methods900, discussed above. So, the multi-way video application1108can receive inputs from the GUIs600,700,800or other input devices1120, formulate parameters based on the inputs, and then cause the transceiver(s)1116to send the appropriate messages. In some examples, the multi-way video application1108can also include the GUIs600,700,800. In this configuration, the multi-way video application1108can also receive notifications of incoming video calls or call modifications, for example, and cause the UE1100to display the appropriate GUI600,700,800, among other things.

In some examples, the multi-way video application1108may also monitor various parameters and automatically manage calls. In other words, in some examples, the multi-way video application1108can monitor battery levels, processor load, and other UE1100parameters (e.g., via the OS1104) and downgrade calls automatically based on these parameters. While on a two-way video call, for example, if the multi-way video application1108determines that the battery level falls below a first predetermined threshold (e.g., 10% or 20%), the multi-way video application1108can provide the user with a warning message. If the battery level continues to fall to below a second predetermined threshold (e.g., 5% or 10%), then the multi-way video application1108can automatically downgrade the call to a one-way video call or an audio-only call, as necessary.

In some examples, the multi-way video application1108may also perform similar operations based in part on information provided by the cellular network (e.g., traffic levels, signal strength, signal quality, etc.). In some examples, the multi-way video application1108may receive instructions from the cellular network, for example, and then take actions (e.g., upgrade or downgrade video calls) based on the information or instructions. So, the cellular network may send a message indicating that traffic levels have reached a predetermined threshold and that a current video call needs to be downgraded to an audio-only call. The multi-way video application1108can then provide a notification to the user, send the appropriate SIP messaging, and downgrade the call automatically.

Similarly, rather than receiving instructions from the cellular network, the multi-way video application1108may receive data from the cellular network and then make decisions regarding upgrading or downgrading calls. If the user is on a one-way video call, for example, and the multi-way video application1108receives data from the network that conditions have improved, for example, then the multi-way video application1108can display a prompt to ask the user if an upgrade to two-way video is desired. If the user indicates an upgrade is desirable, then the multi-way video application1108can make the appropriate changes. In this configuration, the multi-way video application1108can make decisions based on the network data, onboard data, and other factors—i.e., as opposed to simply receiving instructions from the network.

The UE1100can also comprise one or more processors1110. In some implementations, the processor(s)1110can be a central processing unit (CPU), a graphics processing unit (GPU), both CPU and GPU, or any other processing unit. The UE1100may also include additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Such additional storage is illustrated inFIG. 11by removable storage1112and non-removable storage1114. The removable storage1112and non-removable storage1114can store some, or all, of the functions1106,1108and/or the OS1104.

Non-transitory computer-readable media may include volatile and nonvolatile, removable and non-removable tangible, physical media implemented in technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. The memory1102, removable storage1112, and non-removable storage1114are all examples of non-transitory computer-readable media. Non-transitory computer-readable media include, but are not limited to, RAM, ROM, electronically erasable programmable ROM (EEPROM), flash memory or other memory technology, compact disc ROM (CD-ROM), digital versatile discs (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible, physical medium which can be used to store the desired information and which can be accessed by the UE1100. Any such non-transitory computer-readable media may be part of the UE1100or may be a separate database, databank, remote server, or cloud-based server.

In some implementations, the transceiver(s)1116include any transceivers known in the art. In some examples, the transceiver(s)1116can include wireless modem(s) to facilitate wireless connectivity with other UE (e.g., between the sender UE102and the recipient UE104), the Internet, and/or an intranet via the cellular network. Further, the transceiver(s)1116may include a radio transceiver that performs the function of transmitting and receiving radio frequency communications via an antenna (e.g., Wi-Fi or Bluetooth®). In other examples, the transceiver(s)1116may include wired communication components, such as a wired modem or Ethernet port, for communicating with the other UE or the provider's internet-based network. The transceiver(s)1116can enable the UE1100to send and receive messages and commands associated with the systems200,300,400,500,1000; GUIs600,700,800; and methods900, described above.

In some implementations, the output device(s)1118include any output devices known in the art, such as a display (e.g., a liquid crystal or thin-film transistor (TFT) display), a touchscreen display (e.g., for use with the GUIs600,700,800), speakers, a vibrating mechanism, or a tactile feedback mechanism. In some examples, the output devices can play various sounds when sending or receiving video calls. In some examples, the output device(s)1118may play a different sound or display a different graphic depending on whether the user is receiving a two-way or one-way video call. The output device(s)1118may also play an error tone or display an error message when a video call or a call modification is declined by the recipient. Output device(s)1118can also include ports for one or more peripheral devices, such as headphones, peripheral speakers, or a peripheral display.

In various implementations, input device(s)1120include any input devices known in the art. For example, the input device(s)1120may include a camera, a microphone, or a keyboard/keypad. The input device(s)1120can include the touch-sensitive display or a keyboard to enable users to enter data and make and receive calls via the multi-way video application1108and other applications1106. The touch-sensitive display or keyboard/keypad may be a standard push button alphanumeric multi-key keyboard (such as a conventional QWERTY keyboard), virtual controls on a touchscreen (e.g., as shown in the GUIS600,700,800), or one or more other types of keys or buttons, and may also include a joystick, wheel, and/or designated navigation buttons, or the like.

As shown inFIG. 12, the systems200,300,400,500,1000and methods900can also be used in conjunction with a server1200(e.g., the call application server106, HLR/HSS1014, etc.). To simplify the discussion, the server1200is discussed below as a standalone server. One of skill in the art will recognize, however, that the systems200,300,400,500,1000and methods900disclosed herein can also be implemented partially, or fully, on a network entity such as, for example, the PCRF1018, for example, or a 3GPP AAA server, among other things. Thus, the discussion below in terms of the server1200is not intended to limit the disclosure to the use of a standalone server.

The server1200can be a TAS server (e.g., the call application server106) capable of providing video and/or audio calling services, including sending, receiving, and modifying video calls, as discussed above. The server1200can comprise a number of components to execute part, or all, of the above-mentioned systems200,300,400,500,1000and methods900. The server1200can comprise memory1202including, for example, an OS1204, a network monitor1206, and a network multi-way video application (NMVA)1208. In various implementations, the memory1202can be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.), or some combination of the two. The memory1202can include all, or part, of the functions1206,1208and the OS1204for the server1200, among other things.

The OS1204can vary depending on the manufacturer of the server1200and the type of component. Many servers, for example, run Linux or Windows server. Dedicated cellular routing servers may run specific telecommunications OSs. The OS1204contains the modules and software that supports a computer's basic functions, such as scheduling tasks, executing applications, and controlling peripherals. The OS1204can enable the server1200to receive messages and calls and relay the messages and calls to the addressee (e.g., to and from the sender UE102and the recipient UE104). In some examples, as discussed below, the OS1204can also enable the server1200to perform some, or all, of the systems200,300,400,500,1000and methods900discussed herein.

In some examples, the server1200can include a network monitor1206. The network monitor1206can comprise an application configured to monitor various network conditions such as, for example, traffic levels, available capacity, delay, and jitter. In other examples, the network monitor120can receive various network performance parameters from another network entity (e.g., the I-CSCF1022), rather than monitoring them directly. In still other examples, the network monitor1206can also receive information from the UEs102,104or from one or more wireless base stations (WBSs) related to traffic levels, signal quality, signal strength, etc.

The network monitor1206can provide data to the NMVA1208. The NMVA1208, in turn, can manage upgrading and downgrading video calls for the UEs102,104or can provide information to the UEs102,104for their use in managing video calls. So, for example, the NMVA1208may provide instructions or data to the multi-way video application1108to facilitate modifying calls as network conditions change. The NMVA1208may receive data from other network entities regarding network traffic levels, for example, determine that network availability has fallen below a predetermined level, and, in response, send instructions to one or more UE to downgrade to one-way video or audio-only calls.

The server1200can also comprise one or more processors1210. In some implementations, the processor(s)1210can be a central processing unit (CPU), a graphics processing unit (GPU), both CPU and GPU, or any other processing unit. The server1200can also include one or more of removable storage1212, non-removable storage1214, transceiver(s)1216, output device(s)1218, and input device(s)1220.

The server1200may also include additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Such additional storage is illustrated inFIG. 12by removable storage1212and non-removable storage1214. The removable storage1212and non-removable storage1214can store some, or all, of the OS1204and functions1206,1208.

Non-transitory computer-readable media may include volatile and nonvolatile, removable and non-removable tangible, physical media implemented in technology for storage of information, such as computer-readable instructions, data structures, program modules, or other data. The memory1202, removable storage1212, and non-removable storage1214are all examples of non-transitory computer-readable media. Non-transitory computer-readable media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, DVDs or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible, physical medium which can be used to store the desired information and which can be accessed by the server1200. Any such non-transitory computer-readable media may be part of the server1200or may be a separate database, databank, remote server, or cloud-based server.

In some implementations, the transceiver(s)1216include any transceivers known in the art. In some examples, the transceiver(s)1216can include wireless modem(s) to facilitate wireless connectivity with the UEs102,104, the Internet, the cellular network, and/or an intranet via a cellular connection. Further, the transceiver(s)1216may include a radio transceiver that performs the function of transmitting and receiving radio frequency communications via an antenna (e.g., Wi-Fi or Bluetooth®) to connect to the IP network1012. In other examples, the transceiver(s)1216may include wired communication components, such as a wired modem or Ethernet port. The transceiver(s)1216can enable the server1200to communicate with the UEs102,104and to send and receive messages and calls between the UEs102,104and/or other UEs.

In some implementations, the output device(s)1218include any output devices known in the art, such as a display (e.g., a liquid crystal or thin-film transistor (TFT) display), a touchscreen display, speakers, a vibrating mechanism, or a tactile feedback mechanism. In some examples, the output devices can play various sounds based on, for example, whether the server1200is connected to a network, when a message is sent or received, when a message is modified, or when a message modification is rejected by an incompatible UE102,104, among other things. Output device(s)1218also include ports for one or more peripheral devices, such as headphones, peripheral speakers, or a peripheral display.

In various implementations, input device(s)1220include any input devices known in the art. For example, the input device(s)1220may include a camera, a microphone, a keyboard/keypad, or a touch-sensitive display. A keyboard/keypad may be a standard push button alphanumeric, multi-key keyboard (such as a conventional QWERTY keyboard), virtual controls on a touchscreen, or one or more other types of keys or buttons, and may also include a joystick, wheel, and/or designated navigation buttons, or the like.

While several possible examples are disclosed above, examples of the present disclosure are not so limited. For instance, while the systems and methods above are discussed with reference to use with cellular communications, the systems and methods can be used with other types of wired and wireless communications. In addition, while various functions are discussed as being performed on the UEs102,104and/or on the call application server106, for example, other components, such as network entities, could perform some, or all, of these functions without departing from the spirit of the invention. In addition, while the disclosure is primarily directed to UEs102,104sending, receiving, and modifying video calls, it can also be used with other types of communications and on other devices (e.g., IP network1012devices, M2M, or IoT devices) on the same, or similar, networks or future networks. Indeed, the systems200,300,400,500,1000; GUIs600,700,800; and methods900described herein can be applied to virtually any network that provides multiple modes of communication.

Such changes are intended to be embraced within the scope of this disclosure. The presently disclosed examples, therefore, are considered in all respects to be illustrative and not restrictive. The scope of the disclosure is indicated by the appended claims, rather than the foregoing description, and all changes that come within the meaning and range of equivalents thereof are intended to be embraced therein.