session
Click on the red underlined text to get to the source
... Internet that require the creation
and management of a session, where a session is considered an
exchange of data ...
... and management of a session, where a session is considered an
exchange of data between an association ...
... different media - sometimes simultaneously. Numerous protocols have
been authored that carry various forms of real-time multimedia
session data such as voice, video, or text messages. The Session
Initiation Protocol ...
... multimedia
session data such as voice, video, or text messages. The Session
Initiation Protocol (SIP) works in concert with these protocols by
...
... endpoints (called user agents) to discover one
another and to agree on a characterization of a session they would
like to share. For locating prospective session participants, and
...
... another and to agree on a characterization of a session they would
like to share. For locating prospective session participants, and
for other functions, SIP enables the creation of an infrastructure of
...
... user agents can send
registrations, invitations to sessions, and other requests. SIP is
an agile, general-purpose tool ...
... an agile, general-purpose tool for creating, modifying, and
terminating sessions that works independently of underlying transport
protocols and without dependency on the type of session that is being
...
... terminating sessions that works independently of underlying transport
protocols and without dependency on the type of session that is being
established.
...
... application-layer control protocol that can establish,
modify, and terminate multimedia sessions (conferences) such as
Internet telephony calls. SIP ...
... Internet telephony calls. SIP can also invite participants to
already existing sessions, such as multicast conferences. Media can
be added to (and removed ...
... multicast conferences. Media can
be added to (and removed from) an existing session. SIP
transparently supports name mapping and redirection services ...
... to be used;
Session setup: "ringing", establishment of session parameters at
both called and calling party;
...
...
Session setup: "ringing", establishment of session parameters at
both called and calling party;
...
... both called and calling party;
Session management: including transfer and termination of
sessions, modifying session parameters ...
... Session management: including transfer and termination of
sessions, modifying session parameters, and invoking
services ...
... Session management: including transfer and termination of
sessions, modifying session parameters, and invoking
services.
...
... Public Switched Telephone Network (PSTN), and the
Session Description Protocol (SDP) (RFC 2327(-> 4566prop) [1 ...
... 2327(-> 4566prop) [1]) for describing
multimedia sessions. Therefore, SIP should be used in conjunction
...
... locate a user and deliver an opaque object to his current location.
If this primitive is used to deliver a session description written in
SDP, for instance, the endpoints ...
... SDP, for instance, the endpoints can agree on the parameters of a
session. If the same primitive is used to deliver a photo of the
caller as well as the session ...
... session. If the same primitive is used to deliver a photo of the
caller as well as the session description, a "caller ID" service can
...
... or voting and does not prescribe how a conference is to be managed.
SIP can be used to initiate a session that uses some other conference
control protocol. Since SIP messages ...
... control protocol. Since SIP messages and the sessions they establish
can pass through entirely different networks, SIP ...
... SIP: location of an
end point, signal of a desire to communicate, negotiation of session
parameters to establish the session, and teardown of the session once
...
... end point, signal of a desire to communicate, negotiation of session
parameters to establish the session, and teardown of the session once
established.
...
... negotiation of session
parameters to establish the session, and teardown of the session once
established.
...
... SIP phone over the Internet. Also shown are two SIP proxy
servers that act on behalf of Alice and Bob to facilitate the session
establishment. This typical arrangement is often referred to as the
"SIP trapezoid" as shown by the geometric shape of the dotted lines
...
... unique identifier for the call, the destination
address, Alice's address, and information about the type of session
that Alice wishes to establish with Bob. The INVITE (message F1 in
...
... ACK F12 |
|------------------------------------------------->|
| Media Session |
|<================================================>|
| BYE F13 |
...
... SIP header fields is defined in Section 20.
The details of the session, such as the type of media, codec, or
...
... SIP. Rather, the body of a
SIP message contains a description of the session, encoded in some
other protocol format. One such format is the Session Description
Protocol (SDP ...
... SIP message contains a description of the session, encoded in some
other protocol format. One such format is the Session Description
Protocol (SDP) (RFC 2327(-> 4566prop) [1 ...
... message body
with the SDP media description of the type of session that Bob is
willing to establish with Alice. As a result, there is a two-phase
exchange of SDP ...
... error response would have been sent instead of the
200 (OK), which would have resulted in no media session being
established. The complete list of SIP response codes ...
... SIP sessions. Full details on session setup are in Section 13.
Alice and Bob's media session ...
... session setup are in Section 13.
Alice and Bob's media session has now begun, and they send media
packets using the format to which they agreed in the exchange of SDP.
...
... signaling messages.
During the session, either Alice or Bob may decide to change the
characteristics of the media session. This is accomplished by
...
... During the session, either Alice or Bob may decide to change the
characteristics of the media session. This is accomplished by
sending a re-INVITE containing a new media description. This re-
...
... INVITE references the existing dialog so that the other party knows
that it is to modify an existing session instead of establishing a
new session. The other party sends a 200 (OK) to accept the change.
...
... that it is to modify an existing session instead of establishing a
new session. The other party sends a 200 (OK) to accept the change.
The requestor responds to the 200 (OK) with an ACK. If the other
...
... failure of the re-INVITE does not cause the existing call to fail -
the session continues using the previously negotiated
characteristics. Full details on session modification are in Section
...
... the session continues using the previously negotiated
characteristics. Full details on session modification are in Section
14.
...
... softphone, again bypassing the proxies. Alice confirms receipt of
the BYE with a 200 (OK) response, which terminates the session and
the BYE transaction. No ACK ...
... methods besides INVITE. Full details
on session termination are in Section 15.
Section 24.2 describes the messages shown in Figure 1 in full.
...
... to see all the messaging between the endpoints for the duration of
the session. For example, if the biloxi.com proxy server wished to
remain in the SIP ...
... INVITE method, which is used
to establish a session between participants. A session is a
collection of participants, and streams of media between them, for
...
... method, which is used
to establish a session between participants. A session is a
collection of participants, and streams of media between them, for
the purposes of communication. Section 13 discusses how sessions ...
... session is a
collection of participants, and streams of media between them, for
the purposes of communication. Section 13 discusses how sessions are
initiated, resulting in one or more SIP dialogs. Section 14
...
... initiated, resulting in one or more SIP dialogs. Section 14
discusses how characteristics of that session are modified through
the use of an INVITE request within a dialog. Finally, section 15
...
... the use of an INVITE request within a dialog. Finally, section 15
discusses how a session is terminated.
The procedures of Sections 8, 10, 11, 12, 13, 14, and 15 deal
...
... clients.
Conference: A multimedia session (see below) that contains
multiple participants.
...
... Initiator, Calling Party, Caller: The party initiating a session
(and dialog) with an INVITE request. A caller ...
... receives an INVITE request for the purpose of establishing a
new session. A callee retains this role from the time it
receives the INVITE ...
... Session: From the SDP specification: "A multimedia session is a
set of multimedia senders and receivers ...
... senders to receivers. A multimedia conference is
an example of a multimedia session." (RFC 2327(-> 4566prop) [1]) (A session ...
... multimedia session." (RFC 2327(-> 4566prop) [1]) (A session
as defined for SDP can comprise one or more RTP sessions ...
... session
as defined for SDP can comprise one or more RTP sessions.) As
defined, a callee can be invited several times, by different
calls, to the same session ...
... RTP sessions.) As
defined, a callee can be invited several times, by different
calls, to the same session. If SDP is used, a session is
...
... calls, to the same session. If SDP is used, a session is
defined by the concatenation of the SDP ...
... ACK, and CANCEL for
setting up sessions, BYE for terminating sessions, and
OPTIONS for querying servers about their capabilities. SIP ...
... setting up sessions, BYE for terminating sessions, and
OPTIONS for querying servers about their capabilities. SIP
...
...
Content-Disposition: session;handling=optional
is equivalent to
...
... 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
...
... Examples of requests sent outside of a dialog include an INVITE to
establish a session (Section 13) and an OPTIONS to query for
capabilities (Section 11).
...
... identifiers provides some
protection against session hijacking and reduces the likelihood of
unintentional Call-ID ...
... UAC MUST treat any provisional response different than 100 that it
does not recognize as 183 (Session Progress). A UAC MUST be able to
process 100 and 183 responses.
...
... final response for the original request. If it has, the CANCEL
request has no effect on the processing of the original request, no
effect on any session state, and no effect on the responses generated
for the original request. If the UAS ...
... SIP offers a discovery capability. If a user wants to initiate a
session with another user, SIP must discover the current host(s) at
...
... method specific. In this
specification, the BYE method terminates a session and the dialog
associated with it. See Section 15 for details.
...
... Initiating a Session ...
...
When a user agent client desires to initiate a session (for example,
audio, video, or a game), it formulates an INVITE ...
... INVITE request. The
INVITE request asks a server to establish a session. This request
may be forwarded by proxies, eventually arriving at one or more UAS ...
...
invitation. After some time, those UASs can accept the invitation
(meaning the session is to be established) by sending a 2xx response.
If the invitation is not accepted, a 3xx, 4xx, 5xx or 6xx response is
sent, depending on the reason for the rejection. Before sending a
...
...
A 2xx response to an INVITE establishes a session, and it also
creates a dialog between the UA ...
... are part of the same call.
This section provides details on the establishment of a session using
INVITE. A UA ...
... INVITE. The Accept header field
is especially useful for indicating support of various session
description formats.
...
...
There are special rules for message bodies that contain a session
description - their corresponding Content-Disposition is "session ...
... session
description - their corresponding Content-Disposition is "session".
SIP uses an offer/answer model ...
... SIP uses an offer/answer model where one UA sends a session
description, called the offer, which contains a proposed description
of the session ...
... session
description, called the offer, which contains a proposed description
of the session. The offer indicates the desired communications means
(audio, video, games), parameters of those means (such as codec ...
... receiving media from the answerer. The
other UA responds with another session description, called the
answer, which indicates which communications means are accepted, the
parameters that apply to those means, and addresses ...
... answer MAY also be placed in any provisional responses sent
prior to the answer. The UAC MUST treat the first session
description it receives as the answer, and MUST ignore any
session descriptions ...
... session
description it receives as the answer, and MUST ignore any
session descriptions in subsequent responses to the initial
INVITE.
...
... INVITE MUST support these two exchanges.
The Session Description Protocol (SDP) (RFC 2327(-> 4566prop) [1 ...
... 1]) MUST be
supported by all user agents as a means to describe sessions, and its
usage for constructing offers and answers MUST follow the procedures
defined in [13 ...
... to bodies whose Content-Disposition header field value is "session".
Therefore, it is possible that both the INVITE and the ACK ...
... INVITE carries a photo (Content-
Disposition: render) and the ACK a session description (Content-
Disposition: session)).
...
... Content-Type application/sdp imply the disposition "session", while
other content types imply "render".
...
... method-independent
processing described in Section 12.2.2 is first applied. It
might also modify the session; Section 14 provides details.
3. If the request has a tag ...
... Processing from here forward assumes that the INVITE is outside of a
dialog, and is thus for the purposes of establishing a new session.
The INVITE ...
...
The INVITE may contain a session description, in which case the UAS
is being presented with an offer for that session ...
... session description, in which case the UAS
is being presented with an offer for that session. It is possible
that the user is already a participant in that session, even though
...
... is being presented with an offer for that session. It is possible
that the user is already a participant in that session, even though
the INVITE is outside of a dialog. This can happen when a user is
...
... UAS MAY use identifiers within the
session description to detect this duplication. For example, SDP
...
... SDP
contains a session id and version number in the origin (o) field. If
the user is already a member of the session ...
... session id and version number in the origin (o) field. If
the user is already a member of the session, and the session
parameters contained in the session description have not changed, the
...
... version number in the origin (o) field. If
the user is already a member of the session, and the session
parameters contained in the session description have not changed, the
UAS ...
... the user is already a member of the session, and the session
parameters contained in the session description have not changed, the
UAS MAY silently accept the INVITE ...
...
If the INVITE does not contain a session description, the UAS is
being asked to participate in a session ...
... session description, the UAS is
being asked to participate in a session, and the UAC has asked that
the UAS ...
... UAC has asked that
the UAS provide the offer of the session. It MUST provide the offer
in its first non-failure reliable message back to the UAC. In this
...
... receiving an ACK, the dialog is confirmed, but the session SHOULD be
terminated. This is accomplished with a BYE, as described in Section
15.
...
... Modifying an Existing Session ...
... INVITE request (see Section 13) establishes both a
dialog between two user agents and a session using the offer-answer
model. Section 12 explains how to modify an existing dialog using a
...
... URI
of the dialog). This section describes how to modify the actual
session. This modification can involve changing addresses or ports,
...
... accomplished by sending a new INVITE request within the same dialog
that established the session. An INVITE request sent within an
existing dialog is known as a re-INVITE ...
... Note that a single re-INVITE can modify the dialog and the
parameters of the session at the same time.
Either the caller ...
...
The same offer-answer model that applies to session descriptions in
INVITEs (Section 13.2.1) applies to re-INVITEs. As a result, a UAC
...
... INVITE
request to its peer. It is important to note that the full
description of the session, not just the change, is sent. This
supports stateless session ...
... session, not just the change, is sent. This
supports stateless session processing in various elements, and
supports failover and recovery capabilities. Of course, a UAC ...
...
send a re-INVITE with no session description, in which case the first
reliable non-failure response to the re-INVITE will contain the offer
...
... (in this specification, that is a 2xx response).
If the session description format has the capability for version
numbers, the offerer SHOULD indicate that the version of the session ...
... session description format has the capability for version
numbers, the offerer SHOULD indicate that the version of the session
description has changed.
...
... If a UA receives a non-2xx final response to a re-INVITE, the session
parameters MUST remain unchanged, as if no re-INVITE had been issued.
Note that, as stated in Section 12.2.1.2, if the non-2xx final
...
... UAC SHOULD attempt the re-INVITE once more,
if it still desires for that session modification to take place. For
example, if the call was already hung up with a BYE, the re-INVITE
...
... no version identifiers, the content of the session description to see
if it has changed. If the session description has changed, the UAS ...
... identifiers, the content of the session description to see
if it has changed. If the session description has changed, the UAS
MUST adjust the session parameters ...
... session description has changed, the UAS
MUST adjust the session parameters accordingly, possibly after asking
the user for confirmation.
...
... the user for confirmation.
Versioning of the session description can be used to accommodate
the capabilities of new arrivals to a conference, add or delete
...
... multicast conference.
If the new session description is not acceptable, the UAS can reject
it by returning a 488 (Not Acceptable Here) response for the re-
...
... subject to the constraints of sending an offer that
updates an existing session, as described in [13] in the case of SDP.
...
... UA is willing to support. The UAS MUST
ensure that the session description overlaps with its previous
session description in media formats ...
... ensure that the session description overlaps with its previous
session description in media formats, transports, or other parameters
...
... transports, or other parameters
that require support from the peer. This is to avoid the need for
the peer to reject the session description. If, however, it is
unacceptable to the UAC, the UAC ...
... UAC SHOULD generate an answer with a
valid session description, and then send a BYE to terminate the
session.
...
... Terminating a Session ...
...
This section describes the procedures for terminating a session
established by SIP. The state ...
... established by SIP. The state of the session and the state of the
dialog are very closely related. When a session ...
... session and the state of the
dialog are very closely related. When a session is initiated with an
INVITE, each 1xx or 2xx response from a distinct UAS ...
... offer/answer exchange, it
also creates a session. As a result, each session is "associated"
with a single dialog - the one which resulted in its creation. If an
...
... also creates a session. As a result, each session is "associated"
with a single dialog - the one which resulted in its creation. If an
initial INVITE ...
... initial INVITE generates a non-2xx final response, that terminates
all sessions (if any) and all dialogs (if any) that were created
through responses to the request. By virtue of completing the
...
... through responses to the request. By virtue of completing the
transaction, a non-2xx final response also prevents further sessions
from being created as a result of the INVITE ...
... created as a result of the INVITE. The BYE request is
used to terminate a specific session or attempted session. In this
case, the specific session ...
... INVITE. The BYE request is
used to terminate a specific session or attempted session. In this
case, the specific session is the one with the peer UA ...
... session or attempted session. In this
case, the specific session is the one with the peer UA on the other
side of the dialog. When a BYE is received on a dialog, any session ...
... session is the one with the peer UA on the other
side of the dialog. When a BYE is received on a dialog, any session
associated with that dialog SHOULD terminate. A UA MUST NOT send a
...
... The impact of a non-2xx final response to INVITE on dialogs and
sessions makes the use of CANCEL attractive. The CANCEL attempts to
force a non-2xx response to the INVITE (in particular, a 487).
...
... UAS accepted the invitation while
the CANCEL was in progress. The UAC MAY continue with the sessions
established by any 2xx responses, or MAY terminate them with BYE.
...
... user interface.
Typically, when the user hangs up, it indicates a desire to
terminate the attempt to establish a session, and to terminate any
sessions already created ...
... terminate the attempt to establish a session, and to terminate any
sessions already created. For the caller's UA ...
... Terminating a Session with a BYE Request ...
... transaction, and passes it the BYE request. The UAC MUST
consider the session terminated (and therefore stop sending or
listening for media) as soon as the BYE request is passed to the
client ...
... the procedures of Section 12.2.2 to process the request. Once done,
the UAS SHOULD terminate the session (and therefore stop sending and
listening for media). The only case where it can elect not to are
multicast ...
... listening for media). The only case where it can elect not to are
multicast sessions, where participation is possible even if the other
participant in the dialog has terminated its involvement in the
session ...
... sessions, where participation is possible even if the other
participant in the dialog has terminated its involvement in the
session. Whether or not it ends its participation on the session,
the UAS ...
... participant in the dialog has terminated its involvement in the
session. Whether or not it ends its participation on the session,
the UAS core MUST generate a 2xx response to the BYE, and MUST pass
...
... email messages,
or printed literature. They contain sufficient information to
initiate and maintain a communication session with the resource.
Examples of communications resources include the following:
...
... possible to specify the subject, media type, or urgency of sessions
initiated by using a URI on a web page or in an email ...
... INVITE. This is needed in order for a UA to
invite itself to a session, a common case for "hairpinning" of calls
in PSTN gateways ...
... header field is used in requests to indicate the
preferred languages for reason phrases, session descriptions, or
status responses carried as message bodies in the response. If no
...
... header are
defined by SIP. The value "session" indicates that the body part
describes a session, for either calls or early (pre-call ...
... SIP. The value "session" indicates that the body part
describes a session, for either calls or early (pre-call) media. The
value "render" indicates that the body part should be displayed or
...
... Content-Type
application/sdp are the disposition "session", while other content
types are "render".
...
...
Content-Disposition: session
...
... it were a Contact in a redirect and generate a new INVITE, resulting
in a recorded announcement session being established. A non-SIP URI
MAY be rendered to the user.
...
... The expiration time in an INVITE does not affect the duration of the
actual session that may result from the invitation. Session
description protocols may offer the ability to express time limits on
...
... INVITE does not affect the duration of the
actual session that may result from the invitation. Session
description protocols may offer the ability to express time limits on
the session ...
... Session
description protocols may offer the ability to express time limits on
the session duration, however.
The value of this field is an integral number of seconds (in decimal)
...
... header field. For example, the URI MAY be
used to return missed calls or unestablished sessions. If the user
wished to remain anonymous, the header field SHOULD either be omitted
...
... of the call, allowing call filtering without having to parse the
session description. The session description does not have to use
the same subject ...
... filtering without having to parse the
session description. The session description does not have to use
the same subject indication as the invitation.
...
... The currently-defined "warn-code"s are listed below, with a
recommended warn-text in English and a description of their meaning.
These warnings describe failures induced by the session description.
The first digit of warning codes beginning with "3" indicates
warnings specific to SIP ...
... warnings specific to SIP. Warnings 300 through 329 are reserved for
indicating problems with keywords in the session description, 330
through 339 are warnings related to basic network services requested
...
... through 339 are warnings related to basic network services requested
in the session description, 370 through 379 are warnings related to
quantitative QoS parameters requested in the session ...
... session description, 370 through 379 are warnings related to
quantitative QoS parameters requested in the session description, and
390 through 399 are miscellaneous warnings that do not fall into one
of the above categories.
...
... network protocol: One or more network protocols
contained in the session description are not available.
301 Incompatible network ...
... 302 Incompatible transport protocol: One or more transport
protocols described in the session description are not
available.
...
... bandwidth units: One or more bandwidth
measurement units contained in the session description were
not understood.
...
... Media type not available: One or more media types contained in
the session description are not available.
305 Incompatible media format ...
... media format: One or more media formats contained
in the session description are not available.
306 Attribute not understood: One or more of the media attributes
...
...
306 Attribute not understood: One or more of the media attributes
in the session description are not supported.
307 Session ...
... session description are not supported.
307 Session description parameter not understood: A parameter
other than those listed above was not understood.
...
... 370 Insufficient bandwidth: The bandwidth specified in the session
description or defined by the media exceeds that known to be
available.
...
... Examples:
Warning: 307 isi.edu "Session parameter 'foo' not understood"
Warning: 301 isi.edu "Incompatible network address type ...
... ACK. Provisional (1xx)
responses MAY contain message bodies, including session descriptions.
...
... 183 Session Progress ...
...
The 183 (Session Progress) response is used to convey information
about the progress of the call that is not otherwise classified. The
Reason-Phrase, header fields ...
... The user's agent was contacted successfully but some aspects of the
session description such as the requested media, bandwidth, or
addressing ...
...
A 606 (Not Acceptable) response means that the user wishes to
communicate, but cannot adequately support the session described.
The 606 (Not Acceptable) response MAY contain a list of reasons in a
Warning header field ...
... The 606 (Not Acceptable) response MAY contain a list of reasons in a
Warning header field describing why the session described cannot be
supported. Warning reason codes are listed in Section 20.43.
...
... MIME body that is not secured, the UAC
SHOULD notify its user that the session could not be secured.
However, if a user agent that supports S/MIME ...
... identity on its keychain),
the UAS SHOULD notify its user that the session could not be secured.
A number of conditions that arise in the previous text call for the
...
... Session Setup ...
...
This example contains the full details of the example session setup
in Section 4. The message flow is shown in Figure 1. Note that
...
... Content-Length: 0
The media session between Alice and Bob is now established.
Bob hangs up first. Note that Bob's SIP ...
... / "181" ; Call Is Being Forwarded
/ "182" ; Queued
/ "183" ; Session Progress
Success = "200" ; OK
...
... Content-Disposition" HCOLON
disp-type *( SEMI disp-param )
disp-type = "render" / "session" / "icon" / "alert"
/ disp-extension-token ...
... Consider a UA that is using SIP message bodies to communicate session
encryption keys for a media session ...
... session
encryption keys for a media session. Although it trusts the proxy
server of the domain it is contacting to deliver signaling ...
... administrators of that domain to be capable of
decrypting any subsequent media session. Worse yet, if the proxy
server were actively malicious, it could modify the session key,
...
... decrypting any subsequent media session. Worse yet, if the proxy
server were actively malicious, it could modify the session key,
either acting as a man-in-the-middle, or perhaps changing the
...
... UA.
This family of threats applies not only to session keys, but to most
conceivable forms of content carried end-to-end in SIP ...
... Tearing Down Sessions ...
... requests can be sent that modify the state of the dialog and/or
session. It is critical that principals in a session ...
... session. It is critical that principals in a session can be certain
that such requests are not forged by attackers.
...
... captures some initial
messages in a dialog shared by two parties in order to learn the
parameters of the session (To tag, From tag, and so forth) and then
...
... tag, From tag, and so forth) and then
inserts a BYE request into the session. The attacker could opt to
forge the request such that it seemed to come from either
...
... forge the request such that it seemed to come from either
participant. Once the BYE is received by its target, the session
will be torn down prematurely.
...
... will be torn down prematurely.
Similar mid-session threats include the transmission of forged re-
INVITEs that alter the session (possibly to reduce session ...
... Similar mid-session threats include the transmission of forged re-
INVITEs that alter the session (possibly to reduce session security
...
... session threats include the transmission of forged re-
INVITEs that alter the session (possibly to reduce session security
or redirect media streams ...
... sender). Also, if the
attacker is unable to learn the parameters of the session due to
confidentiality, it would not be possible to forge the BYE. However,
...
... some intermediaries (like proxy servers) will need to inspect those
parameters as the session is established.
...
... register some or all users in an administrative
domain, thereby preventing these users from being invited to new
sessions. An attacker could also register a large number of contacts
...
... authentication and privacy of
the participants in a session, and preventing denial-of-service
attacks. Bodies within SIP messages separately require the security
services ...
...
Now let's say that Alice's UA would like to initiate a session with a
user in a remote administrative domain, namely "bob@biloxi.com". We
...
... stream between Bob and Alice because the attacker has no way of
ascertaining the parameters of the session and also because the
integrity mechanism transitively protects the traffic ...
... SIP to establish a
voice communications session, each could read off the fingerprint of
the key they received from the other, which could be compared against
...
... senders - not just what they have to say, but with whom they
communicate, when they communicate and for how long, and from where
they participate in sessions. Many applications and their users
require that this sort of private information be hidden from any
parties that do not need to know it.
...
... service can
infringe on the privacy of the recipient of a session invitation by
divulging their specific whereabouts to the caller; an implementation
...
... SIP response messages when the failure of the transaction results
from a Session Description Protocol (SDP) (RFC 2327(-> 4566prop) [1 ...
...
Warnings 300 through 329 are reserved for indicating problems with
keywords in the session description, 330 through 339 are warnings
related to basic network services requested in the session ...
... session description, 330 through 339 are warnings
related to basic network services requested in the session
description, 370 through 379 are warnings related to quantitative QoS
...
... description, 370 through 379 are warnings related to quantitative QoS
parameters requested in the session description, and 390 through 399
are miscellaneous warnings that do not fall into one of the above
categories.
...
... header
"disposition-types": alert, icon, session and render. The authors
request that these values be recorded in the IANA registry for
...
... icon the body is displayed as an icon to the user
render the body should be displayed to the user
session the body describes a communications session, for
example, as RFC 2327(-> 4566prop) ...
... icon the body is displayed as an icon to the user
render the body should be displayed to the user
session the body describes a communications session, for
example, as RFC 2327(-> 4566prop) ...
... render the body should be displayed to the user
session the body describes a communications session, for
example, as RFC 2327(-> 4566prop) SDP ...
... Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327(-> 4566prop), April 1998. ...
... Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543(-> 3265prop | 3264prop | 3263prop | 3262prop | 3261prop), March 1999. ...