📄 rfc2543.txt
字号:
Handley, et al. Standards Track [Page 14]
RFC 2543 SIP: Session Initiation Protocol March 1999
If TCP is used, request and responses within a single SIP transaction
are carried over the same TCP connection (see Section 10). Several
SIP requests from the same client to the same server MAY use the same
TCP connection or MAY use a new connection for each request.
If the client sent the request via unicast UDP, the response is sent
to the address contained in the next Via header field (Section 6.40)
of the response. If the request is sent via multicast UDP, the
response is directed to the same multicast address and destination
port. For UDP, reliability is achieved using retransmission (Section
10).
The SIP message format and operation is independent of the transport
protocol.
1.4.4 SIP Invitation
A successful SIP invitation consists of two requests, INVITE followed
by ACK. The INVITE (Section 4.2.1) request asks the callee to join a
particular conference or establish a two-party conversation. After
the callee has agreed to participate in the call, the caller confirms
that it has received that response by sending an ACK (Section 4.2.2)
request. If the caller no longer wants to participate in the call, it
sends a BYE request instead of an ACK.
The INVITE request typically contains a session description, for
example written in SDP (RFC 2327 [6]) format, that provides the
called party with enough information to join the session. For
multicast sessions, the session description enumerates the media
types and formats that are allowed to be distributed to that session.
For a unicast session, the session description enumerates the media
types and formats that the caller is willing to use and where it
wishes the media data to be sent. In either case, if the callee
wishes to accept the call, it responds to the invitation by returning
a similar description listing the media it wishes to use. For a
multicast session, the callee SHOULD only return a session
description if it is unable to receive the media indicated in the
caller's description or wants to receive data via unicast.
The protocol exchanges for the INVITE method are shown in Fig. 1 for
a proxy server and in Fig. 2 for a redirect server. (Note that the
messages shown in the figures have been abbreviated slightly.) In
Fig. 1, the proxy server accepts the INVITE request (step 1),
contacts the location service with all or parts of the address (step
2) and obtains a more precise location (step 3). The proxy server
then issues a SIP INVITE request to the address(es) returned by the
location service (step 4). The user agent server alerts the user
(step 5) and returns a success indication to the proxy server (step
Handley, et al. Standards Track [Page 15]
RFC 2543 SIP: Session Initiation Protocol March 1999
6). The proxy server then returns the success result to the original
caller (step 7). The receipt of this message is confirmed by the
caller using an ACK request, which is forwarded to the callee (steps
8 and 9). Note that an ACK can also be sent directly to the callee,
bypassing the proxy. All requests and responses have the same Call-
ID.
+....... cs.columbia.edu .......+
: :
: (~~~~~~~~~~) :
: ( location ) :
: ( service ) :
: (~~~~~~~~~~) :
: ^ | :
: | hgs@lab :
: 2| 3| :
: | | :
: henning | :
+.. cs.tu-berlin.de ..+ 1: INVITE : | | :
: : henning@cs.col: | \/ 4: INVITE 5: ring :
: cz@cs.tu-berlin.de ========================>(~~~~~~)=========>(~~~~~~) :
: <........................( )<.........( ) :
: : 7: 200 OK : ( )6: 200 OK ( ) :
: : : ( work ) ( lab ) :
: : 8: ACK : ( )9: ACK ( ) :
: ========================>(~~~~~~)=========>(~~~~~~) :
+.....................+ +...............................+
====> SIP request
....> SIP response
^
| non-SIP protocols
|
Figure 1: Example of SIP proxy server
The redirect server shown in Fig. 2 accepts the INVITE request (step
1), contacts the location service as before (steps 2 and 3) and,
instead of contacting the newly found address itself, returns the
address to the caller (step 4), which is then acknowledged via an ACK
Handley, et al. Standards Track [Page 16]
RFC 2543 SIP: Session Initiation Protocol March 1999
request (step 5). The caller issues a new request, with the same
call-ID but a higher CSeq, to the address returned by the first
server (step 6). In the example, the call succeeds (step 7). The
caller and callee complete the handshake with an ACK (step 8).
The next section discusses what happens if the location service
returns more than one possible alternative.
1.4.5 Locating a User
A callee may move between a number of different end systems over
time. These locations can be dynamically registered with the SIP
server (Sections 1.4.7, 4.2.6). A location server MAY also use one or
more other protocols, such as finger (RFC 1288 [17]), rwhois (RFC
2167 [18]), LDAP (RFC 1777 [19]), multicast-based protocols [20] or
operating-system dependent mechanisms to actively determine the end
system where a user might be reachable. A location server MAY return
several locations because the user is logged in at several hosts
simultaneously or because the location server has (temporarily)
inaccurate information. The SIP server combines the results to yield
a list of a zero or more locations.
The action taken on receiving a list of locations varies with the
type of SIP server. A SIP redirect server returns the list to the
client as Contact headers (Section 6.13). A SIP proxy server can
sequentially or in parallel try the addresses until the call is
successful (2xx response) or the callee has declined the call (6xx
response). With sequential attempts, a proxy server can implement an
"anycast" service.
If a proxy server forwards a SIP request, it MUST add itself to the
beginning of the list of forwarders noted in the Via (Section 6.40)
headers. The Via trace ensures that replies can take the same path
back, ensuring correct operation through compliant firewalls and
avoiding request loops. On the response path, each host MUST remove
its Via, so that routing internal information is hidden from the
callee and outside networks. A proxy server MUST check that it does
not generate a request to a host listed in the Via sent-by, via-
received or via-maddr parameters (Section 6.40). (Note: If a host has
several names or network addresses, this does not always work. Thus,
each host also checks if it is part of the Via list.)
A SIP invitation may traverse more than one SIP proxy server. If one
of these "forks" the request, i.e., issues more than one request in
response to receiving the invitation request, it is possible that a
client is reached, independently, by more than one copy of the
Handley, et al. Standards Track [Page 17]
RFC 2543 SIP: Session Initiation Protocol March 1999
invitation request. Each of these copies bears the same Call-ID. The
user agent MUST return the same status response returned in the first
response. Duplicate requests are not an error.
1.4.6 Changing an Existing Session
In some circumstances, it is desirable to change the parameters of an
existing session. This is done by re-issuing the INVITE, using the
same Call-ID, but a new or different body or header fields to convey
the new information. This re INVITE MUST have a higher CSeq than any
previous request from the client to the server.
For example, two parties may have been conversing and then want to
add a third party, switching to multicast for efficiency. One of the
participants invites the third party with the new multicast address
and simultaneously sends an INVITE to the second party, with the new
multicast session description, but with the old call identifier.
1.4.7 Registration Services
The REGISTER request allows a client to let a proxy or redirect
server know at which address(es) it can be reached. A client MAY also
use it to install call handling features at the server.
1.5 Protocol Properties
1.5.1 Minimal State
A single conference session or call involves one or more SIP
request-response transactions. Proxy servers do not have to keep
state for a particular call, however, they MAY maintain state for a
single SIP transaction, as discussed in Section 12. For efficiency, a
server MAY cache the results of location service requests.
1.5.2 Lower-Layer-Protocol Neutral
SIP makes minimal assumptions about the underlying transport and
network-layer protocols. The lower-layer can provide either a packet
or a byte stream service, with reliable or unreliable service.
In an Internet context, SIP is able to utilize both UDP and TCP as
transport protocols, among others. UDP allows the application to more
carefully control the timing of messages and their retransmission, to
perform parallel searches without requiring TCP connection state for
each outstanding request, and to use multicast. Routers can more
readily snoop SIP UDP packets. TCP allows easier passage through
existing firewalls.
Handley, et al. Standards Track [Page 18]
RFC 2543 SIP: Session Initiation Protocol March 1999
+....... cs.columbia.edu .......+
: :
: (~~~~~~~~~~) :
: ( location ) :
: ( service ) :
: (~~~~~~~~~~) :
: ^ | :
: | hgs@lab :
: 2| 3| :
: | | :
: henning| :
+.. cs.tu-berlin.de ..+ 1: INVITE : | | :
: : henning@cs.col: | \/ :
: cz@cs.tu-berlin.de =======================>(~~~~~~) :
: | ^ | <.......................( ) :
: | . | : 4: 302 Moved : ( ) :
: | . | : hgs@lab : ( work ) :
: | . | : : ( ) :
: | . | : 5: ACK : ( ) :
: | . | =======================>(~~~~~~) :
: | . | : : :
+.......|...|.........+ : :
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -