没有合适的资源?快使用搜索试试~ 我知道了~
首页SIP协议详解:用户与网络断言身份
SIP协议详解:用户与网络断言身份
需积分: 10 1 下载量 33 浏览量
更新于2024-07-18
收藏 5.71MB PDF 举报
"SIP协议开发手册第二部分:用户与网络断言身份"
SIP协议,全称Session Initiation Protocol,是一种用于控制多媒体通信会话(如语音和视频通话)的互联网标准协议。本手册深入探讨了SIP协议开发的关键方面,包括用户身份和网络断言身份(Network-Asserted Identity, NAI)的使用。
10.1 引言
在SIP中,用户身份通常代表用户的一个独特公共身份,这个身份被共享给他人以便他们能联系到用户。用户可以是个体用户、用户群组、服务或者设备。在某些情况下,SIP中的用户身份也可能是一个私有身份,仅在特定封闭的群体内分享,不公开,例如,服务提供商用于访问控制、计费和收费的用户身份。
415章节可能涉及到SIP处理错误代码的情况,比如当一个用户试图使用不支持的媒体类型时,可能会收到415错误响应。这强调了SIP在媒体能力协商过程中的重要性,确保通信双方都能理解和处理相同的媒体类型。
媒体能力协商是SIP通信中的关键步骤,它允许两个或多个端点在建立会话前确定它们之间的兼容性和可用资源。这一过程通常通过SDP(Session Description Protocol)进行,SDP携带关于媒体类型、编码格式、传输地址和端口等信息。
SIP安全机制也是手册中的重要内容。由于SIP协议在开放的互联网上运行,因此必须考虑身份验证、授权和加密等问题。网络断言身份(NAI)在提供这些安全保障方面发挥了作用,尤其是在保护用户的隐私和防止中间人攻击方面。NAI是一种标准化的身份表示形式,可以在不同网络环境中保持一致,即使用户在私有和公共网络之间切换,其身份仍可被正确识别。
此外,SIP路由是另一个复杂但至关重要的主题。SIP消息在从源到目的地的传输过程中可能经过多个SIP服务器和代理,SIP路由规则决定了这些消息如何被正确地转发和处理。理解SIP路由机制对于设计和实现高效可靠的SIP网络至关重要。
这份SIP协议开发手册提供了关于SIP协议的全面信息,对于任何涉及SIP协议开发和部署的专业人士来说都是宝贵的参考资料,它不仅涵盖了基础概念,还包括了深度技术细节和实践应用。
430 ◾ Handbook on Session Initiation Protocol
some application servers (e.g., IVR systems) use bidirectional
early media to obtain information from the callers (e.g., the
PIN code of a calling card). us, it is not recommended
that operators disallow bidirectional early media. Instead,
operators should consider a remedy of charging early-media
exchanges that last too long, or stopping them at the media
level (according to the operator’s policy).
11.4.7.1.4 Limitations in Application Server Model
If the unknown, untrusted network or network with differ-
ent early-media policies is connected to a private SIP network
of a managed administrative domain (e.g., ird Generation
Partnership Project’s Internet Multimedia System [3GPP’s
IMS] network) via a gateway and the gateway becomes the
primary requestor of early media over this managed SIP net-
work, the application server model cannot be used for early
media. In this situation, the P-Early-Media header-based
early model described later can be used within a transitive
Trust Domain.
11.4.7.2 Gateway Model
e gateway model does not use any SIP signaling indica-
tion for early media as described earlier because unintelli-
gent gateways like IP–PSTN cannot differentiate between
the early media and the regular media. Although both early-
media models described in this document are superior to the
one specified in RFC 3261, the gateway model still presents a
set of issues. In particular, the gateway model does not work
well with forking. Nevertheless, the gateway model is needed
because some SIP entities (in particular, some gateways)
cannot implement the application server model. SIP uses
the offer–answer model to negotiate session parameters as
described earlier. An offer–answer exchange that takes place
before a final response for the INVITE is sent establishes an
early media session.
Early-media sessions terminate when a final response
for the INVITE is sent. If the final response is a 200 OK,
the early-media session transitions to a regular media ses-
sion. If the final response is a non-200 class final response,
the early-media session is simply terminated. Not surpris-
ingly, media exchanged within an early-media session is
referred to as early media. e gateway model consists
of managing early-media sessions using offer–answer
exchanges in reliable provisional responses, PRACKs, and
UPDATEs. e gateway model is seriously limited in the
presence of forking, as described in the following section.
erefore, its use is only acceptable when the UA cannot
distinguish between early and regular media, as described
later. In any other situation (the majority of UAs), use of
the application server model described earlier is strongly
recommended instead.
11.4.7.2.1 F or k ing
In the absence of forking, assuming that the initial INVITE
contains an offer, the gateway model does not introduce
media clipping. Following normal SIP procedures, the UAC
is ready to play any incoming media as soon as it sends the
initial offer in the INVITE. e UAS sends the answer in a
reliable provisional response and can send media as soon as
there is media to send. Even if the first media packets arrive
at the UAC before the 1xx response, the UAC will play them.
It should be noted that, in some situations, the UAC needs
to receive the answer before being able to play any media.
UAs in such a situation (e.g., quality of service, media autho-
rization, or media encryption is required) use preconditions
(RFC 4032, see Section 15.4.12) to avoid media clipping.
On the other hand, if the INVITE forks, the gateway model
may introduce media clipping. is happens when the UAC
receives different answers to its offer in several provisional
responses from different UASs. e UAC has to deal with
bandwidth limitations and early-media session selection.
If the UAC receives early media from different UASs, it
needs to present it to the user. If the early media consists of
audio, playing several audio streams to the user at the same
time may be confusing. On the other hand, other media
types (e.g., video) can be presented to the user at the same
time. For example, the UAC can build a mosaic with the
different inputs. However, even with media types that can be
played at the same time to the user, if the UAC has limited
bandwidth, it will not be able to receive early media from
all the different UASs at the same time. erefore, many
times, the UAC needs to choose a single early-media session
and mute those sending UPDATE requests. It is difficult
to decide which early-media sessions carry more important
information from the caller’s perspective. In fact, in some
scenarios, the UA cannot even correlate media packets with
their particular SIP early dialog. erefore, UACs typically
pick one early dialog randomly and mute the rest.
If one of the early-media sessions that was muted transi-
tions to a regular media session (i.e., the UAS sends a 2xx
response), media clipping is likely. e UAC typically sends
an UPDATE with a new offer (upon reception of the 200
OK for the INVITE) to unmute the media session. e UAS
cannot send any media until it receives the offer from the
UAC. erefore, if the caller starts speaking before the offer
from the UAC is received, his words will get lost. Having
the UAS send the UPDATE to unmute the media session
(instead of the UAC) does not avoid media clipping in the
backward direction, and it causes possible race conditions.
11.4.7.2.2 Ringing-Tone Generation
In the PSTN, telephone switches typically play ringing tones
for the caller, indicating that the callee is being alerted.
Early Media in SIP ◾ 431
When, where, and how these ringing tones are generated
has been standardized (i.e., the local exchange of the cal-
lee generates a standardized ringing tone while the callee is
being alerted). It makes sense for a standardized approach
to provide this type of feedback for the user in a homoge-
neous environment such as the PSTN, where all the termi-
nals have a similar user interface. is homogeneity is not
found among SIP UAs. SIP UAs have different capabilities,
different user interfaces, and may be used to establish ses-
sions that do not involve audio at all. Because of this, the
way a SIP UA provides the user with information about the
progress of session establishment is a matter of local policy.
For example, a UA with a Graphical User Interface (GUI)
may choose to display a message on the screen when the cal-
lee is being alerted, while another UA may choose to show a
picture of a phone ringing instead. Many SIP UAs choose to
imitate the user interface of PSTN phones.
ey provide a ringing tone to the caller when the callee
is being alerted. Such a UAC is supposed to generate ringing
tones locally for its user as long as no early media is received
from the UAS. If the UAS generates early media (e.g., an
announcement or a special ringing tone), the UAC is sup-
posed to play it rather than generate the ringing tone locally.
e problem is that, sometimes, it is not an easy task for a
UAC to know whether it will be receiving early media or it
should generate local ringing. A UAS can send early media
without using reliable provisional responses (very simple
UASs do that), or it can send an answer in a reliable provi-
sional response without any intention of sending early media
(this is the case when preconditions are used). erefore, by
only looking at the SIP signaling, a UAC cannot be sure
whether there will be early media for a particular session. e
UAC needs to check if media packets are arriving at a given
moment. An implementation could even choose to look at
the contents of the media packets, since they could carry only
silence or comfort noise. With this in mind, a UAC should
develop its local policy regarding local ringing generation.
For example, a POTS (Plain Old Telephone Service)-like SIP
UA could implement the following local policy:
◾ Unless a 180 Ringing response is received, never gener-
ate local ringing.
◾ If a 180 Ringing has been received but there are no
incoming media packets, generate local ringing.
◾ If a 180 Ringing has been received and there are
incoming media packets, play them and do not gener-
ate local ringing.
Note that a 180 Ringing response means that the cal-
lee is being alerted, and a UAS should send such a response
if the callee is being alerted, regardless of the status of the
early-media session. At first sight, such a policy may look dif-
ficult to implement in decomposed UAs (i.e., media gateway
controller and media gateway); however, this policy is the
same as the one described earlier, which must be imple-
mented by any UA. at is, any UA should play incoming
media packets (and stop local ringing tone generation if it
was being performed) to avoid media clipping, even if the
200 OK response has not arrived. us, the tools to imple-
ment this early-media policy are already available to any UA
that uses SIP.
Furthermore, while it is not desirable to standardize a
common local policy to be followed by every SIP UA, a par-
ticular subset of more or less homogeneous SIP UAs could
use the same local policy by convention. Examples of such
subsets of SIP UAs may be “all the PSTN/SIP gateways” or
“every 3GPP IMS terminal.” However, defining the particu-
lar common policy that such groups of SIP devices may use
is outside the scope of this document.
11.4.7.2.3 Absence of an Early-Media Indicator
e SIP, as opposed to other signaling protocols, does not
provide an early-media indicator. at is, there is no infor-
mation about the presence or absence of early media in SIP.
Such an indicator could be potentially used to avoid the
generation of local ringing tone by the UAC when UAS
intends to provide an in-band ringing tone or some type of
announcement. However, in the majority of the cases, such
an indicator would be of little use due to the way SIP works.
One important reason limiting the benefit of a potential
early-media indicator is the loose coupling between SIP sig-
naling and the media path. SIP signaling traverses a different
path than the media. e media path is typically optimized
to reduce the end-to-end delay (e.g., minimum number of
intermediaries), while the SIP signaling path typically tra-
verses a number of proxies providing different services for
the session. Hence, it is very likely that the media packets
with early media reach the UAC before any SIP message that
could contain an early-media indicator.
Nevertheless, sometimes SIP responses arrive at the UAC
before any media packet. ere are situations in which the UAS
intends to send early media but cannot do it straight away. For
example, UAs using Interactive Connectivity Establishment
(RFC 5245, see Section 14.3) may need to exchange several
Session Traversal of UDP through NAT (Network Address
Translation) (STUN) (RFC 5389, see Section 14.3) mes-
sages before being able to exchange media. In this situation,
an early-media indicator would keep the UAC from generat-
ing a local ringing tone during this time. However, while the
early media is not arriving at the UAC, the user would not be
aware that the remote user is being alerted, even though a 180
Ringing had been received. erefore, a better solution would
be to apply a local ringing tone until the early-media packets
could be sent from the UAS to the UAC. is solution does
not require any early-media indicator. Moreover, it should be
432 ◾ Handbook on Session Initiation Protocol
noted that migrations from local ringing tone to early media at
the UAC happen in the presence of forking as well; one UAS
sends a 180 Ringing response, and later, another UAS starts
sending early media.
11.4.7.2.4 Limitations of the Gateway Model
Most of the limitations of the gateway model are described
earlier. It produces media clipping in forking scenarios and
requires media detection to generate local ringing properly.
ese issues are addressed by the application server model,
described earlier, which is the recommended way of generat-
ing early media that is not continuous with the regular media
generated during the session. e gateway model allows for
individual networks to create local policy with respect to
the handling of early media, but does not address the case
where a network is interconnected with other networks
with unknown, untrusted, or different early-media policies.
In this situation, the P-Early-Media header-based model
described in RFC 5009 (Section 11.5) becomes a natural
extension of this gateway model that is applicable within a
transitive Trust Domain.
11.5 Early-Media Solution Model
with P-Early-Media Header
Like the earlier model, early media with the P-Early-Media
header model also provides the solution for early media in a
closed SIP network (e.g., 3GPP’s IMS network) under the
same administrative domain, and does not need to use the
Disposition-Type: Early-Media option tag, as explained earlier.
is header field is also useful in any SIP network that is inter-
connected with other SIP networks and needs to control the
flow of media in the early dialog state. is document defines
the use of the P-Early-Media header field for use within SIP
(RFC 3261) messages in certain SIP networks to authorize the
cut-through of backward or forward early media when permit-
ted by the early-media policies of the networks involved.
11.5.1 Early-Media Policy
e private P-Early-Media header field is intended for use in
a SIP network that has the following characteristics:
◾ Its early-media policy prohibits the exchange of early
media between end users.
◾ It is interconnected with other SIP networks that have
unknown, untrusted, or different policies regarding
early media.
◾ It has the capability to gate (enable/disable) the flow of
early media to/from user equipment.
Within an isolated SIP network, it is possible to gate early
media associated with all end points within the network to
enforce a desired early-media policy among network end
points. However, when a SIP network is interconnected with
other SIP networks, only the boundary node connected to the
external network can determine which early-media policy to
apply to a session established between end points on different
sides of the boundary. e P-Early-Media header field provides
a means for this boundary node to communicate this early-
media policy decision to other nodes within the network.
11.5.2 Early-Media Application Environments
e P-Early-Media header of SIP can only be applied in
closed networking environments. For example, a private
SIP network that emulates a traditional circuit switched
telephone network will benefit from using this header field.
Despite the limitations, there are sufficiently useful special-
ized deployments for the use of P-Early-Media in SIP net-
works under the following networking conditions:
1. e use of this private P-Early-Media header field is
only applicable inside a Trust Domain as defined in
RFC 3324 (see Section 10.5). Nodes in such a Trust
Domain are explicitly trusted by its users and end
systems to authorize early-media requests only when
allowed by the early-media policy within the Trust
Domain.
2. e private P-Early-Media header field cannot be
applied for a general early-media authorization com-
munications model suitable for interdomain use or use
in the Internet at large. Furthermore, since the early-
media requests are not cryptographically certified, they
are subject to forgery, replay, and falsification in any
architecture that does not meet the requirements of the
Trust Domain.
3. An early-media request also lacks an indication of who
specifically is making or modifying the request, and so
it must be assumed that the Trust Domain is making
the request. erefore, the information is only mean-
ingful when securely received from a node known to be
a member of the Trust Domain.
4. Although this extension can be used with parallel fork-
ing, it does not improve on the known problems with
early-media and parallel forking, as described in RFC
3960, unless one can assume the use of symmetric RTP.
11.5.3 Early-Media Authorization
PSTN networks typically provide call progress information
as backward early media from the terminating switch toward
the calling party. PSTN networks also use forward early
media from the calling party toward the terminating switch
Early Media in SIP ◾ 433
under some circumstances for applications, such as digit
collection for secondary dialing. PSTN networks typically
allow backward or forward early media since they are used
for the purpose of progressing the call to the answer state
and do not involve the exchange of data between end points.
In a SIP network, backward early media flows from the UAS
toward the UAC. Forward early media flows from the UAC
toward the UAS. SIP networks by default allow both forms of
early media, which may carry user data, once the media path
is established. Early media is typically desirable with a PSTN
gateway as UAS, but not with SIP user equipment as UAS.
To prevent the exchange of user data within early media
while allowing early media via PSTN gateways, a SIP network
may have a policy to prohibit backward early media from SIP
user equipment and to prohibit forward media toward SIP
user equipment, either of which may contain user data. A
SIP network containing both PSTN gateways and SIP end
devices, for example, can maintain such an early-media policy
by gating o any early media with a SIP end device acting as
UAS, gating on early media with a SIP end device acting as
UAC, and gating on early media at each PSTN gateway.
Unfortunately, a SIP network interconnected with
another SIP network may have no means of assuring that the
interconnected network is implementing a compatible early-
media policy, thus allowing the exchange of user data within
early media under some circumstances. For example, if a net-
work A allows all early media with user equipment as UAC
and an interconnected network B allows all early media with
user equipment as UAS, any session established between user
equipment as UAC in A and user equipment as UAS in B will
allow bidirectional user data exchange as early media. Other
combinations of early-media policies may also produce similar
undesirable results. e purpose of the P-Early-Media header
is to allow a SIP network interconnected to other SIP net-
works with different early-media policies to correctly identify
and enable authorized early media according to its policies.
11.5.3.1 Backward Early Media
Backward early media in the PSTN typically comprises call
progress information, such as ringing feedback (ringback),
or announcements regarding special handling such as for-
warding. It may also include requests for further informa-
tion, such as a credit card number to be entered as forward
early media in the form of DTMF tones or speech. Backward
early media of this type provides information to the calling
party strictly for the purpose of indicating that the call is
progressing and involves no exchange of data between end
users. e usual PSTN charging policy assumes that no data
is exchanged between users until the call has been answered.
A terminating SIP UA outside of the SIP network, on
the other hand, may provide any user data in a backward
early-media stream. us, if the network implements the
usual early-media policy, the network equipment gating the
backward early-media flow for the originating UA must dis-
tinguish between authorized early media from a terminating
SIP end point and unauthorized early media from another
SIP device outside of the network. Given the assumption of
a transitive trust relationship between SIP servers in the net-
work, this can be accomplished by including some informa-
tion in a backward SIP message that identifies the presence
of authorized backward early media.
Since it is necessary to verify that this indication comes
from a trusted source, it is necessary for each server on the
path back to the originating UA to be able to verify the trust
relationship with the previous server and to remove such an
indication when it cannot do so. A server on the boundary
to an untrusted SIP network can assure that no indication
of authorized backward early media passes from an exter-
nal UAS to a UAC within the network. us, the use of a
private header field that can be modified by SIP proxies is
to be preferred over the use of a Multipurpose Internet Mail
Extensions attachment that cannot be modified in this way.
11.5.3.2 Forward Early Media
Forward early media is less common than backward early
media in the PSTN. It is typically used to collect second-
ary dialed digits, to collect credit card numbers, or to collect
other DTMF or speech responses for the purpose of fur-
ther directing the call. Forward early media in the PSTN is
always directed toward a network server for the purpose of
indicating that a call is progressing and involves no exchange
of data between end users.
A terminating SIP UA outside of the SIP network, on
the other hand, may receive any user data in a forward early-
media stream. us, if the network implements the usual
early-media policy, the network equipment gating the for-
ward early-media flow for the originating UA must distin-
guish between a terminating end point that is authorized to
receive forward early media, and another SIP device outside
of the network that is not authorized to receive forward early
media containing user data. is authorization can be accom-
plished in the same manner as for backward early media by
including some information in a backward SIP message that
identifies that the terminating side is authorized to receive
forward early media.
11.5.4 Applicability of Content-Disposition
and Application/Gateway Model
e private P-Early-Media header can be applicable to the
gateway model defined in RFC 3960 (see Section 11.4.7),
since the PSTN gateway is the primary requestor of early
media in a private SIP network of a given administrative
domain (e.g., 3GPP’s IMS network). For the same reason,
434 ◾ Handbook on Session Initiation Protocol
neither the application server model of RFC 3960, nor the
early-session disposition type defined in RFC 3959 (see
Section 11.4) is applicable in this situation. e gateway
model of RFC 3960 allows for individual networks to create
local policy with respect to the handling of early media, but
does not address the case where a network is interconnected
with other networks with unknown, untrusted, or different
early-media policies. In this communications environment,
the P-Early-Media header like this is essential. Because with-
out the kind of information in the P-Early-Media header
field, it is not possible for the network to determine whether
cut-through of early media could lead to the transfer of data
between end users during session establishment. us, the
P-Early-Media header is a natural extension of the gateway
model of RFC 3960 that is applicable within a transitive
Trust Domain.
11.5.5 Operation
e P-Early-Media header field is used for the purpose of
requesting and authorizing requests for backward or for-
ward early media. A UAC capable of recognizing the
P-Early-Media header field may include the header field in
an INVITE request. e P-Early-Media header field in an
INVITE request contains the supported parameter. As mem-
bers of the Trust Domain, each proxy receiving an INVITE
request must decide whether to insert or delete the P-Early-
Media header field before forwarding. A UAS receiving an
INVITE request can use the presence of the P-Early-Media
header field in the request to decide whether to request early-
media authorization in subsequent messages toward the
UAC.
After receiving an incoming INVITE request, the UAS
requesting backward or forward early media will include
the P-Early-Media header field in a message toward the
UAC within the dialog, including direction parameter(s)
that identify for each media line in the session whether the
early-media request is for backward media, forward media,
both, or neither. e UAS can change its request for early
media by including a modified P-Early-Media header field
in a subsequent message toward the UAC within the dia-
log. Each proxy in the network receiving the P-Early-Media
header field in a message toward the UAC has the responsi-
bility of assuring that the early-media request comes from
an authorized source. If a P-Early-Media header field arrives
from either an untrusted source, a source not allowed to send
backward early media, or a source not allowed to receive for-
ward early media, then the proxy may remove the P-Early-
Media header field or alter the direction parameter(s) of the
P-Early-Media header field before forwarding the message,
based on local policy.
A proxy in the network not receiving the P-Early-Media
header field in a message toward the UAC may insert one
based on local policy. If the proxy also performs gating of
early media, then it uses the parameter(s) of the P-Early-
Media header field to decide whether to open or close the
gates for backward and forward early-media flow(s) between
the UAs. e proxy performing gating of early media may
also add a gated parameter to the P-Early-Media header field
before forwarding the message so that other gating proxies in
the path can choose to leave open their gates.
If the UAC is a trusted server within the network (e.g.,
a PSTN gateway), then the UAC may use the parameter(s)
of the P-Early-Media header field in messages received from
the UAS to decide whether to perform early-media gating
or cut-through, and to decide whether to render backward
early media in preference to generating ringback based on
the receipt of a 180 Ringing response. If the UAC is asso-
ciated with user equipment, then the network will have
assigned a proxy the task of performing early-media gating,
so that the parameter(s) of the P-Early-Media header field
received at such a UAC do not require that the UAC police
the early-media flow(s); however, they do provide additional
information that the UAC may use to render media. e
UAC and proxies in the network may also insert, delete, or
modify the P-Early-Media header field in messages toward
the UAS within the dialog according to local policy; how-
ever, the interpretation of the header field when used in this
way is a matter of local policy and not defined herein. e
use of direction parameter(s) in this header field could be
used to inform the UAS of the final early-media authoriza-
tion status.
11.5.6 Limitations of the P-Early-Media
Header Field
e P-Early-Media header field does not apply to any SDP
with Content-Disposition: Early-Session defined in RFC
3959 (see Section 11.4). When parallel forking occurs, there
is no reliable way to correlate early-media authorization in
a dialog with the media from the corresponding end point
unless one can assume the use of symmetric RTP, since the
SDP messages do not identify the RTP source address of any
media stream. When a UAC or proxy receives multiple early
dialogs and cannot accurately identify the source of each
media stream, it should use the most restrictive early-media
authorization it receives on any of the dialogs to decide the
policy to apply toward all received media.
When early-media usage is desired for any reason and
one cannot assume the use of symmetric RTP, it is advisable
to disable parallel forking using caller preferences defined in
RFC 3841. Although the implementation of media gating
is not defined in this specification (RFC 5009), note that
media gating must be implemented carefully in the presence
of NATs and protocols that aid in network address transla-
tion traversal. Media gating may also introduce a potential
剩余424页未读,继续阅读
2013-12-16 上传
2010-11-15 上传
2009-04-13 上传
2011-10-26 上传
2008-06-09 上传
2009-04-13 上传
2010-10-18 上传
2019-08-14 上传
milan_coder
- 粉丝: 0
- 资源: 3
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
最新资源
- JHU荣誉单变量微积分课程教案介绍
- Naruto爱好者必备CLI测试应用
- Android应用显示Ignaz-Taschner-Gymnasium取消课程概览
- ASP学生信息档案管理系统毕业设计及完整源码
- Java商城源码解析:酒店管理系统快速开发指南
- 构建可解析文本框:.NET 3.5中实现文本解析与验证
- Java语言打造任天堂红白机模拟器—nes4j解析
- 基于Hadoop和Hive的网络流量分析工具介绍
- Unity实现帝国象棋:从游戏到复刻
- WordPress文档嵌入插件:无需浏览器插件即可上传和显示文档
- Android开源项目精选:优秀项目篇
- 黑色设计商务酷站模板 - 网站构建新选择
- Rollup插件去除JS文件横幅:横扫许可证头
- AngularDart中Hammock服务的使用与REST API集成
- 开源AVR编程器:高效、低成本的微控制器编程解决方案
- Anya Keller 图片组合的开发部署记录
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功