TMO与Sprint Wi-Fi通话功能详解（V1.0）

需积分: 9 31 浏览量更新于2024-07-22 收藏 2.23MB DOC 举报

本文档是一份关于T-Mobile（TMO）和Sprint两家电信运营商提供的Wi-Fi通话服务的介绍，版本为1.0，最初创建于2015年3月23日。作者是高级测试工程师Lei Xie。这份文档详细概述了Wi-Fi通话技术的基础概念、用户体验、在终端设备（UE）上的实现、基于IMS网络的支持、SIP（Session Initiation Protocol）协议以及SDP（Session Description Protocol）的应用，同时还涉及了SIM卡、USIM卡和UICC（Universal Subscriber Identity Module）等移动通信相关的身份认证和管理。 1. **Wi-Fi Calling概览**： Wi-Fi通话是一种利用无线局域网（Wi-Fi）连接进行语音通话的技术，它扩展了传统蜂窝网络的覆盖范围，并允许用户在Wi-Fi环境下享受高质量的语音服务，特别是在信号较差或无蜂窝网络的地方。 2. **用户Wi-Fi通话体验**：文档提及了用户在Wi-Fi条件下可以期待的通话质量，包括清晰度、稳定性及与蜂窝网络通话的无缝切换能力。 3. **TMO Wi-Fi呼叫实施**： TMO的Wi-Fi通话服务基于IMS（IP Multimedia Subsystem）网络架构，通过IMS平台实现了语音、视频和多媒体通信功能。 4. **SIP协议介绍**： SIP是会话初始协议，用于设置、管理、修改和释放多媒体会话，是Wi-Fi通话的核心组成部分，负责建立和维护通信连接。 5. **SDP协议应用**： SDP用于描述会话的媒体属性，如音频和视频格式、带宽需求等，确保双方设备能够正确地解析并协商会话配置。 6. **SIM卡与身份管理**： ISIM、SIM和USIM是移动设备用于存储和验证用户身份的卡片，而在Wi-Fi通话中，这些卡片的角色可能有所变化，以适应Wi-Fi环境下的身份验证流程。 7. **注册和注销过程**：文档概述了用户在Wi-Fi网络中的注册、重新注册和注销操作，确保安全性和连接稳定性。 8. **会话初始化与释放**： Wi-Fi通话涉及到会话的启动和结束，包括如何发起呼叫、接听呼叫以及断开连接的过程。 9. **短信和消息服务**：尽管Wi-Fi通话主要关注语音，但文档提到短信（SMS）和消息服务并不包含在内，可能需要单独处理。 10. **多方会议和补充服务**：文档还讨论了支持多方通话（conferencing）和其他可能的补充服务，如VoIP电话会议功能。 11. **运营商政策**： TMO和Sprint各自的Wi-Fi通话实施策略，可能涉及网络优化、计费、安全和客户服务等方面。 12. **未来展望**：文档末尾提到有部分内容未涉及，但计划在未来继续探讨，这暗示了Wi-Fi通话技术仍在不断发展和改进中。这份文档为理解和使用TMO和Sprint的Wi-Fi通话服务提供了全面的指导，涵盖了技术基础、实施细节和操作流程，对于IT专业人员和电信服务用户提供了一手资料。

TCT-VAL-SZPIC Version  : 0.2

Page  : 11 / 83

list unless the header field value is "*".

header = "header-name" HCOLON header-value *(COMMA header-value)

Each header field consists of a field name followed by a colon (":") and the field value.

field-name: field-value

The relative order of header fields with different field names is not significant. However, it is

RECOMMENDED that header fields which are needed for proxy processing (Via, Route,

Record-Route, Proxy-Require, Max-Forwards, and Proxy-Authorization, for example)

appear towards the top of the message to facilitate rapid parsing.

The relative order of header field rows with the same field name is important. Multiple

header field rows with the same field-name MAY be present in a message if and only if the

entire field-value for that header field is defined as a comma-separated list. It MUST be

possible to combine the multiple header field rows into one "field-name: field-value" pair,

without changing the semantics of the message, by appending each subsequent field-value to

the first, each separated by a comma.

The exceptions to this rule are the WWW-Authenticate, Authorization, Proxy-Authenticate,

and Proxy-Authorization header fields. Multiple header field rows with these names MAY

be present in a message, but since their grammar does not follow the general form, they

MUST NOT be combined into a single header field row.

Implementations MUST be able to process multiple header field rows with the same name in

any combination of the single-value-per-line or comma-separated value forms.

The format of a header field-value is defined per header-name. It will always be either an

opaque sequence of TEXT-UTF8 octets, or a combination of whitespace, tokens, separators,

and quoted strings. Many existing header fields will adhere to the general form of a value

followed by a semi-colon separated sequence of parameter-name,

parameter-value pairs:

field-name: field-value *(;parameter-name=parameter-value)

Even though an arbitrary number of parameter pairs may be attached to a header field value,

any given parameter-name MUST NOT appear more than once. When comparing header

fields, field names are always case insensitive.

Unless otherwise stated in the definition of a particular header field, field values, parameter

names, and parameter values are case-insensitive. Tokens are always case-insensitive. Unless

specified otherwise, values expressed as quoted strings are case-sensitive.

 Bodies

The interpretation of the body depends on the request method. For response messages, the

request method and the response status code determine the type and interpretation of any

message body. All responses MAY include a body.

TCT-VAL-SZPIC Version  : 0.2

Page  : 12 / 83

 Message Body Type

The Internet media type of the message body MUST be given by the Content-Type header

field. If the body has undergone any encoding such as compression, then this MUST be

indicated by the Content-Encoding header field; otherwise, Content-Encoding MUST be

omitted. If applicable, the character set of the message body is indicated as part of the

Content-Type header-field value. The "multipart" MIME type MAY be used within the body

of the message. Implementations that send requests containing multipart message bodies

MUST send a session description as a non-multipart message body if the remote

implementation requests this through an Accept header field that does not contain multipart.

SIP messages MAY contain binary bodies or body parts. When no explicit charset parameter

is provided by the sender, media subtypes of the "text" type are defined to have a default

charset value of "UTF-8".

 Message Body Length

The body length in bytes is provided by the Content-Length header field. Section 20.14

describes the necessary contents of this header field in detail.

The "chunked" transfer encoding of HTTP/1.1 MUST NOT be used for SIP.

Introduction to SDP [taken from RFC2327]

The purpose of SDP is to convey information about media streams in multimedia sessions to

allow the recipients of a session description to participate in the session. SDP is primarily

intended for use in an internetwork, although it is sufficiently general that it can describe

conferences in other network environments.

A multimedia session, for these purposes, is defined as a set of media streams that exist for

some duration of time. Media streams can be many-to-many. The times during which the

session is active need not be continuous.

Thus far, multicast based sessions on the Internet have differed from many other forms of

conferencing in that anyone receiving the traffic can join the session (unless the session

traffic is encrypted). In such an environment, SDP serves two primary purposes. It is a

means to communicate the existence of a session, and is a means to convey sufficient

information to enable joining and participating in the session. In a unicast environment, only

the latter purpose is likely to be relevant.

Thus SDP includes:

o Session name and purpose

o Time(s) the session is active

o The media comprising the session

o Information to receive those media (addresses, ports, formats and so on)

As resources necessary to participate in a session may be limited, some additional

information may also be desirable:

剩余63页未读，继续阅读

qq_26343905

粉丝: 0
资源: 1

TMO与Sprint Wi-Fi通话功能详解（V1.0）

TMO任务：T-Mobile Web UI开发与部署教程

LGE Optimus F6 TMO-MPCS设备的AOSP配置指南

探索TypeScript中的tmo-puzzle解谜游戏

tmo-web-ui:TMO任务

tmo-puzzle

Autocascade for TMO Viewer-crx插件

TMO-IU5:实验室ML

TMO1

android_device_lge_f6mt:LGE Optimus F6 TMO-MPCS的AOSP设备配置

tmo:TMO仪器的软件工具

最新资源