One document matched: draft-barnes-sip-em-ps-req-sol-00.txt
Network Working Group R. Barnes
Internet-Draft M. Lepinski
Intended status: Informational BBN Technologies
Expires: July 19, 2007 January 15, 2007
Early Media in SIP: Problem Statement, Requirements, and Analysis of
Solutions
draft-barnes-sip-em-ps-req-sol-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 19, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The Session Initiation Protocol (SIP) enables and permits endpoints
in an INVITE transaction to send media packets before an SDP offer/
answer exchange has completed; we refer to such media packets as
early media. The use of early media is common in current SIP
implementations, and causes several problems, which have been
documented elsewhere. This document puts forward the goal of
modifying SIP so that compliant implementations will complete an SDP
Barnes & Lepinski Expires July 19, 2007 [Page 1]
Internet-Draft em-ps-req-sol January 2007
exchange before sending media, and lays out high-level requirements
for such a solution. The set of possible solutions is then laid out,
and each possibility examined in light of these requirements.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Elmination of Early Media . . . . . . . . . . . . . . . . 5
2.2. Additional Messaging . . . . . . . . . . . . . . . . . . . 6
2.3. Interoperability with current SIP standards . . . . . . . 6
2.4. Interoperability with the PSTN . . . . . . . . . . . . . . 6
2.5. Denial of Service . . . . . . . . . . . . . . . . . . . . 6
2.6. IPR Constraints . . . . . . . . . . . . . . . . . . . . . 6
3. Early Media Solutions . . . . . . . . . . . . . . . . . . . . 6
3.1. Minimizing SDP completion time . . . . . . . . . . . . . . 7
3.1.1. Fast completion of INVITE transaction . . . . . . . . 7
3.1.2. Elimination of offer from INVITE . . . . . . . . . . . 8
3.1.3. Provisional Responses . . . . . . . . . . . . . . . . 8
3.1.4. Separate INVITE transaction . . . . . . . . . . . . . 9
3.1.5. Non-INVITE SIP Mechanisms . . . . . . . . . . . . . . 9
3.1.6. Non-SIP mechanisms . . . . . . . . . . . . . . . . . . 10
3.2. Handling remaining media . . . . . . . . . . . . . . . . . 11
3.2.1. Unreliable SDP answer . . . . . . . . . . . . . . . . 11
3.2.2. Backwards-compatibility . . . . . . . . . . . . . . . 11
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Barnes & Lepinski Expires July 19, 2007 [Page 2]
Internet-Draft em-ps-req-sol January 2007
1. Introduction
A primary function of the Session Initiation Protocol (SIP,
[RFC3261]) is to carry SDP messages that form an SDP offer/answer
exchange [RFC3264]. The offer/answer exchange serves to negotiate
the parameters necessary for the two end hosts to send multimedia to
each other, including transports, port numbers, codecs, and security
parameters (e.g., MIKEY [RFC3830]). In the most common SIP INVITE
transaction, the calling party (UAC) is the SDP offerer and the
called party (UAS) is the SDP answerer; in this scenario, the SDP
offer is carried in the SIP INVITE request, and the SDP answer in the
200/OK response.
Because there is often a substantial delay between the sending of an
INVITE and the receipt a 200/OK, this assignment of SDP messages to
SIP messages creates a substantial delay between an SDP offer and an
SDP answer. Consequently, there is a period of time between the two
messages in which the two parties have asymmetric information: The
called party has knowledge of both the SDP offered by the calling
party and of his own intended response, while the calling party knows
only the offer he sent. Given this information, the called party has
all the information he needs to begin sending media to the calling
party (because this was included in the SDP offer); moreover, he can
send these media without sending an SDP answer to the calling party.
We define early media as media sent before the completion of an SDP
offer/answer exchange.
Ours is a different definition than is used in RFC 3960 [RFC3960],
which defines early media as "media ... that is exchanged before a
particular session is accepted by the called user." The definition
in RFC 3960 is consistent with the current usage of SDP within the
SIP INVITE transaction, but at the same time conflates two functions
of SIP: Negotiation of session-layer parameters (through the SDP
offer/answer) and communication of an application-layer request and
acceptance of a session (by the INVITE and 200/OK messages). As
suggested above, it is this assignment of SDP messages to SIP
messages that creates the possibility of early media.
Early media is known to create several problems for SIP operation:
o Call failure: When endpoints use early media for an extended
period of time, timers can fire to close the UAC INVITE
transaction before the early media finish and the UAS sends a
200/OK. This causes the session proposed in the initial INVITE to
be dropped by the UAC, and in some implementations, the flow of
media is cut off.
Barnes & Lepinski Expires July 19, 2007 [Page 3]
Internet-Draft em-ps-req-sol January 2007
o Confidentiality: Techniques such as MIKEY [RFC3830]and Security
Descriptions [RFC4568], which use SDP to establish keys for media
security protocols, require a full SDP offer/answer exchange to
negotiate keys. Such keying techniques are therefore incompatible
with early media.
o Access Control: In the presence of early media, a UAC must
anticipate that media will arrive without any signaling, and thus
is obliged to receive (and presumably render) media received from
any host on the Internet.
o Interaction with forking/retargeting: When an INVITE from a UAC is
forked or retarget to UASs that send early media, because these
UASs send no signaling, the UAC has no information besides the
media itself on which to base a decision as to which media stream
to render.
o Denial of Service: Early media is the basis of the "voice hammer"
attack, described in [draft-ietf-mmusic-ice].
To date, attempts to deal with early media have failed to solve all
of the problems caused by early media. Such work typically has
started from the assumption that early media is a necessary component
of SIP (largely due to RFC 3398 [RFC3398] and RFC 3578 [RFC3578]) and
has generally avoided the issue of whether key use-cases (such as
PSTN interoperability) can be satisfied without the use of early
media. RFC 3960 presents two models for managing early media
streams, which mitigate early-media related problems in some cases.
However, the document neither specifies the models in sufficient
detail nor makes their implementation a mandatory part of SIP. More
recently, Stucker has written a draft extending 3960 by detailing a
more current set of early media coping mechanisms, and proposing a
solution that uses additional SDP attributes to mitigate the problems
caused by early media [draft-stucker-sipping-early-media-coping].
Although Stucker's proposed solution addresses several of the above
problems, it stops short of requiring an SDP exchange before media
transmission. Ejzak has also authored a recent draft regarding early
media [draft-ejzak-sipping-p-em-auth]. However, his draft proposes
the use of a p-header to prevent fraudulent uses of early media,
which are largely orthogonal to the early media problems considered
in this draft.
In contrast to previous approaches, this draft proposes to address
the problems of early media by normatively modifying the SIP protocol
to preclude the transmission of early media. In order to remove the
possibility of early media, this modification must ensure (to the
greatest extent possible) that the SDP offer/answer exchange has
completed before any media are sent. At a high level, this goal can
Barnes & Lepinski Expires July 19, 2007 [Page 4]
Internet-Draft em-ps-req-sol January 2007
be approached from two directions: To complete the SDP exchange as
quickly and reliably as possible, and to forbid sending of media
before completion. A successful solution will combine these two
approaches, since as progress is made on the former, the latter
becomes less onerous.
The goal of this draft is three-fold: First, in the above, we have
provided a consolidated statement of the early media problem, namely
that the presence of media before the completion of an SDP offer/
answer exchange is harmful to the functioning of SIP calls. Second,
Section 2 specifies requirements for an update to SIP that eliminates
early media, in an effort to consolidate the requirements that have
been presented to date and enable discussion of solutions. Third,
Section 3 lays out the space of possible solutions, enumerating the
trade-offs entailed by each so that consensus can be reached on the
direction that should be taken by the SIP working group.
2. Requirements
There have been several informal proposals to date that would
mitigate or eliminate early media, but each was disqualified in turn
by requirements as perceived by the SIP and SIPPING working groups.
In this section, we seek to create a consolidated set of requirements
so that a consistent evaluation of solutions can move forward.
Below, we use the term "proposed solution" to refer to a protocol
that normatively updates the relevant standards (e.g., RFCs 3261,
3264, and 3398) in such a way as to eliminate early media, while we
use the term "current SIP" to refer to SIP as defined in RFC 3261 and
related documents.
2.1. Elmination of Early Media
The proposed solution must define a normative modification to the SIP
protocol (and other relevant protocols) that minimizes or eliminates
the possibility of early media in SIP sessions; i.e., it should
minimize or eliminate the possibility that a compliant implementation
could send media before an SDP offer/answer exchange has completed.
Solutions in which receipt of SDP-bearing messages is explicitly
acknowledged (e.g., an INVITE/200/ACK or INVITE/180/PRACK exchange)
are preferred, since these acknowledgements are the only way to
completely eliminate early media (otherwise the answerer cannot know
with certainty that the offerer has received his answer). If a
proposed solution does not include such acknowledgements, it must
define UAS behaviors that minimize the probability of the UAS sending
media before the UAC has received the SDP answer.
Barnes & Lepinski Expires July 19, 2007 [Page 5]
Internet-Draft em-ps-req-sol January 2007
2.2. Additional Messaging
In order to minimize the impact of the proposed solution on call-
setup times, the proposed solution should minimize the number of
signaling messages that are required in addition to those used by
current SIP. Proposed solutions should accommodate the fact that
messages sent "on the media path" (i.e. directly between the two SIP
endpoints) will often be unable to reach their destinations due to
current media gating techniques.
2.3. Interoperability with current SIP standards
The proposed solution must define how entities implementing it will
interact with entities that implement the current SIP protocol. The
proposed solution should minimize the set of conditions under which a
call would fail in such a hybrid scenario, but not in a scenario in
which both endpoints use current SIP.
2.4. Interoperability with the PSTN
The proposed solution must be compatible with the creation of
gateways to the PSTN, and may define normative updates as necessary
to RFC 3398 and RFC 3578.
2.5. Denial of Service
The proposed solution must minimize the possibility of new denial of
service attacks by minimizing the amount of state that is kept by a
UAS prior to the completion of an offer/answer exchange. Ideally, no
state in addition to the SIP INVITE state machine will be required
(i.e., the initial SDP offer/answer will be conducted statelessly).
2.6. IPR Constraints
The proposed solution must, to the extent possible, avoid dependence
on technologies on which there are known IPR constraints, as this
tends to hinder adoption.
3. Early Media Solutions
The fundamental goal of a system to eliminate early media is to
ensure that an SDP offer/answer exchange has completed before media
packets are sent. Such a system will combine two approaches:
Completing the SDP exchange as quickly and reliably as possible, and
providing restrictions on the sending and receiving of media before
such completion. A priori, neither approach is at odds with the
requirements stated above, so we explore the possible mechanisms for
Barnes & Lepinski Expires July 19, 2007 [Page 6]
Internet-Draft em-ps-req-sol January 2007
accomplishing each. Many of the solutions below have been suggested
on the SIP and SIPPING mailing lists already, sometimes by multiple
people independently; we have not made an effort to attribute them.
3.1. Minimizing SDP completion time
The simplest way to preclude early media is for the SIP endpoints to
ensure that an SDP exchange has completed before media packets are
generated. In order to convey the SDP messages comprising this
exchange, it is necessary to modify the way that SDP messages are
carried within SIP session establishment. There are a variety of
mechanisms for achieving this goal, including modifications to
messages within the INVITE transaction, other non-INVITE SIP
mechanisms, and protocols outside of SIP.
3.1.1. Fast completion of INVITE transaction
Perhaps the most straightforward approach to quickly completing an
SDP offer/answer exchange would be to simply complete the SDP
exchange already inherent in the SIP INVITE transaction more quickly:
To do this, the UAS would send a 200/OK response as soon as an INVITE
message is received, rather than awaiting an indication from a higher
layer to do so (formally, this moves both the client and server
INVITE transactions to the Terminated state as quickly as possible).
In essence, this is a change to the semantic meaning of the "200/OK"
response; rather than indicating that an application-layer session
has begun, it would indicate that an media association had been
established, in the sense that all necessary parameters are
established for media to flow. A separate message (for instance, an
UPDATE [RFC3311]) could be used to indicate that an application-layer
user is ready to begin exchanging media.
Quickly completing the INVITE transaction has the potential to
eliminate early media entirely: Because the 200 response is
explicitly acknowledged by the ACK message, both endpoints can be
sure that the SDP exchange is complete when the ACK is transmitted.
In ISUP terms, a 200/OK response used in this way would correspond to
an ACM (rather than to an ANM, as in RFC 3398), and the UPDATE (or
similar message) would correspond to the ANM. The failing of this
approach is its interaction with SIP forking: Since a 200/OK message
moves both endpoints to the Terminated state, the first UAS to
respond would automatically cut off all other branches of the call.
Although this issue could likely be resolved with a modification to
rules for SIP forking, it could inhibit backward compatibility in the
interim.
Barnes & Lepinski Expires July 19, 2007 [Page 7]
Internet-Draft em-ps-req-sol January 2007
3.1.2. Elimination of offer from INVITE
One way to ensure that a UAS cannot send media until an SDP exchange
has completed would be to forbid a UAC from including an SDP offer in
its INVITE message, so that the SDP offer would be sent by the UAS in
either a reliable provisional response or the 200/OK message, and the
answer in the UAC's PRACK or ACK message. This behavior is allowed
by current SIP, but does not eliminate early media because it is not
mandatory. At first blush, reusing the existing INVITE transaction
in this way seems appealing: Because it is a subset of behaviors
allowed by current SIP, it will interact well with current SIP
endpoints, and it introduces no additional messaging or state
machinery. However, if either endpoint does not support reliable
provisional responses [RFC3262], this solution would prevent any
media flows before the sending of a 200/OK (distinct from an SDP
answer), which would cause many existing SIP applications to fail
(including a large number of PSTN applications as they pass through
gateways). In addition, the ACK message is not a reliable mechanism
for transporting SDP answers, since the UAC (as an SDP answerer)
receives no notification that the UAS has received its answer.
3.1.3. Provisional Responses
Within the INVITE transaction, the only other messages sent from UAS
to UAC (besides the INVITE, 200, and ACK messages) that could carry
SDP information are provisional (101-199) responses (response type
100 is excepted because it is often not retransmitted by proxies).
Upon receipt of an INVITE message, a UAS would respond with a 1xx
message that would complete the SDP offer/answer. Some have
suggested use of the 183 (Call Progress) message for this purpose, as
is done in ICE, though another existing or new response type could in
principle be used.
This approach has the advantage that if the UAS does not support this
use of provisional messages, then the call will proceed in the same
way as with current SIP. For PSTN gateways, this approach only
requires the sending or understanding a single additional message.
However, it would be difficult to use provisional responses to
eliminate early media, since this would require them to be reliable.
Though there exist both SIP (PRACK) and non-SIP (ICE binding request)
messages that can acknowledge provisional responses, AT&T holds IPR
related to reliable provisional responses. This has limited the
deployment of PRACK, and may have the same effect on relevant
portions of ICE.
Barnes & Lepinski Expires July 19, 2007 [Page 8]
Internet-Draft em-ps-req-sol January 2007
3.1.4. Separate INVITE transaction
The Application Server model of RFC 3960 provides an SDP exchange for
early media by conducting separate INVITE transactions for an "Early"
session and for the "Final" session. In a recently proposed
realization and extension of this model
[draft-stucker-sipping-early-media-indirection], any entity along the
signaling path can include an EMIND (Early Media Indirection) header
that will prompt the UAC to initiate a separate INVITE transaction
with a third entity, e.g., a media server to provide ring-back tones
or balance announcements. This transaction establishes an "Early
Session," which is terminated when the orignal INVITE transaction is
completed and the "Final Session" begun.
Using a separate INVITE transaction for early media has several
advantages: Since the answer in a 2xx response triggers an ACK in the
early INVITE transaction, it can be used to completely prevent early
media. Prospects for interoperability with current SIP
implementations are good, since no new mechanisms are employed; in
particular, the EMIND header will be ignored by implementations that
do not support it. And the entire burden of state maintenance is
placed on the UAC, which must manage both INVITE transactions.
However, using two separate INVITE transactions incurs significant
siganling overhead, and it is unclear that this approach, at least as
currently specified, can eliminate early media from PSTN gateways
that are unable to separate early and regular media.
3.1.5. Non-INVITE SIP Mechanisms
There are other SIP messages that could be used to carry an SDP
answer that would be formally outside of the INVITE transaction, but
could be contemporaneous with it. Because these messages would be
outside the INVITE transaction, a separate mechanism may be required
to associate the transmitted SDP answer with the SDP offer in the
INVITE request.
3.1.5.1. INFO and UPDATE
The SIP INFO method [RFC2976] is currently used to convey additional
signaling information in the middle of a session, after the INVITE
transaction has terminated. However, it could also be used to convey
information relevant to an INVITE transaction, subject to the
constraint in RFC 2976 that an INFO request must not change the state
of a SIP call. While receipt of an SDP answer in an INFO request
would change state at the TU layer (namely, in the UAC core), it
would not change the transaction-layer state of the call. INFO
messages carrying SDP answers can be associated with the
corresponding SDP offer by virtue of the fact that the INFO message
Barnes & Lepinski Expires July 19, 2007 [Page 9]
Internet-Draft em-ps-req-sol January 2007
carrying the answer will carry the same Call-ID as the INVITE message
carrying the offer. The SIP UPDATE method [RFC3311]could be likewise
used (in fact, RFC 3311 lists early media as the main motivation for
UPDATE, and RFC 3960 uses UPDATE messages as the basis for its
gateway model).
Current standards require that the UAS in an INFO or UPDATE
transaction to send a response to an INFO or UPDATE message, so these
messages would provide a reliable transport for SDP answers. Just as
with provisional responses, using INFO or UPDATE messages to convey
SDP answers is backwards-compatible, and requires minimal
modification to PSTN gateways. One potential drawback is that as
currently specified, UPDATE and INFO messages cannot be sent before a
dialog is established (i.e., a 101-199 response is sent). If not
changed or lifted by the proposed solution, this restriction could
limit the efficacy of UPDATE (or INFO) for quickly concluding an SDP
exchange, since the required 1xx message would introduce additional
delay in the transmission of the SDP answer.
3.1.5.2. Other Response Codes
In current SIP, if a UAS wishes to send early media in response to an
INVITE, it will send the media without any SIP response. As an
alternative, the UAS wishing to send early media could send a 401
response requiring http-auth with null authentication. The UAC would
then signal its willingness to receive the media by sending a new
INVITE (with the nonce for null authentication). In this model, the
UAS's SDP answer would be sent in its 401 response, and the UAC's re-
INVITE would confirm receipt of this answer.
Although this proposal does provide a reliable transport for SDP
answers, it has significant drawbacks: In addition to adding
significant messaging overhead, it requires both endpoints to
maintain state across INVITE transactions (in addition to the nonce
required by null authentication). And the prospects for backward
compatibility with this solution are bleak: All calls to current SIP
endpoints will fail unless the endpoints support the indicated
authentication mechanisms, and forked calls would show unpredictable
behavior due to the Heterogeneous Error Response Forking Problem
(HERFP).
3.1.6. Non-SIP mechanisms
There are some proposals to use protocols other than SIP to resolve
the problem of early media in SIP. For instance, a lower-level
protocol could be defined that could negotiate and SDP session that
could then be used by SIP, much as TLS negotiations are conducted
before HTTPS data are sent. However, such a protocol would have to
Barnes & Lepinski Expires July 19, 2007 [Page 10]
Internet-Draft em-ps-req-sol January 2007
duplicate many SIP features, and any such solution would require SIP
entities to implement an additional protocol stack, which would have
negative consequences for backward-compatability and PSTN
interoperability.
3.2. Handling remaining media
Early media can be completely eliminated only if neither party sends
media until it is assured that the SDP offer/answer exchange is
completed. Of course, this is only possible when both endpoints
support the proposed solution and the SDP answer is carried in a
reliable message: In this optimal case, both the offerer and the
answerer must not send media until they have received assurance that
the SDP exchange has completed. The proposed solution will specify
the two remaining cases.
3.2.1. Unreliable SDP answer
If both endpoints support the solution, but the solution uses an
unreliable message to carry the SDP answer, then the offerer can be
assured that the SDP exchange has completed (because he has received
the answer), but the answerer cannot. In this case, the offerer must
not send media until the SDP exchange has completed. The proposed
solution should provide an explicit, deterministic criterion for when
the answerer may send media: For instance, the answerer may be free
to send media after it receives media from the offerer, or after a
timer fires that is set when the answer is sent.
3.2.2. Backwards-compatibility
Depending on the nature of the proposed solution, one party may not
be able to know whether the other supports the solution. If a party
cannot know, then it must behave as if the other party does support
the solution (otherwise, the solution would never be used). If a
party can be aware of the other party's support, then the solution
should allow a supporting party to knowingly send early media to an
non-supporting party, since to do otherwise -- to mandate that a
supporting party behave as it would if the other party supported the
solution -- is incompatible with existing SIP applications that use
early media. Nonetheless, an implementation of the solution should
always avoid the use of early media; it should only send early media
when it has received early media from a non-supporting endpoint.
4. IANA Considerations
This document makes no request of IANA.
Barnes & Lepinski Expires July 19, 2007 [Page 11]
Internet-Draft em-ps-req-sol January 2007
Note to RFC Editor: this section may be removed on publication as an
RFC.
5. Security Considerations
The only new security concern that arises from this draft is the
possibility of introducing new denial of service attacks. The
requirement addressing this concern is stated in Section 2.5 above.
The performance of each candidate solution against this requirement
is examined in the section where that solution's is proposed.
6. Acknowledgements
7. References
7.1. Normative References
[RFC3261] "SIP: Session Initiation Protocol", June 2002.
[RFC3264] "An Offer/Answer Model with the Session Description
Protocol (SDP)", June 2002.
7.2. Informative References
[RFC2976] "The SIP INFO Method", October 2000.
[RFC3262] 2, "Reliability of Provisional Responses in the Session
Initiation Protocol (SIP)", June 2002.
[RFC3311] "The Session Initiation Protocol (SIP) UPDATE Method",
September 2002.
[RFC3398] "Integrated Services Digital Network (ISDN) User Part
(ISUP) to Session Initiation Protocol (SIP) Mapping",
December 2002.
[RFC3578] "Mapping of Integrated Services Digital Network (ISDN)
User Part (ISUP) Overlap Signalling to the Session
Initiation Protocol (SIP)", August 2003.
[RFC3830] "MIKEY: Multimedia Internet KEYing", August 2004 2004.
[RFC3960] "Early Media and Ringing Tone Generation in the Session
Initiation Protocol (SIP)", December 2004.
Barnes & Lepinski Expires July 19, 2007 [Page 12]
Internet-Draft em-ps-req-sol January 2007
[RFC4568] "Session Description Protocol (SDP) Security Descriptions
for Media Streams", July 2006.
[draft-ejzak-sipping-p-em-auth]
"Private Header (P-Header) Extension to the Session
Initiation Protocol (SIP) for Authorization of Early
Media", January 2007.
[draft-ietf-mmusic-ice]
"Interactive Connectivity Establishment (ICE): A
Methodology for Network Address Translator (NAT) Traversal
for Offer/Answer Protocols", October 2006.
[draft-stucker-sipping-early-media-coping]
"Coping with Early Media in the Session Initiation
Protocol (SIP)", October 2006.
[draft-stucker-sipping-early-media-indirection]
"Early Media INDirection (EMIND) in the Session Initiation
Protocol (SIP)", October 2006.
Authors' Addresses
Richard Barnes
BBN Technologies
9861 Broken Land Pkwy
Columbia, Maryland 21046
USA
Phone: +1-410-290-6169
Email: rbarnes@bbn.com
Matt Lepinski
BBN Technologies
10 Moulton St.
Cambridge, Massachusetts 02138
USA
Phone: +1-617-873-5939
Email: mlepinsk@bbn.com
Barnes & Lepinski Expires July 19, 2007 [Page 13]
Internet-Draft em-ps-req-sol January 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Barnes & Lepinski Expires July 19, 2007 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-23 04:07:21 |