COMMUNICATION SESSION SETUP PROCEDURE THAT ACCOUNTS FOR ENDPOINT BATTERY STATUS

The technology disclosed herein enables consideration of battery status for an endpoint when configuring a codec for a communication session. In a particular example, a method provides, in an endpoint being powered by a battery, identifying a request to establish a communication session with the endpoint and determining a battery status of the battery. In response to determining the battery status satisfies a low-power criterion, the method provides selecting one or more parameters of a plurality of possible parameters for the communication session that result in lower power usage relative to non-selected parameters of the plurality of possible parameters and establishing the communication session using the one or more parameters.

BACKGROUND

During initiation of a communication session, such as during a SIP call setup handshake, endpoints can offer many different protocols and codecs for the same media type. For example, a SIP audio call can connect with G.711, G.729, G.722, the IETF RFC-6716 “Opus” codec, and so on.

Many factors can influence which protocol or codec would be preferred when more than one is available. For example, the G.722 and G.722.2 audio codecs provide similar acoustic benefits (i.e., both support “wideband” audio, up to approximately 7 KHz, as opposed to the roughly 3.4 KHz upper limit of G.711 and G.729). An important difference is that the G.722 codec is computationally simpler than G.722.2, but it is also a bandwidth hog (up to 64 kbits/second vs 23.85 kbits/sec for equivalent quality G.722.2). G.722 is often the preferred wideband codec for wired SIP endpoints, where it can be beneficial to accept a higher kbit/sec transmission rate in exchange for decreased encoding/decoding complexity. Alternatively, when it's more important to conserve network bandwidth than it is to reduce the encoding/decoding complexity (as may be the case, for example, with mobile phones), G.722.2 is often the preferred codec.

Continuing to use the G.722 and G.722.2 codecs as illustrative examples, G.722.2 encoding/decoding consumes battery power more rapidly than G.722 because G.722.2 is computationally more complex. In another example, G.729 consumes battery power more rapidly than G.711 because G.729 is a compression codec utilizing Code Excited Linear Prediction, and is therefore computationally more complex than G.711, which is a comparatively simple Pulse Code Modulation technique.

SUMMARY

The technology disclosed herein enables consideration of battery status for an endpoint when configuring a codec for a communication session. In a particular example, a method provides, in an endpoint being powered by a battery, identifying a request to establish a communication session with the endpoint and determining a battery status of the battery. In response to determining the battery status satisfies a low-power criterion, the method provides selecting one or more parameters of a plurality of possible parameters for the communication session that result in lower power usage relative to non-selected parameters of the plurality of possible parameters and establishing the communication session using the one or more parameters.

In another example, an apparatus is provided having one or more computer readable storage media and one or more processing systems operatively coupled with the one or more computer readable storage media. Program instructions stored on the one or more computer readable storage media, when read and executed by the processing system, direct the apparatus to determine a battery level of a battery powering the apparatus and select one or more codecs for a communication session based on the battery level. The program instructions also direct the processing system to negotiate a session codec from the one or more codecs with other endpoints to the communication session and establish the communication session using the session codec on user communications exchanged over the communication session.

In a further example, one or more computer readable storage media are provided. The computer readable storage media has program instructions stored thereon that, when read and executed by a processing system, direct the processing system to receive a request from a user of a first endpoint to initiate a communication session with a second endpoint, determine a battery level of a battery powering the first endpoint, and select one or more codecs for the communication session based on the battery level. The program instructions also direct the processing system to use Session Initiation Protocol (SIP) to negotiate a session codec from the one or more codecs with other endpoints to the communication session and establish the communication session using the session codec on the user communications exchanged.

DETAILED DESCRIPTION

Session Initiation Protocol (SIP) plays a crucial role in initiating communication sessions by facilitating negotiation between endpoints to select a compatible codec. When a communication session is initiated, SIP begins by sending a SIP INVITE message from the calling party's endpoint to the called party. This message typically contains crucial information such as the caller's identity, the called party's network address, and the desired communication parameters, including the codecs supported by the caller. Upon receiving the SIP INVITE message, the called party's endpoint responds with a SIP 200 OK message, indicating that the request is accepted.

Simultaneously, within the SIP 200 OK message, the called party's endpoint communicates its supported codecs back to the calling party. The calling party's endpoint processes this information to identify a common codec supported by both endpoints. If there's a codec mismatch, SIP initiates negotiation mechanisms, typically through SIP messages like SDP (Session Description Protocol), to find a compromise. Once a mutually supported codec is agreed upon, SIP signals the endpoints to establish the communication session, ensuring that both parties can communicate effectively by encoding and decoding the audio or video streams using the selected codec. This negotiation process facilitated by SIP ensures seamless communication between diverse endpoints with varying codec capabilities.

More and more SIP endpoints are battery powered devices, such as laptops, tablet computers, smartphones, etc., but SIP does not currently account for battery life when selecting a codec. The amount of power used by an endpoint during a communication session differs depending on the codec used by the endpoint. For instance, some codecs place a higher computational load on the endpoint. An endpoint in the examples below determines a status the endpoint's battery and limits SIP to negotiating from codecs selected based on the battery status. As a generic example, codecs having lower power consumption may be selected for a communication session that may not otherwise be able to complete if a higher power consumption codec was used. Even if the higher power consumption codec is supported by all endpoints on the communication session, the endpoint will leave the higher power consumption codec out of the endpoint's available codecs during negotiation, preventing the higher power consumption codec from being selected for the communication session.

The endpoint may also consider parameters beyond codecs that impact the exchange of communications on a communication session. For instance, even after a codec is selected, configuration of the codec may affect the amount of power consumed when using that codec. Bitrate for audio/video communications, and resolution and framerate for video communications, may be configured to reduce the codecs power usage. Also, a connection to a communication network may be selected based on the battery status. One type of connection available to the endpoint may use more power than another type (e.g., the modem for one connection may use more power than the modem for another or a connection with a low signal strength may use more power that a connection with a higher signal strength). Other types of parameters may also be considered when establishing a communication session optimally use available battery power.

FIG.1illustrates implementation100for considering a battery status of an endpoint when configuring a communication session. Implementation100includes endpoint101and endpoint102. Endpoint101is operated by user141and endpoint102is operated by user142. Endpoint101and endpoint102communicate over communication link111. Communication link111may be a direct link or may include intervening systems, networks, and/or devices.

Endpoint101is a computing system, such as a laptop, tablet computer, smartphone, etc., powered by battery121. When battery121is empty, endpoint101may be plugged in or use wireless charging to receive external power to recharge battery121. Endpoint101may also be able to operate while connected to external power. Endpoint102is also a computing system and may be powered by a battery, although, no battery is shown in implementation100. Endpoint101and endpoint102establish a communication session over communication link111. In this example, endpoint101and endpoint102communicate directly with one another. In other examples, an intervening system may facilitate the communication session between endpoint101and endpoint102.

In this example, user141initiates the session request at endpoint101to call user142. In other examples, user142may initiate the session at endpoint102and endpoint101may receive a session request from endpoint102. Endpoint101checks battery status131. Battery status131may indicate an amount of power remaining in battery121(e.g., a battery charge percentage), an amount of power capable of being provided by battery121(e.g., as batteries age and/or get low on charge, the amount of power provided by the battery may be reduced), battery temperature (e.g., battery temperature being too high may reduce the amount of power that can be provided), or some other type of status. Endpoint101determines which parameters should be offered for the communication session based on battery status131. The parameters may include one or more codecs, one or more codec configurations (e.g., bitrates, framerates, resolutions, etc.),

Endpoint101may determine the parameters based solely on battery status131or may use other information that may affect power usage from battery121. For instance, endpoint101may determine its current location and/or a location to which endpoint101may be moving to determine a wireless communication link that should be used for the communication session. In another example, endpoint101may also estimate how long a communication session will last to estimate whether different parameter combinations will enable the communication session to complete prior to battery121running out of energy. In some examples, endpoint101may present the different parameter combinations to user141with estimates as to how long battery121will last. User141may select a parameter combination based on their own judgment regarding how long user141's thinks they need battery121to last (e.g., just for the length of the communication session or long enough for activities afterwards) versus compromises of different parameter combinations (e.g., one combination may use a lower quality codec but a more costly wireless link).

Once the parameters are selected, endpoint101initiates the requested communication session using the parameters. In some examples, if conditions change during the course of the communication session, endpoint101may determine the new conditions warrant different parameters and may reconfigure the communication session to use the different parameters.

FIG.2illustrates operation200to consider a battery status of an endpoint when configuring a communication session. In operation200, endpoint101identifies a request to establish a communication session (step201). Endpoint101may receive a user instruction from user141to initiate the communication session or may receive a communication session request, such as a SIP INVITE message or a message using some other protocol, from endpoint102. The communication session may be a real-time audio or video call enabling user141and user142to speak with each other in real time. While each endpoint is only shown to have one user in this example, one or more of endpoints101-102may have multiple users. Similarly, while the communication session in this example is between two endpoints, the communication session in other examples may be between more than two endpoints. Endpoint101may execute a client application enabling user141to participate in communication sessions.

Endpoint101also determines battery status131of battery121(step202). Endpoint101may determine battery status131after receiving the request to have the most up to date battery status information or endpoint101may regularly (e.g., periodically or continually) monitor battery status131such that battery status131is already known by endpoint101when the request is received. Battery status131may include an amount of energy remaining in battery121, a charge level of battery121relative to full, a power output of battery121, a temperature of battery121, or some other type of information describing battery121's condition.

Endpoint101analyzes battery status131to determine whether at least one low-power criterion is satisfied (step203). In a simple example, the criterion may be a threshold battery charge level. In other examples, the criterion may be dynamic. For instance, rather than a static battery level threshold, the threshold may be dynamic depending on conditions for the communication session. The threshold may be adjusted to ensure proper parameters are selected given the characteristics of the communication session and the characteristics of battery status131. For example, endpoint101may determine that the communication session is likely only going to last 15 minutes. The dynamic battery level threshold in that case may be much lower than had the communication session been estimated to last an hour (e.g., battery121at a low charge level may still be able to support a 15-minute call using a power-hungry codec but cannot support the same codec for a full hour). In some examples, the criterion may be defined by the call conditions themselves. Using the above session time example, endpoint101may estimate how long the session will last and then determine which parameter configurations will enable battery121to power endpoint101for the entire session. If all parameter configurations can power endpoint101until the estimated end time of the session, then endpoint101may consider the low-power condition to not be satisfied. If, however, not all configurations will last until the estimated end of the session, the criterion is satisfied and endpoint101will select one or more parameter configurations that will enable endpoint101to be powered by battery121until the end of the session. In examples where endpoint101is plugged into external power such that battery121is not currently responsible for powering endpoint101, then endpoint101may consider the low-power criterion to not be met by default.

If the low-power criterion is not satisfied, endpoint101selects from all available parameters to configure the communication session (step204). The parameters may include all supported codecs, codec configurations (e.g., bitrates, framerates, resolutions, etc.), wireless links, or other type of parameter that may affect the communication session. In other words, if the low-power criterion is not satisfied, then endpoint101establishes the communication session in the same manner endpoint101would if battery status131was not considered. While any protocol for initiating sessions may be used, if SIP is used by endpoint101, this means endpoint101negotiates the codec to be used for the session with endpoint102as defined by the protocol without limitation.

If the low-power criterion is satisfied, endpoint101selects a subset of the available parameters (step205). The parameter configurations included in the subset, if used by endpoint101, will use less power from battery121than other potential parameter configurations not included in the subset. How much less power depends on the low-power criterion being triggered. For instance, with battery status131being equal in both cases, an estimated 30-minute session may result in different parameters being selected than would be selected for an estimated 15-minute session. That is, even if a criterion is met for both session lengths endpoint101may select even less power-hungry parameters (i.e., parameters that cause endpoint101to consumer more power) to power the 30-minute call verses those selected for the 15-minute call because the 30-minute call will need power for twice as long. In some examples, endpoint101may include a buffer in its calculations of which parameters to select. The buffer helps ensure battery121still has some charge left upon completion of the communication session (e.g., endpoint101may select parameters that allow 10% battery charge level to remain after the session concludes). Endpoint101may estimate the length of the session by accessing a calendar of user141on endpoint101to identify a scheduled amount of time for the communication session (assuming an entry exists in the calendar for the session), may reference call logs to determine how long sessions between user141and user142typically last, may request an estimated length from user141, or may estimate the length based on some other information.

Different parameter configurations may be used to achieve the desired power-saving goals. For example, a codec with a higher computational load may still be included if the parameters also provide a lower framerate and/or resolution than a codec with a lower computational load. In another example, if a lower power wireless link can be used, then endpoint101may be able to select more power-hungry codecs and/or codec configuration parameters to use power freed up by the wireless link selection. Including both codecs may be beneficial to increase the chances that a supported codec can be agreed upon during establishment of the communication session. In some examples, endpoint101may present some or all parameter combinations to user141and enable user141to select a desired parameter combination. Endpoint101may present information, such as an estimated amount of time the battery will last, to aid user141when making their decision about which parameter configuration to select.

Once parameters are selected at either step204or step205, endpoint101establishes the communication session using the selected parameters (step206). How the parameters are used may depend on the protocol being used to establish the session. In one example, endpoint101may just configure the communication session under the assumption endpoint102can handle a communication session with the configured parameters (e.g., may use the highest quality parameters determined in the preceding steps) or may attempt establishment using different parameters until endpoint102accepts the parameters being used (e.g., may attempt successively lower quality parameters until parameters are accepted by endpoint102). In other examples, endpoint101may negotiate with endpoint102on the parameters being used. For instance, using SIP, endpoint101may limit the codecs used in the negotiation to those identified at step205(or limits the codecs to all potential codecs supported by endpoint101if the criterion was not met). From the perspective of endpoint102, endpoint101is simply providing the codecs that are compatible with endpoint101. Endpoint102has no reason to know that the codecs offered by endpoint101are fewer than what endpoint101actually supports due to battery status131. Establishing the communication session using the subset of codecs enables endpoint101to use less power from battery121for the communication session that may otherwise have occurred with all codecs being available. In some examples, endpoint102may similarly be battery powered and selecting parameters based on the status of endpoint102's battery to limit what parameters are offered to endpoint101.

FIG.3illustrates operational scenario300for considering a battery status of an endpoint when configuring a communication session. In operational scenario300, endpoint102requests a communication session with endpoint101(step301). User142may trigger the request by interacting with a client application for the communication session executing on endpoint102or the request may be initiated in some other manner. If using SIP, the request may be a SIP INVITE message. Upon receiving the request, endpoint101determines battery status131(step302). Battery status131may be determined from battery control circuitry, a battery control component of endpoint101's operating system, one or more sensors in endpoint101(e.g., a temperature sensor, voltmeter, etc.), or from some other source. In this example, endpoint101selects codecs to be offered to endpoint102based on battery status131(step303). If battery status131indicates codecs that consume less power should be used to handle the communication session, endpoint101does not select higher power consumption codecs. Endpoint102also selects codecs (step304). If endpoint102is not performing similar to endpoint101by selecting codecs based on battery status, endpoint102may simply select all codecs endpoint102is capable of handling.

After selecting the codecs, endpoint101and endpoint102negotiate which codec will be used for the requested session (step305). In the case of SIP, endpoint101may response to the SIP INVITE with a SIP 200 OK message. In the SIP 200 OK message, endpoint101may include the codecs endpoint101selected. Upon receiving the SIP 200 OK message, endpoint102may select a codec to use for the session that is included in both the SIP 200 OK message and the codecs endpoint102selected for itself. Endpoint102signals endpoint101to set up the session using the selected codec. In some examples, multiple codecs may be selected. For instance, a video call session may use one codec for audio and another codec for video. Once the communication is established, user communications can be exchanged over the established session. Endpoint101and endpoint102both capture user communications (e.g., voice and video) from their respective users, user141and user142. The captured communications are encoded by the respective endpoints101-102(steps306A and306B) before being transmitted over the communication session (step307).

FIG.4illustrates operation400to consider a battery status of an endpoint when configuring a communication session. In operation400, endpoint101receives a user-preferred codec (step401). The user-preferred codec may act as a default codec for communication sessions. The user-preferred codec may be a codec that user141prefers due to the perceived quality by user141, may serve a purpose for computing systems (e.g., hard-of-hearing users may require a wideband audio codec like G.722 or G.722.2), or may be preferred by user141for some other reason.

At some point after setting the user-preferred codec, endpoint101receives a session request (step402). The session request may be received from user141to initiate the communication session with endpoint102or may be a request received from endpoint102. Like in operation200, endpoint101determines battery status131(step403). In this example, the criterion is a threshold battery charge level, which may be static or dynamic, as described above, and battery status131indicates the current battery charge level of endpoint101. Endpoint101determines whether the battery charge level is below the threshold (step404). If not, endpoint101selects the user-preferred codec (step405). If the charge level is below the threshold, endpoint101selects a lower-power codec (i.e., a codec that will not drain battery121as fast as the user-preferred codec) (step406). Using the hard-of-hearing example from above, the user-preferred codec may be G.722.2, which is more computationally complex than G.722. While both codecs are wideband, G.722 may be selected at step406because G.722 will use less power when encoding/decoding audio. G.722 may create an audio signal that uses more bandwidth than one generated by G.722.2 but that may be a tradeoff endpoint101is willing to make in the interest of conserving battery power.

Endpoint101establishes the communication session with endpoint102using the selected codec (step407). In some examples, endpoint101may only offer the selected codec to endpoint102in hopes that the selected codec is supported by endpoint102. In the hard-of-hearing example, endpoint101may not offer codecs other than G.722 and G.722.2 to ensure the communication session is suitable for hard-of-hearing users. In other examples, endpoint101may indicate a preference for a certain codec but may offer other selected codecs as well.

FIG.5illustrates operation500to consider a battery status of an endpoint when configuring a communication session. Operation500is an example where endpoint101receives a video call request (step501) and adjusts configuration of a video codec based on battery status131. Again, the video call request may come from user141or may be a session request received from endpoint102. Endpoint101determines battery status131(step502) and, like in operation400, determines whether the current battery charge level is below a threshold charge level (step503). If the battery charge level is not below the threshold, endpoint101can select a highest possible framerate and/or resolution for the video encoded using the codec (step505). Only framerate and resolution are discussed in this example but, in other examples, additional parameters may be considered, such a number of colors supported or bitrate. The highest possible resolution/framerate may be defined by the video codec, may be limited by hardware of endpoint101(e.g., screen/camera resolution), may be limited by bandwidth available on communication link111, or may be defined in some other manner.

If endpoint101determines the current battery charge level is lower than the threshold, then endpoint101selects a lower framerate and/or resolution that would otherwise be allowed (step506). Lowering the framerate or resolution typically reduces the computational load on endpoint101when encoding/decoding video. In some examples, endpoint101may first select a codec for the video based on battery status131and then, if necessary, further reduce the power consumed by the selected codec by limiting framerate and/or resolution parameters. Endpoint101establishes the communication session with the selected framerate and resolution (step507). Endpoint101may inform endpoint102that the selected framerate and resolution are all that endpoint101supports to ensure endpoint102only uses the selected framerate and resolution. Although, in some examples, endpoint101may merely encode video using the framerate and resolution to at least gain the power-saving benefits on the encoding side but not necessarily the decoding side as endpoint102may send video at a different framerate or resolution. In some examples, endpoint101may adjust the framerate and/or resolution after establishment of the communication session.

FIG.6illustrates operation600to consider a battery status of an endpoint when configuring a communication session. Operation600begins much like operations described above with endpoint101receiving a session request (step601). Endpoint101determines an initial battery status131(step602) and negotiates a codec with endpoint102based on the initial battery status131(step603). That is, endpoint101determines codecs that will not run through what remains of the charge in battery121, as indicated by battery status131, before the session ends. Those determined codecs are offered to endpoint102during negotiation and one of the codecs is selected. Endpoint101establishes the communication session using the selected codec (step604).

During the communication session, circumstances change for endpoint101and the communication session. For example, endpoint101may move to a new location or endpoint101may preemptively determine that endpoint101is moving towards a new location. In another example, endpoint101may determine that the communication session is running longer than originally estimated or is using more power than originally predicted. As such, endpoint101may determine a subsequent battery status131(step605) and determine whether a battery charge level indicated by battery status131is lower than a low-power threshold (step606). If the battery charge level is not lower, the communication session continues without modification and returns to step605to determine new battery status131for subsequent conditions for the communication session. If, however, the battery charge level is below the threshold, endpoint101selects a new codec(s) and renegotiates the codec for the communication session with endpoint102(step607). Preferably, the renegotiation and switching of codecs occurs with little to no disruption to the user experience on the communication session.

In a particular example of operation600, endpoint101may start the communication session at a location with a WIFI connection. At that time, endpoint101may determine the initial battery status131does not warrant selection of fewer than all possible codecs to offer endpoint102during negotiation. During the communication session, endpoint101may move to a different location away from WIFI and must instead use a cellular connection for the communication session. Cellular communications typically use more power than WIFI communications. Endpoint101initial determinations based on the power usage of WIFI are no longer valid. Therefore, endpoint101recalculates the power being used for the communication session and determines that battery121is not going to last the duration of the communication session (i.e., falls below the threshold). Endpoint101selects one or more codecs that use less power than the codec currently being used and renegotiates with endpoint102to use one of the lower-power codecs instead.

In some examples, multiple thresholds may exist. For instance, endpoint101may initially determine based on one threshold that a first codec can be used for the communication session. Then, upon determining that the communication session is lasting longer than first estimated, a second threshold indicates that a second, lower-power codec will be needed to make battery121last until the end of the communication session. Endpoint101will then renegotiate for the lower codec.

FIG.7illustrates implementation700for considering a battery status of an endpoint when configuring a communication session. Implementation700includes communication session system701, endpoints702-703, and communication network704. Communication network704may include one or more local area networks, wide area networks (e.g., the Internet), or other types of communication links, systems, and devices-including combinations thereof. Endpoint702is shown to be powered by battery722but one or more of endpoints703may also be battery powered.

In operation, communication session system701facilitates communication sessions between endpoints702-703. Communication session system701may be a conferencing server that provides a conference bridge for videoconferences. In this example, to host a communication session between endpoints702-703, communication session system701establishes individual communication sessions with each of endpoints702-703. Communication session system701aggregates the user communications (e.g., audio and video of participants at endpoints702-703) before sending the aggregated communications over communication network704to endpoints702-703. The individual sessions enable different codecs, or other parameters, to be used with different ones of endpoints702-703. All of endpoints702-703, therefore, do not need to have overlapping codecs supported to communicate via communication session system701. Also, endpoint702can select codecs/parameters that use less power from battery722while not requiring other endpoints703to also use the same codec/parameters. For instance, endpoints703may communicate with higher-quality video using higher quality, more power-hungry codecs/parameters with video from endpoint702using less power-hungry codec/parameters. In this example, endpoint702supports codecs731, which are codecs for video communications. Endpoint702also supports audio codecs that, while not discussed, may also be selected based on their power consumption characteristics.

FIG.8illustrates operational scenario800for considering a battery status of an endpoint when configuring a communication session. Operational scenario800begins near the time when a videoconference session hosted by communication session system701is scheduled to begin between endpoints702-703. Endpoint702determines a battery status of battery722(step801). The battery status is used as a basis for selecting one of codecs731(step802). Codecs731include high power codec732, medium power codec733, and low power codec734, which are named as such due to high power codec732being a higher power consumption codec than medium power codec733and low power codec734. Likewise, medium power codec733is a higher power consumption codec than low power codec734. If the battery status of battery722indicates that battery722has enough power remaining to handle the entirety of the videoconference session (e.g., as indicated by a calendar entry for the videoconference) regardless of codec selected, endpoint702may select high power codec732because endpoint702is a higher quality codec (and/or uses less bandwidth). However, if high power codec732is too power hungry to last the entire session (or last until a buffer charge amount is reached), then endpoint702may select medium power codec733or low power codec734depending on which is more likely to consume an amount of power from battery722that allows endpoint702to remain powered until the end of the session.

After selecting one of codecs731, the videoconference session is established through communication session system701(step803). Each individual endpoint of endpoints702-703negotiates a session connection with communication session system701when establishing the videoconference session. Each negotiation includes a negotiation regarding which codec will be used between the endpoint and communication session system701. In the case of endpoint702, endpoint702negotiates based on the codec selected above. Endpoint702may only offer a single selected codec or may offer all codecs that will still work for the communication session based on the determined battery status of battery722. For instance, if endpoint702determines high power codec732will work for the communication session, endpoint702may offer all of codecs731during codec negotiation. If endpoint702determines medium power codec733is the highest-powered codec that will work, endpoint702may only offer medium power codec733and low power codec734during the codec negotiation. In all likelihood, communication session system701will also select the highest-powered codec offered by endpoint702but communication session system701may have reason not to select the highest-powered codec (e.g., communication session system701may be under high load, so reducing computational load may be desired).

After establishing the communication session, communication session system701encodes video communications captured by endpoint702of a participant operating endpoint702(step804). The encoded communications are transmitted to communication session system701(step805), which transcodes the communications into one or more codecs used for the session connections established with endpoints703(step806). The transcoded communications are transmitted over the session connections to endpoints703(step807). Since steps804-807occur during a real-time videoconference session, steps804-807happen in real time continuously during the communication session to provide live video of the participant at endpoint702.

Concurrently with steps804-807, communication session system701receives video communications from endpoints703encoded with whichever codec(s) are used for the session connections established with endpoints703(step808). The received communications are transcoded to the codec selected for the session connection with endpoint702(step809). Endpoint702receives the transcoded communications and decodes the communications for display to the participant at endpoint702(step810). Like steps804-807, steps808-810occur continuously in real time to provide live video of participants at endpoints703during the videoconference. If at any point during the videoconference session, endpoint702determines the battery charge level of battery722necessitates a codec change to make it to the end of the session, endpoint702may renegotiate its session connection with communication session system701. The session connections between endpoints703and communication session system701would remain unaffected.

FIG.9illustrates computing system900for considering a battery status of an endpoint when configuring a communication session. Computing system900is representative of any computing system or systems with which the various operational architectures, processes, scenarios, and sequences disclosed herein can be implemented. Computing system900is an example architecture for endpoints101-102and702-702and communication session system701, although other examples may exist. Computing system900includes storage system945, processing system950, and communication interface960. Processing system950is operatively linked to communication interface960and storage system945. Communication interface960may be communicatively linked to storage system945in some implementations. Computing system900may further include other components such as a battery and enclosure that are not shown for clarity.

Communication interface960comprises components that communicate over communication links, such as network cards, ports, radio frequency (RF), processing circuitry and software, or some other communication devices. Communication interface960may be configured to communicate over metallic, wireless, or optical links. Communication interface960may be configured to use Time Division Multiplex (TDM), Internet Protocol (IP), Ethernet, optical networking, wireless protocols, communication signaling, or some other communication format—including combinations thereof. Communication interface960may be configured to communicate with one or more web servers and other computing systems via one or more networks.

Processing system950comprises microprocessor and other circuitry that retrieves and executes operating software from storage system945. Storage system945may include volatile and nonvolatile, removable, and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. Storage system945may be implemented as a single storage device but may also be implemented across multiple storage devices or sub-systems. Storage system945may comprise additional elements, such as a controller to read operating software from the storage systems. Examples of storage media include random access memory, read only memory, magnetic disks, optical disks, and flash memory, as well as any combination or variation thereof, or any other type of storage media. In some implementations, the storage media may be a non-transitory storage media. In some instances, at least a portion of the storage media may be transitory. In no interpretations would storage media of storage system945, or any other computer-readable storage medium herein, be considered a transitory form of signal transmission (often referred to as “signals per se”), such as a propagating electrical or electromagnetic signal or carrier wave.

Processing system950is typically mounted on a circuit board that may also hold the storage system. The operating software of storage system945comprises computer programs, firmware, or some other form of machine-readable program instructions. The operating software of storage system945comprises parameter selector930. The operating software on storage system945may further include an operating system, utilities, drivers, network interfaces, applications, or some other type of software. When read and executed by processing system950, the operating software on storage system945directs computing system900to display indicators in a participant list that convey visually discernable sentiments of the participants identified therein as described herein.

In at least one example, parameter selector930directs processing system950to determine a battery level of a battery powering the apparatus and select one or more codecs for a communication session based on the battery level. Parameter selector930further directs processing system950to negotiate a session codec from the one or more codecs with other endpoints to the communication session and establish the communication session using the session codec on user communications exchanged over the communication session.