具有升级前参与确认的无缝呼叫转换的制作方法
背景技术：
移动电话现在具有提供各种各样的通信模式的功能和应用。例如，单个设备现在能够支持常规的电话呼叫、因特网语音协议(voip)呼叫、视频呼叫、等等。然而，这些功能尚未被特别好地集成，并且各种用户体验方面尚有不足。
例如，虽然许多设备支持视频呼叫，但是主流通信形式仍是仅音频呼叫。虽然用于视频呼叫的技术已经成熟，但是用户体验仍不是最优的。例如，在参与仅音频呼叫的同时，无法向用户呈现受益于可供使用的视频呼叫技术的简单的方式，或者当试图使用视频呼叫技术时可能发生非期望的行为。
因为用户在试图利用不同的通信模式时会面临障碍，所以仍有改进的余地。
技术实现要素：
提供该发明内容以便以下文在具体实施方式中进一步描述的简化形式来引入概念的选择。该发明内容不意在标识出权利要求主题的关键特征或主要特征，也不意在用于限制权利要求主题的范围。
实施例能够实现为方法，包括：对于存储在通信设备处的多个联系人，读取联系人的联系信息；将联系信息传送到地址交流中心；接收联系人中的参与联系人的参与确认；在本地存储参与联系人是视频呼叫服务的参与者的指示；以及随后，在与参与联系人的仅音频呼叫期间，响应于存储的指示，呈现经由视频呼叫服务来将仅音频呼叫升级到视频呼叫的选项。
实施例能够实现为一种系统，包括端点设备，端点设备包括视频呼叫应用、转换引擎、以及多个存储的联系人，其中端点设备与地址簿交流中心通信，其中地址簿交流中心存储视频呼叫服务的用户的多个标识符；其中端点设备被配置为周期性地将关于多个存储的联系人中的特定联系人的信息传送到地址簿交流中心并且在响应中接收特定联系人是视频呼叫服务的参与者的确认；并且其中端点设备被配置为在经由视频呼叫服务的仅音频呼叫到视频呼叫的呼叫升级期间，对于该特定联系人绕过确认用户接口。
实施例能够实现为一个或多个计算机可读介质，包含使通信设备执行一种方法的计算机可执行指令，所述方法包括：确定通信设备空闲；对于存储在通信设备处的多个联系人，读取多个联系人的联系信息；将联系信息传送到地址交流中心；经由地址交流中心，接收参与联系人的参与确认；在本地存储参与联系人是视频呼叫服务的参与者的指示；随后，在与参与联系人的仅音频呼叫期间，呈现经由视频呼叫服务添加视频到仅音频呼叫的选项；以及对于该参与联系人绕过确认用户接口。
如本文所描述的，各种其它特征和优点能够根据需要被并入该技术中。
附图说明
图1是实现无缝呼叫转换的示范性的系统的框图。
图2是实现无缝呼叫转换的示范性的方法的流程图。
图3是被配置为判定无缝呼叫转换是否是可能的的示范性的系统的框图。
图4是判定无缝呼叫转换是否是可能的的示范性的方法的流程图。
图5是实现无缝呼叫转换的示范性的呼叫进展用户接口的线框。
图6是转换呼叫的示范性的方法的流程图。
图7是注册通信应用以实现无缝呼叫转换的示范性的方法的流程图。
图8是存储优选的通信应用的表格的框图。
图9是用于为呼叫类型选择优选应用的示范性的设置用户接口的线框。
图10是实现精确呼叫升级的示范性的系统的框图。
图11是实现精确呼叫升级的示范性的方法的流程图。
图12是从不同设备的视角实现精确呼叫升级的示范性的方法的流程图。
图13是从不同设备的视角实现精确呼叫升级的示例性的其它方法的流程图。
图14是存储包括升级指示的视频呼叫上下文信息的示范性的数据结构的框图。
图15是在呼叫升级方案中处理视频呼叫上下文信息的示范性的方法的流程图。
图16是实现升级前联系参与确认的示范性的系统的框图。
图17是实现升级前联系参与确认的示范性的方法的流程图。
图18、19、20和21是示出用于实现技术的呼叫处理的流程图，包括仅音频呼叫到视频呼叫的无缝升级。
图22是示出用于实现技术的处理的流程图，包括升级前参与确认。
图23是示范性的计算系统的图，其中能够实现一些所描述的实施例。
图24是能够被用于本文所描述的技术的示范性的移动设备。
图25是能够与本文所描述的技术相结合使用的示范性的云支持环境。
具体实施方式
示例1-示范性的概述
本文描述的技术能够用于各种无缝呼叫转换方案，并且该技术的采用能够提供经由不同呼叫类型通信的改进技术。用户接口能够更好地实现无缝呼叫转换。本文描述的其它特征能够被实现以针对用户偏好来定制呼叫体验。能够得到呼叫类型之间具有更平滑转换的总体优良的用户体验。
在仅音频呼叫升级到视频呼叫的情况下，接收用户(即，被邀请方)可能在多个端点设备处在线。如本文所描述的，在一些实施例中，邀请可以仅显示在仅音频呼叫所涉及的端点设备处。
该布置能够有助于在一个端点设备处于不同位置的情况下保留隐私。例如，如果用户恰巧在家用端点设备上在线，并且在家外发生了呼叫，则邀请将不会显示在家用端点设备处。该布置还能够避免在不同(例如，不正确的)位置处对视频呼叫的不注意拾起。
在设备正参与仅音频呼叫的同时，能够接收到呼入的视频呼叫。在一些实施例中，视频呼叫上下文信息能够作为呼入的视频呼叫通知的部分而被包含，并且该信息可以包括呼入的视频呼叫实际上是仅音频呼叫的升级的指示。基于呼叫上下文信息，能够采取各种措施。例如，仅音频呼叫可以无缝地转换到视频呼叫。
该布置允许进行对呼入视频呼叫的更智能的处理。例如，普通的呼入的视频呼叫能够区别于作为当前仅音频呼叫的升级的视频呼叫。
在一些实施例中，可以抓取设备的本地地址簿，以得到联系信息，该联系信息被传送到地址交流中心。交流中心能够指示联系人是否能够参与视频呼叫服务。如果是，则可以在本地存储指示联系人能够参与的指示。后来，在与联系人的仅音频呼叫期间，能够呈现经由视频呼叫服务将仅音频呼叫升级到视频呼叫的选项。
该布置允许在视频呼叫服务中用户参与的升级前确认。升级仅音频呼叫的随后的机会可以在不显示确认用户接口的情况下发生，该确认用户接口能够被绕过，如上所述。而且，预先获得该信息能够实现更平滑的呼叫转换和/或转换是否可能的判定。
如本文所描述的，技术能够支持由视频呼叫服务支持的公用交换电话网(pstn)仅音频呼叫到视频呼叫的呼叫升级，该视频呼叫服务使用非pstn网络来提供视频呼叫功能。
此外，该技术能够支持各种通信应用并且实现跨平台无缝呼叫转换。
能够实现和组合各种其它特征，如本文所描述的。
示例2：实现无缝呼叫转换的示范性的系统
图1是实现如本文所述的无缝呼叫转换的示范性的系统100的框图。
为了上下文的目的，图1示出了通信设备110正参与经由一个或多个网络180与另一(例如，远程)通信设备190的通信。
在示例中，通信设备110包括呼叫控制器120和联系人数据库125。转换配置数据130可以包括与特定呼叫类型一起使用的优选应用。呼叫转换状态137能够跟踪呼叫转换的状态，如本文所述的。
通信设备110能够支持与另一通信设备190的不同呼叫类型的两个同时的呼叫172、174。如图所示，呼叫能够以两个不同的应用为主机，与其对应部分140b通信的电话呼叫应用140a以及与其对应部分145b通信的另一(例如，非电话呼叫)通信应用145a。不同的应用140a、145b可以具有不同的应用类型。如本文所述的，能够支持跨平台操作。呼叫能够传递通过一个或多个网络180。例如，呼叫172、174能够实现在相同或不同的网络180上。呼叫能够传递通过不同的物理或逻辑通信信道。
如本文所述的，两个呼叫172、174之间的转换能够无缝地进行以给予涉及到单个呼叫(例如，呼叫或通信未被中断)的印象。各种技术能够应用于实现无缝呼叫转换，诸如在后台中启动第二呼叫，保持第一呼叫，抑制第二呼叫的音频，禁止将第二呼叫描绘为第二呼叫，以及最终转换到第二呼叫。
虽然在单独的框中显示了各个组件，实际上，组件界限可以变化。例如，组件能够被提供为电话操作系统、呼叫控制器等的部分。在仍实现该技术的同时，其它布置是可能的。
实际上，此处所示的系统，诸如系统100，能够更加复杂，具有额外的功能，更多的通信应用，等等。
系统100以及本文所述的任何其它系统能够与本文所述的任意硬件组件相结合实现，诸如下述的计算系统或移动设备(例如，包括一个或多个处理器、存储器等)。在本文的任意示例中，输入、输出、偏好和应用能够存储在一个或多个计算机可读存储介质或计算机可读存储设备中。本文所述的技术能够通用于操作系统或硬件的细节并且能够在任何各种环境中被应用以利用描述的特征。
示例3-实现无缝呼叫转换的示范性的方法
图2是实现无缝呼叫转换的示范性的方法200的流程图并且能够被实现在例如图1所示的系统中。
方法200典型地是在第一呼叫(例如，用电话呼叫应用)已经被建立之后被执行的。实际上，在进行第一呼叫的同时，显示出呼叫进展用户接口。
在210处，判定到第二呼叫类型(例如，不同于第一呼叫)的第二呼叫的无缝呼叫转换是否可能。该判定能够在进行第一呼叫类型的第一呼叫的同时来进行。如本文所述的，该判定能够基于另一个通信设备的能力、网络条件等。在此时，无需建立第二呼叫。
在220处，响应于判定出无缝呼叫转换是可能的，在通信设备的用户接口中呈现启动无缝呼叫转换的选项。如本文所述的，该选项能够表现为在判定出无缝呼叫转换可能时被启用的图形按钮的形式。选项可以被呈现为呼叫进展用户接口的部分(例如，在进行所述第一呼叫的同时)。
虽然没有显示，该方法可以包括：从另一个通信设备获得同意，如本文所述的。
在230处，响应于用户接口选项的激活，第一呼叫类型的第一呼叫无缝转换到第二呼叫类型的第二呼叫。在保持第一呼叫的同时，能够建立第二呼叫(例如，作为转换处理或事前的部分)。因此，对于通信设备的用户，两个呼叫看起来是一个(例如，不中断)呼叫。典型的场景是将电话呼叫转换到voip呼叫(例如，有视频或无视频)，但是其它转换是可能的，如本文所描述的。
在无缝转换期间，用同一(例如，另一)通信设备来同时保持两个呼叫。
在无缝转换期间，可以使用各种技术。例如，第二呼叫可以被启动，音频被抑制，并且连接被确认。随后，音频可以不受抑制，并且第一呼叫可以停止。
在转换到第二呼叫时，可以使得任何可供第二类型的呼叫使用的特征可用。如本文所描述的，这些特征可以包括视频、屏幕共享，或由调整第二呼叫的通信应用所提供的其它功能。因此，用户接口可以被升级以提供或指示这些特征。
方法200的典型使用情况是通过常规的(例如，线路交换的、蜂窝的，等等)电话呼叫将来自电话呼叫的呼叫转换到因特网语音协议(voip)呼叫。voip呼叫能够支持视频以及其它所需特征。然而，技术能够支持其它呼叫类型之间的转换或者其它方向的转换。
方法200以及本文所述的任何其它方法能够由存储在一个或多个计算机可读介质(例如，存储设备或其它有形介质)中或者存储在一个或多个计算机可读存储设备中的计算机可执行指令来执行(例如，使得计算系统执行方法)。
示例4-实现无缝呼叫转换的示范性的通信设备
图3是示出被配置为判定无缝呼叫转换是否可能的示范性的系统300的框图。在示例中，通信设备305(例如，图1的通信设备110)包括电话呼叫应用340a、一个或多个通信应用345a-349a、联系人数据库325以及网络状态指示符355。
各种技术能够用于判定无缝呼叫转换是否可能。在一些情况下，可以支持各种不同的呼叫类型，并且可以对于不同的呼叫类型单独地做出判定(例如，到视频呼叫的无缝转换可能是不可能的，但是到没有视频的voip的无缝转换可能是可能的)。
如本文所描述的，无缝呼叫转换到特定呼叫类型是否可能的判定能够取决于网络状态指示符355，网络状态指示符355指示网络380上的状况是否将支持呼叫类型。还能够执行对应用注册信息360的校验以判定支持无缝转换的应用是否被注册。对于如本文所述的不同的呼叫类型，可以注册不同的应用。信息360能够指示特定的应用是否支持无缝转换(例如，按呼叫类型考虑)。
该判定还能够取决于另一个通信设备390的能力。一种确定另一个通信设备390的能力的技术是在本地存储信息(例如，与联系人数据库325相关联的)。例如，如果已知设备具备视频能力，则数据库中的条目(例如，基于电话号码或其他地址)可以被注释以指示该设备具备视频能力。通信设备305能够通过与应用服务385通信来周期性地更新本地存储(例如，判定联系人数据库387中的联系人是否匹配本地数据库325中的那些联系人)。
然而，用户可以具有对于特定的通信服务使用同一地址或用户名的多个设备。因此，能够通过与另一通信设备390上的对应部分通信应用345b通信来判定能力。或者，应用服务385能够主动地更新所跟踪设备的状态(例如，它们是否连接，它们具有何种版本的软件，等等)。
在一些情况下，不呈现通信应用345a-349a。或者，不能呈现特定类型的通信应用。在该情况下，虽然无缝呼叫转换不是立即可能的，但能够呈现当前用户接口中的选项，借此能够获得如本文所述的适合的通信应用。因此，随后无缝转换可能是可能的。因此，用户可以有帮助地被告知，其设备上的转换功能是可能的。
类似地，如果应用被呈现但未经配置或激活，则能够呈现当前用户接口中的选项，借此能够对通信应用进行配置或激活。再有，用户能够有帮助地被告知，其设备上的转换功能是可能的。
示例5-实现无缝呼叫转换的示范性的方法
图4是判定无缝呼叫转换是否可能的示范性的方法400的流程图，并且能够在例如图3所示的系统中实现。虽然其他布置是可能的，但是实际上，方法400典型地在经由第一呼叫类型的呼叫与另一设备通信期间被调用。该方法能够被实现以便保留呼叫转换的无缝本质。例如，在无缝转换可能而不需要导航到特殊或分开的用户接口时，在呼叫期间可以呈现简单的用户接口选项。
在本文的任意示例中，(例如，在方法400开始之前，在方法400期间，等等)，能够判定第二呼叫类型的通信应用是否在本地通信设备处可用(例如，安装、注册、被配置为活跃，等等)。如本文所描述的，如果支持特定呼叫类型的多个通信应用可用，则对于该呼叫类型可以存储最爱的或优选的应用。然后，优选的应用能够在整个无缝转换过程中使用。判定还可以包括判定应用是否支持无缝转换(例如，对于特定的呼叫类型)。
如果第二呼叫类型的通信应用不可用，则可以在如本文所描述的当前用户接口中显示选项以获得应用、激活应用，配置应用，等等。否则，响应于判定出第二呼叫类型的通信应用可用，该方法可以继续。因此，确认第二呼叫类型的通信应用在本地通信设备处是否可用。
在410处，判定另一个通信设备是否支持第二呼叫类型的第二呼叫。如本文所描述的，该判定可以通过各种方式来进行。
判定另一个设备是否支持呼叫能够通过查询关于另一个通信设备的本地信息来完成。例如，本地联系人数据库(例如，地址簿)可被检查以查看另一个通信设备(例如，其号码能够经由呼叫者id来找到或被拨号)或者与另一个通信设备相关联的用户(例如，用户在本地通讯录中存储为与当前呼叫的号码相关联)是否具有支持第二呼叫类型的呼叫的服务提供商的账号。如果是，则可以假设另一个设备支持这些呼叫。地址簿能够被增强或补充以指示无缝转换是否可能。诸如平台类型、平台版本、应用类型、应用版本等的信息能够被存储、咨询、或这两者，以判定另一个设备是否能够实现无缝转换。
其它技术包括用另一个通信设备直接检查(例如，查询)。该检查可以通过在本地应用与支持第二呼叫类型的呼叫的远程应用(例如，或应用的后台版本)之间的握手来实现。例如，如果针对特定的呼叫类型指示优选的应用，则可以进行查询以查看另一个设备是否具有替代应用的实例或后台收听者。或者，呼叫控制器或其它软件能够存储该信息来避免不得不调用该应用。
另一技术是查询应用服务(例如，与支持第二呼叫类型的通信应用相关联的服务器)以查看号码或联系人(例如，与另一个设备相关联的)是否被识别出。识别可以包括号码或联系人是否被注册、是否活跃、或这两者。
为利于判定，可以为通信应用定义应用编程接口呼叫，借助于此，本地通信应用能够被查询以提供关于另一个设备是否具有适合能力的答案。输入可以包括呼叫类型、用户标识符(例如，号码、地址等)、或这两者。
在420处，判定当前网络是否能够支持第二呼叫类型的呼叫。例如，如果到一些类型的网络的连接不可用或不稳定，则呼叫类型可能是不可能的。通信设备能够存储一个或多个网络状态指示符或网络连接状况指示符以指示相应网络的状态。该网络可以包括由移动运营商提供的无线数据连接(例如，3g、4g、4glte、wimax等)、wi-fi连接等。能够对于不同的网络存储不同的状态指示符。因此，判定是否能够无缝转换可以包括判定网络连接状况指示符是否指示第二呼叫类型可能。
如果两个判定都指示到第二呼叫类型的呼叫的无缝转换是可能的(例如，另一个设备具有能力且网络将支持第二呼叫类型)，则用于启动转换的选项可以被提供，如本文所描述的。其它状况可并入判定中。
示例6-示范性的呼叫类型
在本文的任意示例中，技术能够支持多个不同的呼叫类型。在同时期的通信设备中几乎普遍存在的一种呼叫类型是标准(移动)电话呼叫(例如，经由移动运营商基础架构交换或管理)，这有时称为“蜂窝电话”，即使基础技术可能不是蜂窝。其它呼叫类型包括voip呼叫，在一些实现方式中，其可进一步划分为仅语音voip呼叫、视频voip呼叫等等。rcs或rcs-e呼叫类型也能够被支持。
该技术能够支持各种指定呼叫类型的方式。例如，由共享某些特性的不同通信应用所调整的呼叫能够被视为同一呼叫类型(例如，skype呼叫以及viber呼叫被视为视频呼叫类型)。或者，这些呼叫能够被实现为不同的呼叫类型(例如，一种用于skype呼叫的呼叫类型，以及另一种用于viber呼叫的呼叫类型)。
实际上，不同的呼叫类型能够通过不同的信道或者在不同的网络上来实现。然而，一些或全部的分支能够共享同一网络基础架构。
示例7-示范性的通信应用类型
除了支持标准电话呼叫的通信应用(“应用”)之外，在本文任意示例中，可以在单个设备上支持各种各样的其它通信应用类型(例如，非电话呼叫应用)。实际上，该通信应用能够由不同(例如，第三)方来提供(例如由除了提供并保持用于电话操作系统、呼叫控制器、电话呼叫应用等的软件的实体之外的实体来提供和保持)。能够支持的示范性的应用类型包括视频应用、voip应用(例如，能够支持视频的)，等等。
实际上，该应用类型能够与发起用于实现通信的软件并且保持利于连接或其它功能的服务器的服务提供商相关联。例如，由微软公司提供的skypetm应用、由vibermediainc.提供的viber应用、由tangome,inc.提供的tangotm应用，以及其它应用是能够被支持的可用应用。由移动运营商提供的各种rcs和rcs-e应用也能被支持。
此外，在特定服务内，可以存在用于不同平台或硬件版本的不同实际应用。例如，skypetm应用可以实现于各种操作系统上。因此，单个服务提供商能够发起跨不同平台(例如，操作系统)实现的通信应用。例如，skypetm通信应用能够被提供在各种源自于微软公司的
因此，在另一设备上的对应部分应用无需为相同的实际应用。不同平台的对应部分应用能够用于建立通信。此处的技术能够将不同的版本和平台进行区分以判定无缝呼叫转换是否可能并且随后相应地实现这些无缝呼叫转换。
应用能够充当呼叫的端点。因此，无缝转换能够从一组端点(例如，电话呼叫应用)转换到另一组端点(例如，在与通信服务相关联的应用家族中的应用)。
示例8-示范性的能力的自动检测
能够实现支持无缝呼叫转换的其它通信设备的安装的通信应用的自动检测，以判定是否与本地设备的应用存在任何交叉。因此，如果两个设备具有共同的支持到第二呼叫类型的呼叫的无缝呼叫转换的应用，则共享的应用可被指定为待使用的一个应用。如果多个应用被共享，则可以咨询用户偏好。在一些情况下，应用是否支持无缝转换可以取决于平台或应用版本。
因此，能够判定的是参与第一呼叫的各方均订购了同一服务。随后能够实现对由服务支持的呼叫类型的无缝提升(upgrade)。
示例9-示范性的实现方式：提升到视频呼叫
本文描述的技术能够被实现以将语音电话呼叫提升到视频呼叫。在该情况下，第一呼叫类型是电话呼叫(例如，音频而没有视频)，并且第二呼叫类型是视频呼叫(例如，典型的经由voip的视频和音频)。指示视频的语言和图标能够用在整个用户接口中以指示使用本文描述的无缝呼叫转换技术可以将呼叫提升到视频。因此，无缝转换从音频呼叫提升到视频呼叫。
因此，例如，作为蜂窝呼叫的部分，当两方正在谈话时，他们能够通过将呼叫无缝转换到视频呼叫类型而将蜂窝呼叫提升到视频呼叫。
该实现方式能够用包括可执行音频呼叫应用和可执行视频呼叫应用的系统来实现。呼叫控制器能够被配置为将呼叫从音频呼叫应用无缝转换到视频呼叫应用。
示例10-示范性的实现方式：提升到voip
本文描述的技术能够被实现以将蜂窝电话呼叫提升到voip呼叫。在该情况下，第一呼叫类型是蜂窝呼叫(例如，音频而没有视频)，第二呼叫类型是voip呼叫。指示voip的语言和图标能够被用在整个用户接口中以指示利用本文描述的无缝呼叫转换技术可以将呼叫提升到voip。因此，无缝转换从蜂窝呼叫提升到voip呼叫。
因此，例如，作为蜂窝呼叫的部分，当两方正在谈话时，他们能够通过将呼叫无缝转换到voip呼叫类型而将voip呼叫提升到视频呼叫。
该实现方式能够用包括可执行电话呼叫应用和可执行voip呼叫应用的系统来实现。呼叫控制器能够被配置为将呼叫从电话呼叫应用无缝地转换到voip呼叫应用。
示例11-示范性的调用无缝呼叫转换的用户接口选项
在本文的任意示例中，用户接口选项能够被呈现，借助于其，能够调用无缝呼叫转换。如本文所描述的，基于该呼叫转换是否可能，该选项能够有条件地被呈现。
图5是示范性的呼叫进展用户接口500的线框并且包括用于启动转换的可激活用户接口元件535。实际上，用户接口元件535能够在不可用时被描绘为禁用的(例如，变灰、变暗等)以及当可用时被描绘为启用的。例如，当网络状条件不支持第二呼叫类型时，用户接口元件能够被描绘为禁用的。
用户接口元件535能够包含指示哪个应用或呼叫类型(例如，第二呼叫的)被调用的描述、文本、徽标、图形或其它信息。例如，为了转换到视频呼叫类型，视频摄像机或类似的图标可以被示出。
在示例中，用户接口元件535被描绘为呼叫进展(例如进行中的呼叫、呼叫中(in-call)或呼叫中(mid-call))用户接口的部分，同时进行第一呼叫。用户接口包括另一方的照片520，以及用于控制当前呼叫(例如，扬声器按钮531、静音按钮532、添加呼叫按钮533、保持按钮534、以及蓝牙按钮539)的各种其它的用户接口元件。实际上，能够示出其它或附加的用户接口元件。
在因为没有安装可应用的通信应用而使得无缝呼叫转换不可用的情况中，仍能够呈现用户接口元件。因此，能够判定用于支持第二类型的呼叫的应用没有安装在通信设备上，并且作为呼叫进展用户接口的部分的选项能够被呈现以启动针对通信设备上的应用的安装过程。
该用户接口元件能够引起对如下事实的注意：可以安装支持无缝呼叫转换(例如，经由图标、图形、文本、颜色等)的应用。用户接口元件的激活能够导致显示出支持的通信应用的列表。列表中的应用的激活能够导致导航到能够获取应用的市场页面。或者，用户接口元件的激活能够导致直接导航到能够购买适当的通信应用的应用市场或市场页面。
虽然用户接口元件535在判定出呼叫转换可能时能够被启用，但是判定无需完全精确。例如，可以是另一方不再订购相关的服务，或者网络条件已经变劣。
实现方式能够支持用于转换的多个用户接口元件535。例如，对于不同的呼叫类型、不同的服务、或不同的呼叫特征(例如，视频、屏幕共享等)呈现不同的元件。或者，单个元件535能够支持多个呼叫类型(例如，经由轻敲并保持、学习用户行为，等等)。
如果需要，能够设定偏好以使转换在可用时自动发生。
示例12-示范性激活
在本文的任意示例中，用户接口元件能够表现为能够由用户激活的显示或暗示的用户接口元件的形式。这些元件能够表现为瓦片、图标、图形按钮、区域、列表中项目、形状、滑块等的形式，其呈现为图形用户接口的部分。用户接口元件可以包括指示功能的文本、图形或颜色。
(例如可激活用户接口元件的)激活能够表现为指示选择(例如，可激活用户接口元件)的用户输入的形式。例如，在支持触摸的系统中，能够接收到轻敲、盘旋或其它触摸姿势。其它系统能够支持点击、盘旋、语音激活、闪烁、眨眼，等等。
示例13-示范性的联系点
在本文任意示例中，能够支持各种号码或地址类型(例如，家庭、移动、工作等)。联系点能够表现为与联系人相关联的号码或地址的形式。例如，联系点可以为联系人的电话号码或用户地址，诸如联系人的工作号码，联系人的移动号码，或者联系人的家庭号码。
当判定使用另一个通信设备的一方的身份时，另一个通信设备的电话号码能够被用于搜索具有匹配的联系点的联系人。然后，可以使用通讯录条目来找到正调整第二呼叫的通信应用的号码或用户地址。例如，电话号码能够被用于确定voip呼叫的用户地址。
示例14-示范性的同意
在本文的任意示例中，在第二呼叫被激活或启动之前，可以给予同意在另一个通信设备处的呼叫转换的机会。例如，当转换到支持视频的呼叫类型时，另一方可能不希望他们的设备发送视频。
能够显示出获得用户同意的用户接口。能够显示出关于呼叫的请求方和类型的信息(例如，“ellen正在请求呼叫现在包含视频。可以吗？”)。响应于接收到同意，转换可以继续。
要获得用户关注，当寻求同意时，可以播放音调或其它音频指示。
如果需要，能够实现同意以使呼叫转换仍在尊重用户意图的同时而发生。例如，呼叫能够提升到voip，但是不包含来自非同意侧的视频。或者，可以将附加的选项呈现给用户。例如，能够实现提升和包含视频的独立的同意。
在一些情况下，可以不支持同意，并且来自被呼叫者侧的体验可能不是被呼叫者侧的无缝转换的体验(例如，呼入的呼叫表现为呼入的呼叫)。
示例15-示范性的转换呼叫的方法
图6是转换呼叫的示范性的方法600的流程图，并且能够被例如实现于图1所示的系统中。实现该方法的系统还可以包括第一呼叫的唯一标识符以及音频抑制逻辑，如本文所描述的。
在620处，从本地通信设备向另一个通信设备启动第二(例如，不同于第一的)呼叫类型的第二呼叫。呼叫可以被置于后台中(例如，不作为分开的呼叫而被呈现给用户)。同时，第一(例如，当前)呼叫保持活跃。例如，如果第二呼叫典型地导致第一呼叫被置于保持，则该功能可被禁止。如本文所述的，第二呼叫的音频能够被抑制。
虽然第二呼叫能够被置于后台中，但是进展的一些指示能够被提供，而无需给予已经做出第二呼叫的印象。例如，在等待连接的同时，能够显示出指示准备转换的选取框、动画、或其它机制。而且，可以禁用启动转换的用户接口元件。
在630处，确认第二呼叫的连接。例如，能够判定是否成功地建立与另一个通信设备的第二呼叫。因此，在保持第一呼叫的同时，建立了第二呼叫(例如，通过第二信道)。如果因为某种原因导致连接未成功(例如，在n秒后)，则过程可能失败，第一呼叫仍然继续。
在640处，响应于确认第二呼叫的连接，可以使得第二呼叫完全活跃。在一些实现方式中，第一呼叫随后可以被置于保持、被终止、被挂断或以其它方式变得不活跃。要实现第一呼叫的去激活，唯一标识符能够被用于标识第一呼叫。为避免不期望的或未经授权的第一呼叫的去激活，可以避免过分简单化的唯一标识符。而是，可以使用更加复杂的(例如，guid等)标识符生成方案来标识呼叫。
作为转换的部分，音频资源能够被切换以便更好地实现第二呼叫类型。例如，如果第二呼叫类型是视频，则音频能够从设备耳机切换到扬声器以利于摄像机的使用。如果蓝音频正在被使用，则音频资源无需切换。
如所描述的，方法600能够在保持涉及单一呼叫的印象的同时实现切换应用(例如，在由一种应用类型支持的呼叫到由不同应用类型支持的呼叫之间的切换)。
当转换到包含视频的呼叫类型时，在本地视频变得对于另一个通信设备可见的间隙期间内，可以在设备上显示本地视频(例如，给用户一个检查外观的机会)。来自第一呼叫的音频在间隙期间内可以继续。
在被呼叫者的设备上，能够以类似的方式实现无缝转换。然而，呼入的呼叫能够被表示为应被处理为无缝转换的部分的特殊呼叫。因此，不是将呼入的呼叫显示为呼入的呼叫，它可以在后台中被处置，并且可以随后无缝地实现到呼入的呼叫的转换。可以如本文所述那样获得同意。
在一些情况下，网络条件会变劣，提示转换回第一呼叫的呼叫类型。该转换可以如本文所述那样无缝地进行。可能不能获得或者不需要(例如当从呼叫中去除视频时)另一方的同意。
示例16-示范性的音频抑制
在本文的任意示例中，第二呼叫的音频在变得活跃之前可以被抑制。该技术能够避免音频、回声等的重合。能够通过呼叫控制器或其它组件来控制呼叫抑制。
示例17-示范性的用户接口顺序
在本文的任意示例中，用户接口能够在原用户接口(例如，呼叫进展ui)和支持第二呼叫的通信应用的用户接口之间定序。在完成转换时，表现为第一呼叫变换成第二呼叫。第二呼叫类型的功能随后被呈现以供在通信设备处使用。
在另一设备处，能够显示征得同意的请求，此后用户接口转换到支持第二呼叫。
示例18-示范性的呼叫转换状态
在本文的任意示例中，呼叫转换状态能够被存储以帮助调整转换过程。该状态能够与呼叫状态联合地实现或者实现为呼叫状态的部分。例如，状态可以指示“未实现”、“不活跃”、“启动第二呼叫”、“完成”，等等。
类似地，如本文所述，可以存储网络状态指示符。
示例19-示范性的注册通信应用的方法
图7是注册通信应用以实现无缝呼叫转换的示范性的方法700的流程图，并且能够实现在例如本文所述的任意通信设备中。
在720处，在通信设备上注册通信应用。例如，操作系统或其它控制软件能够接收到：正在安装通信应用的通知，它支持一种或多种呼叫类型的通知，以及它支持无缝呼叫转换的通知。
在730处，响应于注册，通信设备的配置被更新。例如，通过将通信应用添加到列表中，能够更新支持特定呼叫类型的通信应用的列表。还能够存储用于特定呼叫类型的优选的通信应用。
在740处，作为注册的结果，在通信设备的用户接口中呈现无缝转换到通信应用所支持的类型的第二呼叫的选项。如本文所述的，该选项可以被有条件地呈现或者有条件地启用(例如，取决于另一个通信设备的能力、网络条件，等等)。
因此，在支持第二呼叫类型的应用的安装过程中，应用可被注册为当经由第二呼叫类型进行无缝转换时使用。随后，指示第二呼叫类型或应用的用户接口元件能够响应于注册而被呈现。
示例20-注册的通信应用
图8是存储优选的通信应用的表格800的框图并且能够被存储为配置数据的部分(例如，转换配置数据130)。表格800能够存储指示应用830a以及应用是否优选830b的条目830。表格可以在通信应用注册时被构建和更新。然后，当在呈现用于无缝呼叫转换的用户接口选项时判定是否显示以及显示哪个应用时，可以咨询表格。例如，如果应用3是优选的应用，则当用户接口选项被激活时该应用可被指示为所调用的应用(例如，通过文本、图形、徽标等)。
其它信息(例如，文本、图标、徽标或其它图形)也能够被存储在表格中或者在表格中引用并且被显示为用户接口元件的部分(例如，作为呼叫进展ui的部分)。表格能够显式地指示应用是否支持无缝转换，或者表格可局限于这些通信应用。为无缝转换的目的，可以设定分开的偏好。因此，如果存在多个支持特定呼叫类型的应用，则子集可以支持无缝转换。如果在子集中存在多个应用，则通信应用中特定的一个通信应用可被指定为优选的。
虽然示例显示出单一呼叫类型的通信应用，但是可以支持多种呼叫类型。不同的应用能够被指示为对于不同呼叫类型是优选的。
示例21-示范性的通信应用的配置
图9是用于选择呼叫类型的优选应用的示范性的设置用户接口900的线框。在示例中，用于选择特定类型的呼叫(例如，视频)的优选的通信应用的用户接口被显示出。能够支持对于其它或附加的呼叫类型的用户接口。
在框930中可以显示出优选的应用。如果多于一个的通信应用可用，则框930可以是允许选择不同应用的下拉框。如本文所描述的偏好随后可以相应地被更新。
能够显示出说明性的文本940以描述选择特定应用的结果(例如，选定的应用将被显示在呼叫进展ui中)。如果不安装应用，则接口能够显示文本940，指示获得支持的通信应用的结果。例如，文本可以描述具有视频的益处，无缝呼叫转换的可用性，等等(例如，“你知道你能够借助提升应用将呼叫提升到视频呼叫吗？”)。
用户接口900能够显示出用户接口元件950，其允许导航到能够获得如本文所描述的支持应用的应用市场。
可选的技术能够允许应用将其自身设定为对于特定呼叫类型的优选的应用。应用无需对设置有直接访问权。例如，在注册期间，应用能够访问api(例如，规定呼叫类型、应用标识符，等等)以将其自身设定为优选的应用。为防止对配置的暗中变改变，对话框可以被显示以确认改变(例如，“使得应用x是你的优选的视频应用？是/否”)。应用能够查询api以查看其是否已经是优选的。如果是，则不需要改变。
示例22-示范性的优点
如本文所描述，用户能够容易地利用他们设备的能力，而无需学习新的过程或者甚至初始地知道这些能力存在。
示例23-示范性的呼叫升级
在下面的示例中，特定类型的呼叫转换(例如，仅音频呼叫到视频呼叫)用于阐明有时称为“呼叫升级”的技术。该呼叫升级可包括无缝呼叫转换(例如，为无缝呼叫升级)。在其它情况下，升级可以不是在无缝的情况下实现。可以通过利用本文所述的任意技术在保持单个统一的呼叫发生的印象的同时从仅音频呼叫转换到视频呼叫来实现无缝。例如，不是提供仅音频呼叫已经结束的明确指示(例如，仅音频呼叫的“结束的”消息)，该指示可以被抑制或者未被呈现。此外，与仅音频呼叫相关联的呼入的视频呼叫(即，为仅音频呼叫的升级)能够被以特殊方式处置，而不是将其呈现为呼入的视频呼叫。例如，可以在保持当前的仅音频呼叫的音频的同时显示如所述的通知。不是将呼入的视频呼叫呈现为分开的呼叫，其可以被呈现为将视频添加到当前呼叫中的机会，从而保持单一呼叫正在发生的印象，即使涉及到不同的技术、网络类型、客户端应用等。
虽然使用了从仅音频呼叫升级到视频呼叫的示例，在本文的任意示例中可以支持其它类型的升级(例如，从视频呼叫升级到全息呼叫，等等)。
示例24-示范性的精确呼叫升级系统
图10是实现精确呼叫升级的示范性的系统1000的框图。在示例中，两个通信设备1010和1020a正在进行仅音频呼叫(例如，通过公用交换电话网、蜂窝呼叫，等等)。为了说明的目的，设备1010有时被称为“发起方端点设备”，因为它是升级呼叫的邀请发起的设备。通信设备1020a有时称为“接收方端点设备”，因为它是接收升级呼叫的邀请的设备。一个或多个其它的通信设备1020b是关联于与端点设备1020a相同的用户的且可能当前在线(例如，与服务器1085通信或者加电且激活的)且能够参与视频呼叫的其它端点设备。然而，如本文所描述的，升级邀请不被发送到这些设备，因为它们当前未参与与发起方端点设备1010的呼叫。
如图所示，发起方端点设备1010能够存储联系人信息1025并且执行视频应用1045a。视频应用1045a能够处置视频呼叫并且能够与服务器1085通信以判定哪些接收方端点当前正参与仅音频呼叫。替代地，能够通过系统的另一部分来执行这些处理，或者视频应用1045a可以简单地咨询存在信息1030。
转换引擎1047a能够处置如本文所述的转换和邀请功能。实际上，转换引擎1047a可以如所示为分开的，为视频应用1045a的部分，为较大的通信应用的部分，为操作系统的部分，等等。转换引擎1047a可以运行以将呼叫升级呈现为单个呼叫，即使涉及到两个呼叫。
在发起方端点设备1010内，能够存储与接收方用户相关联的多个设备的存在信息1030。该信息可以指示多个接收方端点1020a-b中的哪些接收方端点当前正在参与仅音频呼叫。该信息可以指示端点设备1020a-b的网络地址并且特殊地指示端点设备1020a-b中的仅音频呼叫中所涉及到的端点设备1020a。该信息可基于从接收方端点设备1020a公布的信息，如本文所述的。信息1030因此能够表现为参与仅音频呼叫(例如，当前的仅音频呼叫)的设备特定指示的形式。设备特定标识符或呼叫特定标识符能够充当设备特定指示。
虽然使用了术语“存在信息”，但是信息可以表现为有限存在信息的形式(例如，仅关于是否设备参与仅音频呼叫或者当前的仅音频呼叫被暴露的信息)。其它存在信息(例如，位置、最后活跃时间，等等)可保持不暴露。
如图所示，设备1010和1020a-b能够经由各种网络1080中的任一种来互连，包括所述的公用交换电话网、因特网、私人网络等中的一种或多种。服务器1085也可以如此连接。
在一些场景中，可能期望涉及服务器1085，其能够跟踪存在信息以及端点数据库1087中的其它数据。例如，服务器1085能够存储关于与接收方用户名相关联的多个接收方端点1020a-b的信息。因此，服务器能够充当设备之间的联络。例如，服务器能够调整邀请以使单个接收方端点设备被邀请来升级仅音频呼叫。然而，在一些情况下，服务器1085可以保持不参与，允许设备协商连接和呼叫升级。
如图所示，参与仅音频呼叫的接收方端点设备1020a可以包括类似于其它设备1010的视频应用1045b和转换引擎1047b。端点设备1020a还能够将其存在信息公布到网络1080，以便直接地或者通过服务器1085由端点设备1010消费。例如，服务器1085能够接收端点设备1020a参与仅音频呼叫且报告该信息给发起方设备(例如，以及其它设备)的指示。接收方端点1020a可以被配置为对呼叫升级作出响应并且调整从仅音频呼叫到视频呼叫的无缝呼叫转换(例如，结束仅音频呼叫，而不为仅音频呼叫呈现结束消息，等等)。
示例25-示范性的精确呼叫升级方法
图11是能够在本文所述的示例中实现的实现精确呼叫升级的示范性的方法1100的流程图。
在示例中，方法1100在特定的接收方端点设备与发起设备之间的仅音频呼叫期间被执行1110。接收方端点设备与在多个端点设备(即，包括接收方端点设备)(例如，能够参与视频呼叫)处当前活跃(例如，在线、登录，等等)的用户标识符相关联。
在1120处，接收到将仅音频呼叫升级到视频呼叫的请求。例如，在显示用户接口，发送消息，或其它技术之后，能够接收到邀请接收方用户升级仅音频呼叫的指示(例如，“添加视频”)。
在1130处，响应于该请求，仅接收方端点设备(即，参与仅音频呼叫的接收方端点设备)响铃。其它设备不响铃(例如，未收到邀请，不显示，或者两者)。例如，升级仅音频呼叫的邀请能够仅被发送到特定端点设备或者在特定端点设备处显示。
示例26-示范性的精确呼叫升级方法
图12是从不同设备的视角实现精确呼叫升级的示范性的方法1200的流程图，其能实现于本文所描述的任意示例中并且能够用于实现图11的方法1100。在示例中，客户端端点设备1210、1220参与仅音频(例如，公用交换电话网、蜂窝呼叫等)呼叫1230、1240。两个设备1210、1220因此是活跃的。然而，如本文所述的，与接收方设备1220相关联的用户可能具有活跃或不活跃(例如能够参与视频呼叫)的一个或多个其它设备。例如，用户可以使其它设备注册通信服务、作为其它设备上的视频呼叫服务的用户而被登录，或两者。
在1250处，在参与仅音频呼叫的同时，接收方客户端端点设备1220公布了参与仅音频呼叫的设备特定指示。如本文所述的，该指示能够指示设备1220的唯一设备地址、仅音频呼叫的唯一呼叫标识符，或两者。
而且，在参与仅音频呼叫的同时，发起方客户端端点设备1210接收哪个端点(例如，1220)参与仅音频呼叫的指示。如本文所述的，能够直接地或者通过中介(如服务器)接收该指示。该指示能够在接受升级呼叫的请求之前被接收到。因此，设备特定指示能够在升级邀请被发送或接受之前被接收到。如本文所述的，该功能能够由诸如服务器的中介来处置。
能够存储与用户标识符相关联的多个端点设备的指示。能够特殊地指示参与仅音频呼叫的特定的端点设备。
在1270处，请求(例如，经由用户接口)被显示在发起方设备1210处以将仅音频呼叫升级到视频呼叫。例如，能够呈现将仅音频呼叫升级到视频呼叫的用户接口选项(例如，用户接口元件)，并且用户能够如本文所述，激活诸如图形按钮的用户接口元件(例如，在进行仅音频呼叫的同时的呼叫进展用户接口中)，使得设备接收到请求。
在1280处，响应于该请求，发起方端点设备1210将邀请仅发送到接收方的特定端点设备(例如，仅对于当前参与与发起方设备1210的仅音频呼叫的设备1220的精确邀请)。例如，能够使用接收方的实际网络设备地址，或者可以询问服务器来发送邀请，其中服务器处置精确邀请功能。与接收方端点设备1220的用户相关联的其它设备1220未被发送邀请(例如，该过程省去向其它设备发送将仅音频呼叫升级到视频呼叫的邀请)。
在1290处，接收方端点设备1220接收升级呼叫的邀请。
如本文所述的，如果接受了邀请(例如，从接收方端点设备接收到接受)，则可以将仅音频呼叫升级到视频呼叫。该升级可以表现为从仅音频呼叫到视频呼叫的无缝呼叫转换的形式。可以在接收到接受之前做出关于哪个端点参与仅音频呼叫的判定。
示例27-示范性的其它精确呼叫升级方法
图13是从不同设备的视角实现精确呼叫升级的另一示范性的方法1300的流程图，其能够被实现于本文描述的任意示例中并且能够被用于实现图11的方法1100。在示例中，客户端端点设备1310、1320参与仅音频(例如，公用交换电话网、蜂窝、voip等)呼叫1330、1340。两个设备1310、1320因此是活跃的。然而，如本文所述的，与接收方设备1320相关联的用户可以具有活跃的或不活跃的(例如，并且能够参与视频呼叫的)一个或多个其它设备。例如，用户可以使其它设备注册通信服务、作为其它设备上的视频呼叫服务的用户而被登录，或两者。
在1370处，在发起方设备1310处接收到请求(例如，经由用户接口)以将仅音频呼叫升级到视频呼叫。例如，将仅音频呼叫升级到视频呼叫的用户接口选项(例如，用户接口元件)能够被呈现，并且如上所述，用户能够激活诸如图形按钮的用户接口元件(例如，在进行仅音频呼叫的同时，在呼叫进展用户接口中)。
在1380处，响应于请求，发起方端点设备1310发送邀请到接收方1320的特定端点设备以及与接收方端点设备1320的用户相关联的其它设备。如本文所述，如果需要，该特定的端点设备1320能够避免需要公布其参与仅音频呼叫的事实，但是邀请仍能局限于特定的端点设备1320。
在1390处，在设备1320和其它设备处接收到升级呼叫的邀请。能够判定(例如，在设备1320处本地)呼入的视频呼叫是将当前的仅音频呼叫升级到视频呼叫的升级请求。基于设备1320是否是参与被升级的仅音频呼叫的设备，提升呼叫的邀请被选择性地显示1395。例如，与呼入的呼叫通知相关联的呼叫标识符或用户标识符能够被检查以判定呼入的视频呼叫是否是当前的仅音频呼叫的升级。如果判定出呼入的视频呼叫是当前的仅音频呼叫的升级，则能够呈现邀请以供接收方用户考虑，如本文所述的。
否则(例如，呼入的呼叫是在不同设备处发生的仅音频呼叫的升级)，呼入的呼叫可以被避开。例如，邀请可被忽略、抑制等(例如，在与设备1320的用户相关联的其它设备处)。通过这种方式，仅在适当的端点设备处显示邀请。
示例28-示范性的服务器参与
在本文的任意示例中，如由设备执行的所描述的功能能够由中介(例如，服务器)执行，而不是由在设备处完成的处理执行，或者是与在设备处完成的处理一起执行。此外，当使用术语“从”或“到”时，除了直接通信之外，这些术语可以涵盖中介参与或者与设备联合(例如，配合)工作的情形。例如，当“从”设备接收到通信时，该通信可以传递通过服务器。
此外，能够支持冗余，由于通信能够在无服务器参与的情况(例如，在对等场景中)、有服务器参与的情况，或两者的情况下发生。在单一通信中，场景可以根据诸如网络状况、信号强度、带宽等的各种因素而改变。
示例29-视频呼叫服务
在本文的任意示例中，视频呼叫服务能够支持服务中的参与者之间的视频呼叫。实际上，视频呼叫服务可以是还支持其它(例如，语音、voip等)呼叫类型的服务，无论是通过pstn还是非pstn网络提供的。
示例30-示范性的用户标识符
在本文的任意示例中，用户标识符能够用于标识用户(例如，独立于服务)。例如，能够使用姓名、电话号码、设备标识符、网络地址、电子邮件地址、用户名或用户的其它记号。
在本文的任意示例中，服务用户标识符能够用于标识服务(例如，视频呼叫服务等)的用户或订购者。这些标识符能够表现为各种形式并且可以包括姓名、电话号码、设备标识符、网络地址、电子邮件地址、服务的用户名、或用户的其它记号。
这些标识符之间的映射能够如本文所述用于判定特定用户是否是特定服务的订购者。
示例31-示范性的邀请
在本文的任意示例中，升级呼叫的邀请可以表现为呼入的视频呼叫通知的形式。如本文所述，在通知中可以包括附加的信息以将其区分为升级邀请而不是普通的呼入的视频呼叫。能够支持其它形式的传送升级呼叫的请求的邀请。
示例32-示范性的视频呼叫上下文信息
图14是存储包括升级指示1420在内的视频呼叫上下文信息1410的示范性的数据结构1400的框图。视频呼叫上下文信息1410能够由发起设备或服务器发送而充当升级请求通知。实际上，信息1410能够被包括而作为呼入的视频呼叫的部分。视频呼叫上下文信息1410能够用于将呼入的呼叫表示为被处理为如本文所述的无缝转换的部分的特殊呼叫。
如图所示，升级指示1420能够指示呼入的视频呼叫是升级请求的结果，从而将其与普通的呼入的视频呼叫区分开。上下文信息因此能够从指示1420中收集。例如，能够得出接收通知的被通知设备已经处于与发起设备的仅音频呼叫中的结论。信息1410还能够指示已经在进展中的呼叫的类型(例如，仅音频、视频等)，根据需要允许多阶段升级。
标识符1440能够与呼叫通知1405相关联以指示与呼入的呼叫相关联的用户标识符或呼叫标识符。可选地，标识符1440可以与呼叫上下文信息1410一起被包含。
其它指示可被包含而作为上下文信息1410的部分。例如，可以包含无缝能力指示1430以指示呼叫的无缝升级是否可能(例如，发起设备、接收方设备或两者是否能够实现到视频呼叫的无缝呼叫转换)。
如本文所述的，升级指示1420能够通过指示视频呼叫的上下文来起到各种作用。例如，它可以充当呼叫是升级的标志，并且基于指示1420是否确实指示呼叫是仅音频呼叫的升级来采取其它措施。
实际上，在包括操作为进行公用交换仅音频呼叫的呼叫控制器的通信设备中，呼入视频呼叫处理器能够运行以接收呼叫通知1405并且基于指示的存在而经由呼叫通知的检验以及从仅音频呼叫到视频呼叫的无缝转换而判定呼入视频呼叫是仅音频呼叫的升级。呼叫控制器随后可以结束仅音频呼叫(例如，不提供仅音频呼叫已结束的明确指示)。
接收到呼叫通知1405能够使得接收设备基于存储在呼叫通知1405中的视频呼叫上下文信息1410的检验而参与仅音频呼叫的无缝升级。升级指示1420能够使得上下文引擎指示呼入的视频呼叫是当前仅音频呼叫的升级。升级随后能够被调整，如本文所述。
另外，接收方能够提供状态信息，该状态信息能够用于构建呼叫上下文信息并且决定如何以及是否参与呼叫升级。例如，接收方能够提供诸如以下的信息：端点是否登录、数据连接是否存在、当前连接是否将支持高品质视频呼叫、是否需要升级等。该信息可以在升级之前公布到发起方、服务器或两者以避开或增强升级处理。
示例33-示范性的视频呼叫上下文处理方法
图15是在呼叫升级场景中处理视频呼叫上下文信息的示范性的方法1500的流程图，并且能够在本文的任意示例中与视频呼叫上下文信息合并使用以改进升级处理。方法1500能够在仅音频呼叫期间(例如，在设备参与与发起设备的仅音频呼叫的同时)执行，如本文所述，在一些情形下该仅音频呼叫随后升级到视频呼叫。
在1510处，接收到视频呼叫上下文信息。例如，能够接收到视频呼叫上下文信息1410或类似信息。如所述，视频呼叫上下文信息可以包括视频呼叫是否是仅语音呼叫的升级的指示。该信息能够被接收而作为呼入的视频呼叫通知(例如，来自发起设备)的部分。
在1520处，检验视频呼叫上下文信息。例如，通过检验呼叫升级指示能够判定呼入的呼叫是否是仅语音呼叫的升级。虽然能够使用标志，但是能够支持指示升级类型等的更丰富的上下文。还能够判定是否支持无缝升级。根据实现方式，如果呼叫升级指示表明呼入的呼叫是升级，则能够假设呼入的视频呼叫是当前呼叫的升级，或者能够使用将当前的仅音频呼叫链接到呼入的视频呼叫的明确信息(例如，用户标识符、呼叫标识符等)。如果包含了该信息，则能够检验以验证呼入的视频呼叫从同一用户或当前进展中的呼叫发起。
在1530处，响应于判定出视频呼叫上下文信息指示呼入的视频呼叫是仅音频呼叫的升级，对于呼入的视频呼叫采取措施。
因此，接收方、服务器或两者能够对视频呼叫上下文信息进行作用以实现呼入呼叫的处理从而将其与常规(例如，新的视频)呼叫做差别处理。如果呼叫被指示为升级，则支持各种动作。例如，响应于服务器检测到呼叫是仅语音呼叫的升级，能够调用本文所述的精确升级。
不是将呼叫处理为新的视频呼叫，能够实现如本文所述的无缝升级。例如，如本文所述，能够调整仅音频呼叫到呼入视频呼叫的无缝升级。因此，视频呼叫能够呈现为仅音频呼叫的持续。例如，仅音频呼叫可结束，而不明确地表明仅音频呼叫已结束(例如，对于仅音频呼叫不呈现“结束”消息)。然而，还能够检验无缝升级是否可能的指示。如果为否，则仍能够实现升级以及其它特征(例如，通过明确地结束当前的仅音频呼叫且升级到视频呼叫)。
例如，一些设备(例如，cdma等)不能同时参与仅语言呼叫和视频呼叫。因此，所采取的措施可以是检查设备的能力以及然后相应地升级呼叫。
一般地，当另一呼叫被拾取时，当前呼叫结束；然而，在无缝升级的情况下，能够有差别地处置呼叫结束处理。例如，响应于检测到升级指示表明升级，仅音频呼叫不被显示为结束，即使呼叫最终结束。
在升级的情况下，能够呈现用户接口选项，借此被邀请的用户能够拒绝(例如，升级是在用户选择，而不是自动的)。接收方设备能够显示已经接收到升级请求的指示(例如，“<姓名>正请求将呼叫升级到视频”)。响应于用户接口(例如，显示“添加视频到呼叫”的图形按钮)选项的激活，升级能够继续(或者被阻止)。
在一些情况下，自动回答功能可能是活跃。然而，在呼入的呼叫是升级的情况下，可能不期望这种自动回答功能。因此，响应于检测到升级指示，所采取的措施可以是自动回答功能可以被禁止(例如，即使自动回答功能是活跃，呼入的视频呼叫也不被回答)。
可以根据需要基于升级指示的检测来采取其它措施。例如，能够生成用于呼入呼叫的上下文，并且该生成可以包括咨询升级指示、无缝呼叫转换指示能力或可供用作视频呼叫通知或其它的部分的任何其它信息。升级指示能够提供允许以更加智能的方式进行呼叫处置决策的更丰富的呼叫上下文。例如，如果在不能实现升级的设备处接收到指示升级的呼叫通知(例如，当前没有进展中的音频呼叫，视频功能不可用，等等)，则可以忽略呼叫通知，能够呈现错误消息，等等。
如果呼叫上下文指示无缝升级不可能，则措施可以包括调整从仅音频呼叫到视频呼叫的转换，无论转换是否是无缝的。
示例34-示范性的共享服务参与
在本文任意示例中，能够在通信设备中在本地确定和记录联系人对共享服务的参与。例如，如果联系人能够连接到本地支持的服务(例如，两个用户订购或能够参与相同的服务)，则能够在本地地址簿或其它中进行记录。例如，在视频呼叫服务的情况中，能够判定本地地址簿中的联系人是否支持视频呼叫服务(例如，支持应用被安装，订购是当前的，等等)。
如本文所述的，能够在呼叫升级之前确认其它方的参与。通过这种方式，在仅音频呼叫期间，可以快速地判定呼叫升级(例如，到所支持的服务)是否可能。在一些情况下，该过程称为“短路”，因为能够避免将联系人注册为经由前后交换(back-and-forthexchange)支持的联系人的通常的过程。相反，联系人简单地表现为能够参与共享服务。
示例35-示范性的升级前联系人参与确认系统
图16是实现升级前联系人参与确认的示范性的系统1600的框图并且能够用于本文的任何示例。
在示例中，发起方端点设备1610将多个联系人的通讯录1625(例如，有时称为“地址簿”)和关联信息本地存储在设备1610中。实际上，通讯录1625能够与存储在云(例如，经由网络1680)中的信息镜像或以其它方式同步。从设备1610的视角看，联系人1625可以视为存储于本地。
在示例中，设备1610还包括支持视频呼叫的视频应用1645以及能够调整仅音频呼叫与视频呼叫之间的转换的转换引擎1647。
设备1610能够连接到(例如，与其通信、查询等)地址簿交流中心1685，地址簿交流中心1685存储参与设备1610所支持的服务的那些用户的标识符1687。例如，视频呼叫服务可以是可用的，其与视频应用1645联合操作。视频服务标识符1687可以是本文所述的视频服务标识符等中的任一个，以标识服务的用户。标识符1687或其它指示的存在能够用于确认用户或设备对于服务的参与。交流中心1685可以集成到应用服务(例如，图3的服务385，其可以提供视频呼叫服务等)中或者是分开的服务。
虽然显示为距端点设备1610远，实际上，地址簿交流中心1685能够在本地实现，通过该地址簿交流中心能够执行本地查找。例如，可以针对特定于充当交流中心的视频服务应用的本地存储的地址簿来检查全局地址簿中的联系人。
地址簿交流中心能够配置为响应于接收到联系人的用户标识符而提供用于视频呼叫服务的视频服务标识符。例如，地址簿交流中心1685能够接收到电话号码或电子邮件地址，并且交流中心1685能够提供电话号码或电子邮件地址是否与参与服务的用户相关和/或相关联设备是否支持服务的指示。
设备1610能够配置为将关于如本文所述的存储的通讯录1625中的特定联系人的信息周期性地传送到地址簿交流中心1685并且在响应中接收联系人是视频呼叫服务的参与者的确认。
实际上，当在设备1610与交流中心1685之间交换信息时，能够使用安全和优化技术以保留隐私，提高性能，等等。
在呼叫升级方案中，将仅音频呼叫升级到视频呼叫的选项的呈现可以局限于由地址簿交流中心1685根据标识符1687被指示为参与该服务的那些通讯录1625。该信息还能够通过其它方式获得(例如，经由设备之间的直接邀请，通过服务器的邀请，等等)。
如本文所述的，经由交流中心1687的咨询在升级之前(例如，在启动呼叫之前)能够更新通讯录1625。例如，通讯录1625能够在空闲时间等进行更新。
端点设备1610可被配置为在经由视频呼叫服务呼叫升级到视频呼叫的期间对于参与的联系人绕过确认用户接口。
示例36-示范性的升级前联系人参与确认方法
图17是实现升级前联系人参与确认的示范性方法1700的流程图并且能够在本文的任意示例中与联系人地址簿组合使用以改进升级处理。
如本文所述，方法1700能够在空闲时间1710中执行。因此，能够做出通信设备空闲的判定，并且响应于该判定，该方法能够被执行。例如，该方法可以在没有进行呼叫时执行，当数据连接空闲时执行，或者在对联系人的呼叫被升级或启动之前的任何其它时间执行。随后，用于升级呼叫的选项能够如所述呈现。
实际上，等待直至呼叫启动而执行该方法会导致一定的升级延时，但是该技术可能仍在一些情况下是期望的。方法1700能够被规划成周期性执行，使得地址簿信息趋于为当前的。
在1720处，抓取通讯录(例如，本地地址簿)。例如，可以逐条地或者根据一定的优先级(例如，首先查看近期添加的联系人，等等)来查验通讯录。标识联系人的信息(例如，电话号码、电子邮件地址、用户名等)能够被确定为联系人的标识符。对于存储在通信设备处的多个联系人，能够读取联系人的联系信息。
在1730处，联系信息(例如，用户标识符等)能够传送到地址交流中心。例如，标识符能够作为关于标识符是否是特定服务(例如，视频呼叫服务)的参与者的查询的部分而被发送到交流中心。信息可被加密、散列化或以其它方式混淆以保留隐私。实际上，电话号码或电子邮件地址能够被用于用户标识符并且被发送到联系人的地址交流中心。
在1740处，如果联系人是服务的参与者，则对于参与的联系人，接收参与确认。例如，能够接收到能够用于连接到用户或设备的肯定指示或(例如，联系人的视频呼叫服务的)用户标识符指示。在联系人不是参与者的情况下，不提供回答或否定响应。从交流中心的视角，作为判定与呼入的查询相关联的用户是否是服务的参与者的结果，发送该信息。还能够提供服务连接信息(例如，足以开始视频呼叫)。
在1750处，响应于接收到联系人与服务的参与者相关联的确认，联系人被表示为参与者(例如，在地址簿中)。例如，能够更新联系信息以指示联系人是参与者。指示可以本地存储，其指示参与的联系人是服务的参与者。还能够存储服务连接信息如用户名、标识符、网络地址等。
本地存储该指示可以包括对于实现视频呼叫服务的通信设备处的应用所能访问的联系人，创建实体记录。足以借助视频呼叫服务而开始到参与的联系人的视频呼叫的信息(例如，用于视频呼叫服务的参与联系人的用户标识符)能够被置于实体记录中。
随后，当在与经过确认的参与者的呼叫中时，响应于判定出联系人是参与者的判定(例如，响应于存储的指示)，能够呈现升级呼叫的选项，如本文所述的。例如，在与参与联系人的仅音频呼叫期间，能够呈现经由服务将仅音频呼叫升级到视频呼叫的选项。所获得的连接信息(如果有的话)能够被用于升级呼叫。对于不是参与者的那些联系人，选项可被省略或禁止(例如，不呈现，变灰，等等)。
因为联系人被表示为视频呼叫服务的参与者，通常的确认用户接口可由于确认而被绕过。例如，不是呈现如下的确认对话：用户能够借以确认联系人应当被更新以表明联系人参与服务，该对话可被绕过。如果期望，能够维持用户偏好。因此，能够接收到这样的用户指示：对于信息已经存储在通信设备处的联系人，应绕过确认用户接口。
该布置可以是有帮助的，因为可以假设根据联系人的信息出现在本地地址簿中的事实，出现在本地地址簿中的联系人应当被授权而经由设备通信。
示例37-示范性的确认用户接口
在本文的任意示例中，对于视频呼叫服务的参与者，能够呈现确认用户接口。例如，该用户接口可被呈现作为将用户集成到视频呼叫服务中而使得它们被设备处的视频呼叫应用识别(例如，它们可进行视频呼叫)的技术。
例如，能够呈现该用户接口作为将用户添加到地址簿或服务特定地址簿的部分。用户接口一般能够充当实现或接收对联系人的视频呼叫的先决条件。
如本文所述，在一些情况下，可以绕过该确认用户接口。
示例38-示范性的地址簿
在本文的任意示例中，地址簿可以是用于通信设备的全局地址簿。该地址簿可以由操作系统或其它允许接入公用交换电话网呼叫、电子邮件、文本消息、视频呼叫等的调整实体来维护。
实际上，该地址簿可以是来自各种源(例如，社交媒体、电话呼叫、电子邮件、文本消息等)的信息的集合体。因此，地址簿能够用于代理以判定是否与联系人有关系(例如，他们是否连接在社交图中)。能够假设，出现在地址簿中的那些用户是用户希望参与与其的通信的联系人。可以提供用户偏好来根据期望而限制该假设。
示例39-示范性的呼入升级确认
在本文的任意示例中，能够提供用户设置，通过该用户设置，用户能够指示是否期望实现(例如，发送或接收)呼叫升级，或者在何种情况下期望实现该呼叫升级。例如，用户可以决定仅当连接到wifi时、仅在某些设备中时等才期望升级。
该用户设置(例如，“允许升级”、“允许视频添加邀请”、“仅当连接到wi-fi时才允许呼入视频添加”等等)能够经由给予选项以供用户选择的用户接口的呈现来控制。随后能够在设备处实现选定的选项的接收(例如，通过在发起设备处不呈现选项，在接收设备处拒绝邀请，指示接收方设备不首先接受邀请，等等)。
示例40-示范性的仅音频呼叫
在本文的任意示例中，仅音频呼叫可以包括公用交换电话网(例如，仅音频)呼叫(例如，蜂窝电话呼叫、电路交换电话呼叫，等等)。因此，该呼叫可以升级到视频呼叫，如本文所述。该视频呼叫能够得到使用非pstn网络的视频呼叫服务(例如voip等)的支持。因此，能够在公用交换电话网呼叫的熟悉上下文中提供优良的用户体验。
示例41-示范性的呼叫升级实现方式
图18、19、20和21是示出了借以实现呼叫升级的技术的实现方式的呼叫处理的流程图。在示例中，在与第一用户相关联的第一设备处的电话操作系统框架1810、用于第一设备的全局地址簿1811、平台特定呼叫应用客户端组件1812、以及跨平台客户端组件1814与后端(例如服务器)组件1815通信，该后端组件1815与关联于第二用户的第二设备处的跨平台客户端组件1816、平台特定呼叫应用客户端组件1817、以及第二设备处的电话操作系统框架1819通信。
电话操作系统(例如，平台)可以在不同设备上为不同的，以支持跨平台通信。呼叫应用能够如本文所述的支持视频呼叫，并且后端组件1815可以是如本文所述的视频呼叫服务的部分。虽然操作系统可以表现为微软公司的windowsphone操作系统、苹果公司的ios操作系统、谷歌公司的android操作系统以及其它形式、或类似形式，但是该技术能够跨广泛的多种平台而被应用。广泛的多种呼叫应用，诸如，由微软公司提供的skypetm应用、由vibermediainc.提供的viber应用、由tangome，inc.提供的tangotm应用、以及其它应用能够被支持。在windowsphone实现方式的情况中，地址簿1811能够表现为peoplehub的形式，但是在其它平台上类似的实现方式是可能的。类似地，在skypetm的实现方式中，跨平台客户端组件1814、1816能够表现为corellib系统的形式。
流程图显示出示范性的呼叫升级场景中的通信。在1820处，建立蜂窝呼叫(例如，通过公用交换电话网的仅音频呼叫)。在1822处，判定另一方(例如，在该示例中的接收方)的电话号码是否在本地设备(例如，该示例中的发起方)的全局地址簿中。在1826处，如果为否，则对于不在地址簿1828中的裸拨号不存在升级选项。该方法能够在如下假设下采用：用户通常不偏好具有以裸号码升级呼叫的选项。然而，实际上，可以提供该选项(例如，如果期望的话，如果如此设定偏好，等等)。
然后，判定接收方是否在全局地址簿中显示为视频呼叫服务的参与者。在1832处，如果电话号码在地址簿中，则在全局地址簿中检查联系人以查看是否设定了isparticipant标志以及是否为联系人设定1834远程用户标识符字段。
如果任一字段没有被设定1838，则接收方的服务用户名被从客户端应用处获得。在1840处，接收方的电话号码被用于经由voip代理来查找接收方的服务用户名。如图所示，处理1842、1844可以包括调用跨平台客户端组件1814。然后，提供结果1846。
如果在地址簿中设定1920两个字段，则如本文所描述的启用升级按钮；然后能够接收到1926按钮的激活的指示。能够如本文所述经由升级前参与确认技术来设定远程用户标识符字段和isparticipant标志。
然后，判定无缝升级是否可能1930。通过经由本地用户名(例如，使用记号或其它技术)代表用户建立与后端组件1815的经认证的连接1934，由跨平台组件转发对于无缝呼叫升级能力1932的查询。
然后，能够获得移动存在信息(例如，经由瞬时消息发送或其它通信协议)(例如，移动状态通知协议等)1936。能够在1938处返回接收方用户的无缝呼叫升级标志信息。
如果无缝呼叫升级标志指示无缝呼叫升级不可能2022，则结果被转发2024回到框架。在此点，即使不是无缝的，也能够采取2026各种措施，例如结束呼叫，显示错误消息，或者参与呼叫升级。
如果无缝呼叫升级标志指示无缝呼叫升级是可能的2028，则结果也被转发2030回到框架。判定接收方支持无缝呼叫升级2032，并且过程继续。
然后，启动2040仅音频呼叫到视频的升级的过程。视频呼叫客户端用户接口被发射到前台2042。能够显示2044连接用户接口。呼出升级到视频呼叫的请求正在发生的通知能够被发送2046回到框架1810。
然后，可以实现2120视频呼叫。呼出呼叫的呼叫上下文信息能够被设定成指示视频呼叫是仅音频呼叫的升级(例如，经由如本文所述的升级标志或其它升级指示)。推送通知能够被发送2122到第二设备上的跨平台组件1816(例如，直接地、通过后端组件1815，等等)。在2124处接收呼入的视频呼叫的通知；通知可以指示其用于呼叫的升级。
在2126处，显示出升级呼叫用户接口，并且用户能够接受呼叫。请求可以被发送到框架2128。在2130处，视频呼叫客户端用户接口能够被发射到前台。在2132处可以显示连接用户接口。可以发送加入呼叫消息2140。系统准备好升级呼叫的通知能够被发送2144。随后，能够显示出呼叫中用户接口2146。
在2148处，呼叫被接受。在2150处，接受被转发。在2152处，能够发送呼叫准备就绪的通知。
能够发送停止呼叫消息(例如，停止音频呼叫)2160。然后，发回蜂窝呼叫结束通知2162，这导致来自发起设备的蜂窝呼叫结束通知2164。
能够显示2166呼出的呼叫中用户接口，在2170处能够发送开始视频消息，并且在2172处转发该开始视频消息。最后，接收2174从第一用户接收到的视频流。
呼叫已经升级，并且两个端点之间的通信能够继续。
示例42-示范性的具有升级前参与确认的实现方式
图22是示出用于技术的实现的示范性的处理的流程图，包括升级前参与确认。所涉及的要素类似于图18的那些。如图所示，该过程可以被限制为在单个设备上执行(例如，能够在发起设备上、接收方设备上、或两者上执行)。在一些情况下，会涉及到服务器组件。如本文所述的，客户端应用能够提供用于诸如视频服务的服务的通信。
对于从跨平台呼叫客户端1812接收到2220的那些服务联系人s，一个实施例在本地全局地址簿中创建了应用实体。为s创建联系人2222。判定服务联系人s是否是受限的联系人2224(例如，不是服务的实际完全参与者但是可以由其接近的联系人)。如果是，2226，则应用实体被创建2228，并且电话号码和电子邮件字段被填充。远程标识符字段被设定成s的服务用户标识符。然而，因为不能经由视频呼叫服务来接近联系人，所以isparticipant字段(例如，标志)被设定成假。
如果联系人是普通的服务联系人2230，则应用实体被创建，并且电话号码和电子邮件字段被填充。远程标识符字段被设定成s的服务用户标识符。并且isparticipant字段被设定成真2232。随后标志能够被用作呼叫升级处理的部分。
在另一实施例中，如本文所述的，能够对本地全局地址簿进行抓取来找到联系信息。如本文所述的，能够在空闲时执行该方法。对于能够经由api访问以便访问全局地址簿(例如直接访问等)2240的那些联系人，细节被发送2242到服务应用。可以发生针对电话号码、电子邮件或服务用户名2244的查找，提供结果2246。该技术有时称为“短路”，如本文所述。
如果存在成功的匹配2248，则对于电话号码/电子邮件、用户名对，应用实体被创建，信息被填充，并且isparticipant字段被设定成真2250。
如果基于结果2260不存在匹配2252(例如，联系人不是视频呼叫服务的参与者)，则可以发生进一步的处理。
针对对于联系人2270可用的电话号码，如果发起用户具有服务信用或者电话号码是免费的2272，应用实体可以被填充，服务用户名能够被设定成正常电话号码，并且isparticipant字段能够被设定成假2274。
如本文所述，然后可以咨询isparticipant字段以判定仅音频呼叫中的另一方是否是服务的参与者(例如，从发起方的视角看)。因此，实现了升级前参与确认。另一方可能实际上是服务的参与者，但是为了升级处理的目的，另一方被处理为不可用于呼叫升级。因此，isparticipant字段可以指示联系人是否是能够访问服务的用户的本地用户网络的参与者。
示例43-示范性的计算系统
图23示出了能够实现若干所描述的创新的适合的计算系统或环境2300的通用示例。计算系统2300不意在暗示对使用或功能的范围的任何限制，因为创新可以实现于多样的通用或专用计算系统中。如本文所描述的通信设备能够表现为所描述的计算系统2300的形式。
参考图23，计算系统2300包括一个或多个处理单元2310、2315以及存储器2320、2325。在图23中，该基本配置2330被包含在虚线内。处理单元2310、2315执行计算机可执行指令。处理单元可以是通用中央处理单元(cpu)、专用集成电路(asic)中的处理器或任何其它类型的处理器。在多处理系统中，多个处理单元执行计算机可执行指令以提高处理能力。例如，图23示出了中央处理单元2310以及图形处理单元或协处理单元2315。有形存储器2320、2325可以是处理单元能访问的易失性存储器(例如，寄存器、高速缓存、ram)、非易失性存储器(例如，rom、eeprom、闪存等)、或两者的某种组合。存储器2320、2325存储实现本文所述的一个或多个创新的软件2380，形式为适合于由处理单元执行的计算机可执行指令。
计算系统可以具有附加的特征。例如，计算系统2300包括存储设备2340、一个或多个输入设备2350、一个或多个输出设备2360、以及一个或多个通信连接2370。诸如总线、控制器、或网络的互连机构(未示出)将计算系统2300的组件互连。典型地，操作系统软件(未示出)提供了在计算系统2300中执行的其它软件的操作环境，并且协调计算系统2300的组件的活动。
有形存储设备2340可以是可移除的或非可移除的，并且包括磁盘、磁带或磁盒、cd-rom、dvd、或能够被用于以非暂态方式存储信息并且能够在计算系统2300内被访问的任何其它介质。存储设备2340存储实现本文所述的一个或多个创新的软件2380的指令。
输入设备2350可以是：触摸输入设备，诸如键盘、鼠标、笔、或轨迹球；语音输入设备；扫描设备；或者向计算系统2300提供输入的另一设备。对于视频编码，输入设备2350可以是摄像机、视频卡、tv调谐卡、或接受模拟或数字形式的视频输入的类似设备，或者将视频采样读入计算系统2300的cd-rom或cd-rw。输出设备2360可以是显示器、打印机、扬声器、cd写入器、或者从计算系统2300提供输出的另一设备。
通信连接2370启用通过通信介质到另一计算实体的通信。通信介质传送诸如计算机可执行指令、音频或视频输入或输出、或者调制数据信号中的其它数据的信息。调制数据信号是以如下方式设定或改变其一个或多个特性的信号：对信号中的信息进行编码。通过示例而不是限制的方式，通信介质可以使用电、光、rf或其它载体。
可以在计算机可读介质的总体上下文中描述创新。计算机可读介质是任何能够在计算环内被访问的可用的有形介质。通过示例而不是限制的方式，对于计算系统2300，计算机可读介质包括存储器2320、2325，存储设备2340，以及上述任意的组合。
能够在计算机可执行指令的总体上下文中描述创新，诸如那些被包含在程序模块中的创新、在目标真实或虚拟处理器上的计算系统中执行的那些创新(例如，其最终在硬件中执行)。一般地，程序模块包括例程、程序、库、对象、类、组件、数据结构等，其执行特定任务或实现特定的抽象数据类型。在各个实施例中根据期望，程序模块的功能可以在程序模块之间组合或者拆分。可以在本地或分布式计算系统内执行用于程序模块的计算机可执行指令。
术语“系统”和“设备”在本文中互换使用。除非上下文明确规定，否则任一术语均不暗示对计算系统或计算设备的类型的任何限制。一般地，计算机系统或计算设备可以是本地的或分布式的，并且可以包括专用硬件和/或通用硬件与实现本文所描述的功能的软件的任意组合。
为了呈现的原因，具体实施方式使用了类似于“确定”和“使用”的术语来描述计算系统中的计算机操作。这些术语是计算机所执行的操作的高级抽象，不应与人类执行的动作混淆。实际的对应于这些术语的计算机操作根据实现方式而不同。
示例44-示范性的移动设备
在本文的任意示例中，通信设备可以表现为移动设备的形式。图24是描绘了示范性的移动设备2400的系统图，包括各种可选的硬件和软件组件，一般地显示在2402处。移动设备中的任何组件2402能够与任何其它组件通信，但是为了易于说明，没有示出所有的连接。移动设备可以是各种计算设备(例如，蜂窝电话、智能电话、手持式计算机、个人数字助理(pda)等)中的任一种并且能够允许与诸如蜂窝、卫星或其它网络的一个或多个移动通信网络2404的无线双向通信。ip语音场景(例如，通过wifi或其它网络)也能够得到支持。本文所述的通信设备能够表现为所描述的移动设备2400的形式。
图示的移动设备2400可以包括控制器或处理器2410(例如，信号处理器、微处理器、asic、或其它控制与处理逻辑电路系统)，用于执行诸如信号编码、数据处理、输入/输出处理、功率控制、和/或其它功能的任务。操作系统2412能够控制组件2402的分配和使用并且支持一个或多个应用程序2414。应用程序2414能够包括共有的移动计算应用(例如，电子邮件应用、日历、联系人管理器、网络浏览器、收发消息应用)、或者任何其它计算应用。用于访问应用商店的功能2413还能够被用于获取并更新应用2414。
图示的移动设备2400可以包括存储器2420。存储器2420可以包括非可移除存储器2422和/或可移除存储器2424。非可移除存储器2422可以包括ram、rom、闪存、硬盘、或其它公知的存储器存储技术。可移除存储器2424可以包括闪存或订购者身份模块(sim)卡，这是gsm通信系统中公知的，或者诸如“智能卡”的其它公知存储器存储技术。存储器2420能够被用于存储用于运行操作系统2412和应用2414的数据和/或代码。示例数据可包括网页、文本、图像、声音文件、视频数据、或者经由一个或多个有线或无线网络发送到一个或多个网络服务器或其它设备和/或从一个或多个网络服务器或其它设备接收的其它数据集。存储器2420能够被用于存储器订购者标识符，诸如国际移动订购者身份(imsi)，以及装备标识符，诸如国际移动装备标识符(imei)。这些标识符能够被发送到网络服务器以标识用户和装备。
移动设备2400能够支持：一个或多个输入设备2430，诸如触摸屏2432、麦克风2434、摄像机2436、物理键盘2438和/或轨迹球2440；以及一个或多个输出设备2450，诸如扬声器2452以及显示器2454。其它可能的输出设备(未示出)可以包括压电或其它触摸输出设备。一些设备能够提供多于一种的输入/输出功能。例如，触摸屏2432和显示器2454能够组合在单个输入/输出设备中。
无线调制解调器2460能够与天线(未示出)耦合并且能够支持处理器2410与外部设备之间的双向通信，这是本领域公知的。调制解调器2460显示为通用的并且可以包括用于与移动通信网络2404通信的蜂窝调制解调器和/或其它基于无线电的调制解调器(例如，bluetooth2464或wi-fi2462)。无线调制解调器2460典型地被配置为与一个或多个蜂窝网络通信，诸如gsm或cdma网络，用于在单个蜂窝网络内、蜂窝网络之间、或者移动设备与公用交换电话网(pstn)之间的数据和语音通信。
移动设备2400可以进一步包括至少一个输入/输出端口2480、电源2482、诸如全球定位系统(gps)接收器的卫星导航系统接收器2484、加速度计2486、和/或物理连接器2490，其可以是usb端口、ieee1394(firewire)端口、和/或rs-232端口。图示的组件2402不是必要的或全部包含的，由于任何组件可以被删除并且其它组件可以被添加。
示例45-示范性的云支持环境
在图25的示例环境2500中，云2510提供用于与各种屏幕能力连接的设备2530、2540、2550的服务。连接的设备2530代表了具有计算机屏幕2535(例如，中等大小的屏幕)的设备。例如，连接的设备2530可以是个人计算机，诸如桌面式计算机、膝上型计算机、笔记本、上网本等。连接的设备2540代表了具备移动设备屏幕2545(例如，小尺寸屏幕)的设备。例如，连接的设备2540可以是移动电话、智能电话、个人数字助理、平板式计算机等。连接的设备2550代表了具备较大屏幕2555的设备。例如，连接的设备2550可以是电视机屏幕(例如，智能电视机)或连接到电视机(例如，机顶盒或游戏控制台)等的另一设备。连接的设备2530、2540、2550中的一个或多个可以包括触摸屏能力。触摸屏能够以不同的方式接受输入。例如，当对象(例如，指尖或触针)扭曲或中断跨表面运行的电流时，电容触摸屏检测到触摸输入。作为另一示例，当来自光传感器的光束被中断时，触摸屏能够使用光学传感器来检测触摸输入。对于一些触摸屏要检测的输入来说，与屏幕表面的物理接触不是必要的。在示例环境2500中，还能够使用不具备屏幕能力的设备。例如，云2510能够为一个或多个不具备显示器的计算机(例如，服务器计算机)提供服务。
能够通过服务提供商2520由云2510、或者通过其它在线服务的提供商(未描绘)来提供服务。例如，云服务可以针对特定连接设备(例如，连接的设备2530、2540、2550)的屏幕尺寸、显示能力、和/或触摸屏能力来定制。
在示例环境2500中，云2510至少部分地利用服务提供商2520将本文描述的技术和解决方案提供给各个连接设备2530、2540、2550。例如，服务提供商2520能够为各种基于云的服务提供集中解决方案。服务提供商2520能够管理用户和/或设备的(例如，连接设备2530、2540、2550和/或其相应用户的)服务订购。
示例46-示范性的实现方式
虽然为便于呈现，以特别的顺序的次序描述了公开的方法中的一些的操作，应当理解的是这种描述方式涵盖了重布置，除非被下面阐述的具体语言要求特定次序。例如，顺序地描述的操作在一些情况下可以同时被重新布置或执行。而且，为了简化的原因，所附的图可以不显示出公开的方法能够与其它方法结合使用的各种方式。
任何公开的方法能够实现为存储在一个或多个计算机可读存储介质(例如，非暂时性计算机可读介质，诸如一个或多个光介质盘，易失性存储器组件(诸如dram或sram)、或非易失性存储器组件(诸如硬盘))上并且在计算机(例如，任何商业方式可获得的计算机、包括智能手机或其它包括计算硬件的移动设备)上执行的计算机可执行指令。任何用于实现公开的技术的计算机可执行指令以及在公开的实施例的实现期间创建和使用的任何数据能够存储在一个或多个计算机可读介质(例如，非暂时性计算机可读介质)上。计算机可执行指令可以是例如专用软件应用或经由网络浏览器或其它软件应用(诸如远程计算应用)访问或下载的软件应用的部分。该软件可以例如在单个本地计算机(例如，任何适合的商业方式可获得的计算机)中或者在使用一个或多个网络计算机的网络环境(例如，经由因特网、广域网、局域网、客户端-服务器网络(诸如云计算网络)、或其它这样的网络)中执行。
为清晰起见，仅描述了基于软件的实现方式中的一些选定方面。本领域公知的其它细节省略。例如，应当理解，公开的技术不限于任何特定的计算机语言或程序。例如，公开的技术能够由用c++、java、perl、javascript、adobeflash或任何其它适合的编程语言编写的软件来实现。同样，公开的技术不限于任何特定的计算机或任何特定类型的硬件。适合的计算机和硬件的一些细节是公知的，无需在本公开中具体阐述。
此外，任何基于软件的实施例(包括例如用于使计算机执行任何公开的方法的计算机可执行指令)能够通过适合的通信手段来上传、下载或远程访问。这样的适合的通信手段包括例如因特网、万维网、内联网、软件应用、电缆(包括光纤电缆)、磁通信、电磁通信(包括rf、微波和红外通信)、电子通信、或其它这样的通信手段。
公开的方法、装置和系统不应解释为以任何方式进行限制。相反，本公开涉及各个公开的实施例的全新以及非显而易见的特征和方面，单独地和彼此成各种组合和子组合。公开的方法、装置和系统不限于任何特定的方面或特征或其组合，公开的实施例也不要求任何一个或多个特定优点被呈现或者问题被解决。
非暂时性计算机可读介质
任何本文中的计算机可读介质可以是非暂时性的(例如，存储器、磁存储、光存储等)。
存储在计算机可读介质中
可以通过存储在一个或多个计算机可读介质(例如，计算机可读存储介质或其它有形介质)中来实现任何本文中描述的存储动作。
任何描述为被存储的事物能够被存储在一个或多个计算机可读介质(例如，计算机可读存储介质或其它有形介质)中。
计算机可读介质中的方法
本文描述的任意方法能够由在一个或多个计算机可读介质(例如，计算机可读存储介质或其它有形介质)中(例如编码在一个或多个计算机可读介质上)的计算机可执行指令来实现。该指令能够使得计算系统执行方法。本文描述的技术能够被以各种编程语言实现。
计算机可读存储设备中的方法
任何本文中描述的方法能够由存储在一个或多个计算机可读存储设备(例如，存储器、磁存储设备、光存储设备等)中的计算机可执行指令来实现。该指令能够使得计算机执行方法。
示范性组合
能够支持各种组合。例如，呼入呼叫用户接口能够与呼叫进展中用户接口组合(例如，在呼入的呼叫被接受之后)。呼叫进展中用户接口能够与后台呼叫进展中用户接口组合(例如，如果呼叫移至后台)。
呼叫进展中用户接口能够与家庭用户接口组合(例如，如果在呼叫期间导航发生在家庭用户接口中)。在该情况下，后台呼叫进展中用户接口也能够被显示。
用于启动通信的用户接口还能够与任何其它用户接口组合。
可选方案
来自任何示例的技术能够与在任何一个或多个其它示例中描述的技术组合。在使用词语“示范性”的情况下，意在表明示例，而不是理想的实施例。考虑到公开的技术原理能够应用到的多个可能的实施例，应当认识到，图示的实施例是公开技术的示例，而不应被视为对公开技术的范围的限制。相反，公开技术的范围包括下面的权利要求所涵盖的。因此，我们主张所有落在权利要求的范围和精神内为我们的发明。
- 还没有人留言评论。精彩留言会获得点赞！