技术基础
爱立信 IMS weShare 4.0 能够同时处理 3GPP CSI和GSMA VideoShare 中规定的电路交换和分组数据业务。

图 4:通讯圆环—个人(中心环)、他(或她)的家人及好友(第二环)及其他熟人与联系人(外环)。
| Applications |
应用 |
| Client application |
客户端应用 |
| Ericsson IMS weShare |
爱立信 IMS weShare |
| JME applications |
JME 应用 |
| JME API |
JME API |
| ICP API |
ICP API |
| Service enablers |
业务支持程序 |
| ICP core |
ICP 核心 |
图 5:爱立信 IMS 客户端解决方案:weShare 客户端应用以及其它 IMS 应用在 IMS 客户端平台 (ICP) 上同时运行。
借助这一解决方案,最终用户便可在通话的同时,传送各种类型的多媒体内容。语音信号通过电路承载进行发送,而可视媒体则通过分组数据承载进行发送。爱立信 IMS weShare 产品可提供一系列丰富的业务,使您的语音通话更加精彩。
客户端体系结构
爱立信的 IMS 客户端平台,是一个面向 IMS 业务的一个水平客户端平台,代替客户端应用从协议和业务层面处理所有标准的行为。从而,它将客户端与 IMS 技术剥离,支持客户端开发人员全面致力于特定的业务用户界面以及与用户交互的其它领域。一个能将ICP功能开放给应用的高层应用编程接口 (API) 是实现这个想法的关键。
ICP 还支持所有的 IMS 客户端应用使用 IMS 功能,同时确保客户端之间的互操作性并避免在客户端应用中的重复操作。图 5 阐明了这一解决方案并描述了 ICP 与客户端应用的体系结构。为便利起见,下文中所有提到的爱立信 IMS weShare 客户端都包含客户端应用与 ICP。
网络体系结构
爱立信 IMS weShare 4.0 解决方案采用了同之前的版本中相同的IMS 对等体系结构,来保障用户的 IMS 手机连通性与媒体的传递,。GSMA VideoShare 和 3GPP CSI 均支持这一体系结构。这种方法可使运营商通过相对较小的 IMS 网络投资来启动新型爱立信 IMS weShare 业务,同时拥有多种爱立信 IMS weShare 业务,包括实时计费等。
会话初始协议 (SIP) 进程通过空中链路以及分组核心网络触发。两个主要的SIP进程为功能查询 (capability query) 与会话建立 (session setup)。爱立信IMS weShare使用了这两种进程(这两种进程已被 GSMA 和 3GPP 中采纳)。
一旦SIP进程被触发,#1 和 #2 之间的 IMS 核心上便会建立一个媒体平面(图六)。
就分组数据协议 (PDP) 上下文激活而言,一些运营商倾向于 PDP“不间断”模式;有些则倾向于 PDP“每一呼叫”(per-call) 激活模式。GSMA VideoShare 系列可支持任一模式,这意味着爱立信 IMS weShare 4.0 也可支持任一模式。如果 PDP 由“每一呼叫”激活(当一个电路交换语音呼叫得到应答时),那么客户端便在“每一呼叫”的基础上进行 SIP 注册。
功能查询
爱立信 IMS weShare 4.0 的功能查询机制(与在 GSMA 和 3GPP 所使用的相同)能在手机中显示相应的业务图标,提示最终用户他们在进行语音呼叫的时候可以激活哪项业务。爱立信 IMS weShare 使用 SIP OPTIONS 查询/响应方法。为帮助止呼的 IMS 核心网络将OPTIONS 消息路由到正在进行电路话音的终端,爱立信 IMS weShare 客户端在信息的接受联系报头上设置了一个特性标签 (+g.3gpp-cs-voice)。
支持 SIP OPTIONS 方法的被叫手机以 200 OK 消息(这一消息包括描述其性能的对话数据协议SDP)来响应接收到的消息。发出查询的爱立信 IMS weShare 客户端对这些功能进行分析,而后在客户端手机上显示出对应的图标。
爱立信 IMS weShare 4.0 开发中的一个目标就是在不破坏 3GPP 的兼容性的前提下,确保能与其它主要厂商(非爱立信手机的厂商)的设备交互操作。因此,爱立信 IMS weShare 的一大重要特征与强大特性便是可与那些同 SIP OPTIONS 方法的规则不完全一致“传统”手机相兼容。例如,如果远程手机无法执行 SIP OPTIONS,发起功能查询的爱立信 IMS weShare 客户端仍能够显示出一定数量的业务图标。
SIP 对话邀请/计费
当一位最终用户选择了所显示的一项业务图标时,爱立信 IMS weShare 客户端便建立一个 SIP 对话。标准 SIP 对话邀请程序有两种:
IETF 方法,以及
3GPP IMS(前提条件)方法。为应付始发与终端手机已预先配置为不同模式的情况,爱立信 IMS weShare 还支持降级运行,以保证会话的成功建立。因此,当最终用户选择了一项业务图标时,爱立信 IMS weShare 客户端便以预先配置的模式建立一个 SIP 会话。此 SIP 会话包括一个 SDP 部分,可描述所提供的业务媒体。
爱立信 IMS weShare 4.0 体系结构不包括可截取媒体的业务内容感知 (sercive-content-aware) 节点。因此,为支持实时计费与非实时计费,IMS 核心 (S-CSCF) 可提取 SIP 对话与 SDP 数据,并将其转发至实时计费系统。
Motion(动态视频)
当最终用户选择了“实时视频 (Live Video)”图标时,SIP 对话便激活基于 RTP 的单向视频。终端手机以其编解码器和接收带宽的相关信息进行响应。爱立信 IMS weShare 支持 H.263 视频编解码器(可处理 64kbps 或 128kbps 的视频)。
用户的体验取决于无线环境。WCDMA 接入可提供 56 或 112kbps 的原始视频传输速率。GERAN/DTM 可提供 40kbps(DTM,class 11 接入)以及 25kbps(DTM,class 5 接入)的视频传输速率。爱立信 IMS weShare 支持基于 GERAN/DTM 的流服务质量 (QoS) 以及基于 WCDMA 的交互视频或媒体流。无法接入 WCDMA 或 EDGE 时,便无法支持视频。
视频分组数据通过 RTP 进行传送。接收方和发送方的测试报告通过 RTCP 传送。当一方手机转为不带有双传送模式 (DTM) 的纯 GSM 接入时,爱立信 IMS weShare 将自动终止此次会话。
当视频传输停止时,客户端则终止 RTP 会话 (RTCP ”BYE”) 与 SIP 会话 (SIP ”BYE”)。实时和非实时计费都以视频对话的时长来计。爱立信 IMS weShare 4.0 与 GSMA VideoShare的定义(重点面向实时视频业务)兼容。
Image(图像)与 Media File(媒体文件)
| CS |
呼叫会话 |
| CS core |
CS 核心 |
| OCS |
实时计费系统 |
| Online charging |
实时计费 |
| IMS client |
多媒体子系统客户端 |
| PS core |
PS 核心 |
| CSCF |
呼叫会话控制功能 |
| Mb:RTP and MSRP based media e.g. video, pictures |
Mb:基于 RTP 和 MSRP 的媒体,如视频、图片 |
| Originating session side/operator #1 |
会话发起端/运营商 #1 |
| Terminating session side/operator#2 |
会话终止端/运营商 #2 |
图6:不包含 weShare 应用服务器的体系结构简图。
除了视频,爱立信 IMS weShare 4.0 还支持用户共享图像与媒体文件。其中包括实时及存储的图像和视频片断。功能查询机制可检测远程手机对图像/文件共享的水平。例如,如果一位最终用户选择了爱立信 IMS weShare Image 业务,其手机便会发送一个 SIP 对话邀请 ,显示基于消息对话中继协议 (MSRP) 的图片传送。功能查询机制可识别远程手机支持的编解码器。在 SIP会话协商成功后 (200 OK),爱立信 IMS weShare 便在手机之间建立直接的 TCP 连接。如果双方手机分属于不同的网络或运营商,TCP 连接则将通过网络边缘的网络地址转换/转换器 (NAT) 功能节点建立。这一功能通过一个会话边界网关 (SBG) 实现。爱立信的 SBG 具备 MSRP感知能力,可以胜任这些情况。SBG在这种情况下的功能类似 MSRP 应用层网关 (ALG) ,可通过修改 MSRP 消息的 IP 地址标头,使其与来自 SIP 信令的 SDP 的 IP 地址域相匹配。若不做此修改,远程客户端将拒绝 MSRP 消息。
若 TCP 连接已建立,手机便可在 MSRP S E N D 消息中附带图像。当接收手机成功提取并显示图像后,便通过 MSRP 200 OK 消息予以答复。
商标
爱立信 IMS weShare 是瑞典爱立信电话公司 (Telefonaktiebolaget LM) 的商标。
GSM 与 GSM 标识均由 GSM 协会注册并归其所有。
Sun Microsystems、Java、以及 Java Community Process 均为 Sun Microsystems 公司在美国及其它国家和地区的注册商标,归 Sun Microsystems 公司所有。
|
Whiteboard(白板)
爱立信 IMS weShare 提供一项白板业务,支持在远程手机上显示发送方用触控笔在其智能手机显示屏书写或描绘的内容。用户可以从这样的应用获得很多便利,例如,可在发送的图片或地图上作出标记,以确认某物或指示某一位置。爱立信 IMS weShare Whiteboard 业务也使用了 MSRP。借助包含 MIME 纯文本的多个 MSRP SEND 消息,触控笔勾勒出的每一笔划便可传送至远程手机上。
未来版本
爱立信 IMS weShare 的未来版本将提供更多的增值业务。例如,用户将可以:
• 交换音乐与 web 内容
• 发送个人的可视问候;
• 与固定的纯 IP 手机交互工作;以及
• 管理增添的业务类特性,诸如白名单/黑名单呼入或呼出媒体类型。
爱立信 IMS weShare 还将支持增强的计费系统。要实现这些业务,必须为这一架构添加应用服务器以及媒体资源功能 (MRF)。
| IMS Client |
IMS 客户端 |
| CS Core |
CS 核心 |
| PS Core |
PS 核心 |
| Mb:RTP and MSRP based media e.g. video,pictures |
Mb:基于 RTP 和 MSRP 的媒体,如视频,图片等 |
| Originating session side/operator #1 |
会话发起端/运营商 #1 |
| Terminating session side/operator #2 |
会话终止端/运营商 #2 |
图 7:部署有 weShare 应用服务器的高级体系结构。
如图 7 所示,内容媒体将不再绕开 IMS 核心,而是直接通过 MRF。这样,运营商就可以进行全方位的计费管理和策略管理。
策略管理
这一系统可检测出最终用户双方试图交换的媒体类型是否与协定的(通过 SIP/SDP 会话信令)媒体类型一致。此外,为了保护系统安全,操作人员可在 MRF 中设置图像的最大尺寸限制,这样,MRF 将可拒绝超过这一限制的图像或文件。
计费
用户可在一个 SIP 会话期间发送多种类型的内容。而借助 MRF,运营商不会遗漏任何可以用来计费的事件。更重要的是,MRF 可消除因添加新的媒体元素而导致的呼叫建立延迟。
音乐分享
音乐分享业务支持用户在电路交换呼叫的同时将音乐以媒体流的方式传递给另一方用户。例如,某一用户可能已下载以高级音频编码 (ACC+) 格式编译的、适合用64kbps数据流传递的音乐片断。这样,只需选择“分享音乐”图标,他/她便可通过 RTP 在 一个64kbps 分组交换承载(流或交互的 QoS)上将音乐片断传送到其它用户的手机中。此外,这一业务还支持为最新添加的媒体建立一个新的 SIP 会话。若不考虑 DRM(数字版权管理)因素,通过 MSRP 发送完整的音乐片断在技术方面也是可行的。
个性化问候
个性化问候业务支持用户制定个人的可视问候,这一问候可由文本、图片或视频片断组成。在电路交换语音呼叫建立期间,个人问候便会发送至呼叫方。最终用户可根据每次呼叫线路,在媒体库中选择不同的问候内容。当呼叫到达时,电路网络通过 OSA/Parlay 通知应用服务器。应用服务器便处理所有必要的 SIP 信令并将问候内容传送给呼叫方。注:这一解决方案不排除以下方法:被叫方的爱立信 IMS weShare 客户端直接发送一个本地存储的问候。但在任一情况中,MRF 都可以截到问候内容,以支持运营商对此业务收费。
与固定客户端互通
当爱立信 IMS weShare 移动设备用户与纯 IP 终端(如,固定 PC)建立语音呼叫时,媒体网关控制器 (MGC) 便将 ISUP 信令转换成 SIP 信令并传送至固定客户端。语音则由移动端的 比如AMR 转换为 IP 客户端的 G.711 或 G.729。如果移动用户在语音会话期间激活爱立信 IMS we-Share 视频,移动终端则将发送 SIP 信令(此信令可能被应用服务器截取)。如果这一 SIP 会话要与第一个会话合并,应用服务器则发出一个重新邀请信息,将发至纯 IP 用户的媒体由音频扩展至音频加视频。然而,如果由移动终端发出的 SIP 信令将作为单独的 SIP 会话进行传送,应用服务器则无需发送重新邀请,而仅需调整部分 SIP 会话数据,使之与固定设备端更具兼容性。由此,移动终端即可在通话时将分组视频流发送至纯 IP 端。目前,3GPP 正致力于实现 CSI 和纯 IP 设备之间的互通的标准化。
黑名单/白名单
如果采用该服务的用户(如某一家长)想阻止用户接收外部视频内容,应用服务器可以做出相应设置,拒绝任何建立含 SDP 部分(视频)的呼入 SIP 会话的请求。应用服务器可以帮助运营商与最终用户全面、灵活地进行控制,这里举出的只是一个简单的例子。