Internet DRAFT - draft-jbemmel-herfp-solution
draft-jbemmel-herfp-solution
Network Working Group J. van Bemmel
Internet-Draft Lucent Technologies
Expires: February 2, 2006 August 2005
A solution for the HERFP caused by forked SIP INVITE requests
draft-jbemmel-herfp-solution-00.txt
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 February 2, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes a solution to the Heterogeneous Error
Response Forking Problem (HERFP), a situation in which a UAC remains
unaware of elements that are responding to its INVITE with a
'repairable' error response, because a forking proxy in the
signalling path only forwards what it considers the 'best' final
response. This issue may cause communication establishment to be
delayed or even fail. To address this issue this document proposes a
new method [preliminarily called 'FIX'] to be used by a forking proxy
that detects a HERFP to notify the UAC of a repairable error.
van Bemmel Expires February 2, 2006 [Page 1]
Internet-Draft A solution for the HERFP August 2005
Table of Contents
1. Conventions used in this document . . . . . . . . . . . . . . 3
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem analysis and requirements . . . . . . . . . . . . . . 7
3.1. Repairable errors . . . . . . . . . . . . . . . . . . . . 8
3.2. Analysis of possible solutions . . . . . . . . . . . . . . 11
3.2.1. Notification mechanism . . . . . . . . . . . . . . . . 11
3.2.2. Forwarding/routing of the modified INVITE request . . 13
3.2.3. Formulation of the HERFP notification . . . . . . . . 14
3.2.4. Formulation of the modified INVITE request . . . . . . 14
4. Proposed solution . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2. Argumentation . . . . . . . . . . . . . . . . . . . . . . 18
4.2.1. Interaction between UAC and proxy . . . . . . . . . . 19
4.2.2. SUBSCRIBE/NOTIFY based alternative . . . . . . . . . . 20
4.3. Detailed normative guidelines . . . . . . . . . . . . . . 20
4.3.1. Construction of a FIX request . . . . . . . . . . . . 20
4.3.2. Merging of the original and modified INVITE . . . . . 22
4.3.3. UAC behavior . . . . . . . . . . . . . . . . . . . . . 22
4.3.4. B2BUA behavior . . . . . . . . . . . . . . . . . . . . 23
4.3.5. Forking proxy behavior . . . . . . . . . . . . . . . . 24
4.3.6. UAS behavior . . . . . . . . . . . . . . . . . . . . . 25
4.4. Open issues . . . . . . . . . . . . . . . . . . . . . . . 26
5. Security Considerations . . . . . . . . . . . . . . . . . . . 27
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
6.1. New Methods . . . . . . . . . . . . . . . . . . . . . . . 28
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.1. Normative References . . . . . . . . . . . . . . . . . . . 31
8.2. Informative References . . . . . . . . . . . . . . . . . . 31
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . . . . 33
van Bemmel Expires February 2, 2006 [Page 2]
Internet-Draft A solution for the HERFP August 2005
1. Conventions used in this document
1.1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1].
1.2. Terminology
o 'HERFP' means "Heterogeneous Error Response Forking Problem".
o 'Forking' is the forwarding of a (SIP) request to more than one
destination, either sequentially or in parallel
o A 'repairable' response is a final error response to an INVITE
request that represents a condition which could potentially be
fixed by submitting a modified INVITE request. The response codes
are typically in the 4xx range; some examples are "401
Unauthorized" or "415 Unsupported Media Type".
van Bemmel Expires February 2, 2006 [Page 3]
Internet-Draft A solution for the HERFP August 2005
2. Background
The Session Initiation Protocol (SIP) [2] allows a stateful SIP proxy
that is responsible for the domain in the request URI to fork a
request to multiple destinations. These 'targets' may be other
proxies, UAC or UAS elements. Each branch of the fork is an
independent client transaction, and may result in zero or more
provisional responses and at most one final response. According to
the current standard the proxy is to forward all provisional
responses and 2xx OKs upstream immediately. When all branches have
finished and no final response was forwarded yet, it should
eventually forward one 'best' final response from all those received.
It can therefore occur that an answer from a respondent never reaches
the caller, since it is blocked by the proxy in favor of another
'better' response. If the blocked response is due to an error
condition that could have been fixed (e.g. by responding to an
authentication challenge), a communication opportunity is lost. This
situation is known as the Heterogeneous Error Response Forking
Problem (HERFP)
To illustrate a simple case of HERFP, consider the example below
adopted from [8]. The UAC sends a request that includes a body
format which is understood by UAS2, but not by UAS1. For example,
the UAC might have used a multipart/mixed with a session description
and an optional image or sound (e.g. a personal ring tone). UAS1
does not support multipart/mixed, so it returns a 415 response. The
UAC could trivially repair this 415 response by resending the request
with just the session description. Unfortunately, the proxy has to
wait until all branches generate a final response before forwarding
the best response. UAS2 keeps ringing until finally the user at the
calling UAC gives up and cancels the call. At this point the proxy
cancels all pending branches and returns the 415 as a best final
response. The calling UAC may now retry but that is unlikely since
the user already hung up. Even when it would retry, precious time is
lost. In case UAS2 would represent an automatic response system
(e.g. a voicemail box) and returned a 2xx response instead, the
caller would never even know about the possibility of direct contact.
van Bemmel Expires February 2, 2006 [Page 4]
Internet-Draft A solution for the HERFP August 2005
UAC Forking Proxy UAS1 UAS2
| INVITE | | |
|---------->| | |
| | INVITE | |
| |-------------------------------->| |
| | INVITE | |
| |------------------------------------------>|
| | 415 Unsupported Media Type | |
| |<--------------------------------| |
| | ACK | |
| |-------------------------------->| |
| | 180 Ringing | |
| 180 |<------------------------------------------|
|<----------| | |
~ ~ time passes... ~ ~
| CANCEL | | |
|---------->| | |
| 200 OK | | |
|<----------| CANCEL | |
| |------------------------------------------>|
| | 200 OK | |
| |<------------------------------------------|
| | 487 Request Terminated | |
| |<------------------------------------------|
| | ACK | |
| 415 |------------------------------------------>|
|<----------| | |
Fig. 1 : Sample call flow illustrating the HERFP
Previous approaches to solve this issue are outlined in [9] (expired)
and more recently [8]. In [9] - which addresses several other issues
simultaneously - it is proposed that the proxy adds a 'Require'
header which causes the UAS to generate a 155 provisional response
when it would normally generate a repairable error (401, etc),
encapsulating the 'real' error response in a 'Reason' header. The
client receives this 155 and can then send an updated INVITE, using a
new method called 'COMET' (later replaced with UPDATE [3]). Drawback
of this proposal is that it requires updates to UACs, proxies and
UASs, and the use of 'Require' would cause each 'old' UAS to refuse
the request. In other words, modifications to each UAS would be
needed. The status of this work is that 'The proposal was accepted,
and the text has found its way into the UPDATE and manyfolks
specifications. There will be no more revisions of this document.'
However, neither [3](UPDATE) nor [4] (manyfolks work) mentions HERFP.
In [8] an additional requirement is proposed to ensure that a
solution would work with existing UAS. This rules out the above
van Bemmel Expires February 2, 2006 [Page 5]
Internet-Draft A solution for the HERFP August 2005
solution; instead it is proposed to have the proxy send a new '130
Repairable Error' provisional response when it receives a repairable
error. This 130 response would have a to-tag generated by the proxy
and contain a contact that points to the specific branch at the
proxy. The UAC would then send a modified INVITE request to this
URI, which the proxy would receive and merge with the ongoing call
attempt. If the UAC does not wish to retry the INVITE, it should
send a special CANCEL to tell the proxy to abandon the branch. Some
issues with this approach are:
1. The proposed solution might not work when there are other proxies
on the path between the UAC and the HERFP-solving proxy. The
request URI of the modified INVITE points directly at the proxy
that sent the 130, thus bypassing all other elements on the
original route. As a result, the modified INVITE could lack
headers that would have been inserted by those intermediate
proxies, or contain headers that would have been stripped or
modified. The presence or absence of these headers could cause
the request to fail, or certain features to break. As concrete
examples, consider privacy services [5] or identity services [6]
that would be bypassed or session timers [7] that would not get
set.
2. The proposal defines a 'repairable' error response as 'a 400-
class or 500-class response other than a 503, 487, or 408'. This
range is too broad as it includes e.g. 403 Forbidden. Moreover,
UAC behavior for some specific responses such as a 486 Busy here
(with/without a Retry-After header) should be explicitly
specified to avoid interoperability issues and/or network
flooding.
3. The usage of CANCEL is somewhat particular, as CANCEL is normally
sent to the same URI as the request being CANCELed (in fact, it
is not a request being cancelled here, but a particular branch).
4. The proposal allows reliable transmission of the 130 response,
which implies that the proxy must formulate a response to any
session offer or answer that was contained in the original
INVITE. It is suggested to generate a minimal offer or answer.
This sets up a session that has little use, and triggers a
PRACK/OK sequence.
5. The entire error response is to be included as the body of the
130 response. This response could contain information that the
network does not want to make public, such as IP addresses of
specific proxies.
van Bemmel Expires February 2, 2006 [Page 6]
Internet-Draft A solution for the HERFP August 2005
3. Problem analysis and requirements
The HERFP was first identified in late 2001, but up until now no
satisfactory solution was proposed. Generally stated, a solution to
the HERFP would enable a UAC to learn about repairable errors
received by a forking proxy, and give it a chance to issue a modified
INVITE request in an attempt to resolve the problem.
The following list of requirements for a HERFP solution are
identified:
o The UAC SHOULD indicate support for the protocol feature(s)
required for the HERFP solution
o The HERFP solution SHOULD work regardless whether the element that
sent the repairable error response is a UAC, UAS, proxy or B2BUA
o The HERFP solution SHOULD work regardless of intermediary elements
between the forking proxy with HERFP solution and the UAC; in
particular it SHOULD NOT break services or features provided by
such intermediary elements
o A UAC supporting the HERFP solution SHOULD be notified promptly of
all 'repairable' error responses received by any forking proxy
along the signalling path that supports the HERFP solution
o To attempt to fix a repairable error, a UAC with HERFP solution
support SHOULD cause a modified INVITE request to arrive at the
element that sent the error response
o Until it is received by the element that sent the repairable
error, the modified INVITE request MUST NOT be received by any
element that was not in the original path. This implies that the
modified INVITE request MUST NOT be forked by any element on the
path of the original INVITE, from the UAC up to and including the
forking proxy that detected HERFP (i.e. those listed in the Via
headers of the error response) even if they are not aware of the
HERFP solution
o The modified INVITE SHOULD be received by the element that sent
the repairable error, which SHOULD see it as a new call attempt
In addition there is a list of 'nice to have' features:
o A solution SHOULD require only minimal changes to the SIP
protocol, and preferably reuse existing mechanisms where possible
van Bemmel Expires February 2, 2006 [Page 7]
Internet-Draft A solution for the HERFP August 2005
o A solution SHOULD require only minimal changes to SIP protocol
entities, in particular it SHOULD work without modifying existing
UAS elements
o A solution MUST be backwards compatible
Specific issues and scenarios to be addressed:
o What happens when an element first sends a provisional response
(with a to-tag, establishing an early dialog) and then a
repairable error?
o What happens if multiple forking proxies are in the path, some of
which are unaware of the HERFP solution?
o What happens if the modified INVITE request also fails with a
repairable error response, possibly the same?
o What happens if the fix requires a change of transport?
3.1. Repairable errors
To avoid interoperability issues with implementations of a HERFP
solution, it must be clearly specified which error responses are to
be considered 'repairable'. In general, error responses in the 4xx-
5xx range SHOULD be considered repairable unless explicitly stated
otherwise. This is especially true for codes that have no assigned
meaning yet, as not forwarding these would imply that all proxies
would need to be updated each time a new response code in this range
is introduced. This draft only covers response codes defined in [2].
van Bemmel Expires February 2, 2006 [Page 8]
Internet-Draft A solution for the HERFP August 2005
The following error responses from RFC3261 are repairable [ possibly
under specified conditions ] when returned in response to an INVITE
request
+---------------------+---------------------------------------------+
| response code | when / how |
+---------------------+---------------------------------------------+
| 401 Unauthorized | Always, by attaching credentials for the |
| | requested realm |
| | |
| 406 Not Acceptable | Always, by changing the Accept header in |
| | the INVITE (if supported) |
| | |
| 407 Proxy | Always, by attaching credentials for the |
| Authentication | requested realm |
| Required | |
| | |
| 413 Request Entity | Always, by making the request body smaller |
| Too Large | if possible. If a Retry-After header is |
| | included, the condition is temporary and |
| | the request could be retried unmodified |
| | after the specified time interval. If this |
| | interval is larger than an Expires header |
| | added to the original INVITE, the UAC |
| | SHOULD decline the fix and offer the user |
| | the possibility to retry later. |
| | |
| 414 Request-URI Too | Possibly, by using a shorter URI (if the |
| Long | UAC/proxy have control over this) |
| | |
| 415 Unsupported | Always, by using only media supported by |
| Media Type | the responding entity |
| | |
| 416 Unsupported URI | Possibly, if the forking proxy did not |
| Scheme | change the URI scheme itself. If so, the |
| | forking proxy SHOULD add a URI with a SIP |
| | scheme to its target set (see RFC3261 |
| | section 16.7 point 4) and not notify the |
| | UAC. |
| | |
| 420 Bad Extension | Always, if the UAC is willing to do without |
| | the extension |
| | |
| 421 Extension | Always, if the UAC supports the required |
| Required | extension. |
| | |
van Bemmel Expires February 2, 2006 [Page 9]
Internet-Draft A solution for the HERFP August 2005
| 480 Temporarily | Not repairable but SHOULD be forwarded to |
| Unavailable | notify the UAC including reason phrase and |
| | any Retry-After information. The UAC MUST |
| | decline to repair |
| | |
| 485 Ambiguous | Always, but only after user input is |
| | collected |
| | |
| 486 Busy Here | Not repairable but SHOULD be forwarded to |
| | notify the UAC including any Retry-After |
| | information. The UAC MUST decline to |
| | repair |
| | |
| 488 Not Acceptable | Always, if acceptable media capabilities |
| Here | are supported by the UAC |
| | |
| 493 Undecipherable | Always, using an encryption key not used |
| | before for that target (e.g. the one |
| | provided in the response body) |
| | |
| 504 Server Time-out | With caution, no more than 2 retries is |
| | RECOMMENDED |
| | |
| 505 Version Not | If the UAC (and proxy) support a different |
| Supported | SIP version |
| | |
| 513 Message Too | Always, using a smaller message or |
| Large | different transport (if possible) |
+---------------------+---------------------------------------------+
Table 1: Repairable responses in RFC3261
van Bemmel Expires February 2, 2006 [Page 10]
Internet-Draft A solution for the HERFP August 2005
Some responses were intentionally left out of this table. In
particular:
+---------------------+---------------------------------------------+
| response code | why not |
+---------------------+---------------------------------------------+
| 400 Bad Request | More likely to be generated by the forking |
| | proxy itself, and some causes (e.g. missing |
| | Call-ID header) cannot be fixed. |
| | |
| 408 Request Timeout | Not caused by something the UAC can fix. |
| | |
| 483 Too Many Hops | The UAC cannot change the number of hops |
| | the request traversed. It could be that a |
| | shorter path exists between the UAC and the |
| | failing element, but it is more likely a |
| | signal of misconfiguration in the network |
| | (a looping request) |
| | |
| 484 Address | It is assumed that a proxy would not fork a |
| Incomplete | request with an incomplete address, in |
| | particular because it cannot determine |
| | whether it is responsible for the |
| | (incomplete) domain |
| | |
| 491 Request Pending | Another INVITE is apparently already |
| | pending |
| | |
| 503 Service | RFC3261 states that proxies SHOULD NOT |
| Unavailable | forward 503 responses upstream, but replace |
| | it with a 500 response instead. |
+---------------------+---------------------------------------------+
Table 2: Non-Repairable responses in RFC3261
A forking proxy SHOULD process non-repairable responses as defined in
RFC3261.
3.2. Analysis of possible solutions
3.2.1. Notification mechanism
A forking proxy that receives a 'repairable' error on one of its
branches has several options to notify the UAC:
1. Send a request
van Bemmel Expires February 2, 2006 [Page 11]
Internet-Draft A solution for the HERFP August 2005
* Using an existing method : The proxy could use an existing
method, e.g. SUBSCRIBE/NOTIFY [ref], UPDATE [3], INFO [ref],
PUBLISH [ref] or others. Support for each method is indicated
in the 'Allow' header, but that is not sufficient for the
proxy to determine whether the UAC supports the HERFP-related
semantics of the method. For SUBSCRIBE/NOTIFY or PUBLISH a
new event could be defined, such that 'Allow-Events: fix'
would be sufficient proof of support.
* Using a newly defined method : This has the advantage of
cleanly and exactly matching the intended semantics, at the
cost of adding yet another method to SIP.
* A request would be sent with the same Call-ID and a to-tag
equal to the from-tag of the original INVITE, to allow the UAC
to match it against an ongoing call attempt.
2. Send a response
* provisional (1xx): A provisional response could be sent.
RFC3261 disallows a proxy from generating its own provisional
responses, but allows 'virtual co-location' with a UAS
element. Technically the proxy would forward the request to a
virtual UAS, which would generate the response. The
provisional response might or might not contain a to-tag,
depending on whether the intention is to create an early
dialog between the virtual UAS on the proxy and the UAC.
* final success (2xx): Sending a final success response would
terminate any transactions in upstream intermediate elements,
and thus block any responses from other branches. Such a 2xx
response would be expected to contain an SDP offer/answer. In
addition, according to the rules in [2] section 16.7 the proxy
should CANCEL all other pending branches.
* final error (300-699): Sending a final error response would
cause any transactions in upstream intermediate elements to
move to the 'confirmed' state. As for a final 2xx response,
this would block any responses from other branches and the
proxy should CANCEL all pending client transactions.
Sending a new request rather than a response has the advantage that
any upstream transaction state is unaffected. Furthermore, a request
could be routed directly to the UAC (using the Contact address from
the INVITE if it is a GRUU), and does not need to travel along the
established signalling path. A request can be acknowledged by the
UAC with a response, a response would require PRACK(1xx), ACK(2xx) or
some other mechanism (300-699 since these get ACKed hop-by-hop).
van Bemmel Expires February 2, 2006 [Page 12]
Internet-Draft A solution for the HERFP August 2005
Drawback of PRACK is that it would trigger an additional response to
the PRACK itself.
For the notification mechanism the choice is between sending a
request or a provisional response. The transport path for the
response is already setup (DNS names have been resolved and cached,
connections are setup) but a request could be sent directly. Sending
a request would provoke a response, which would acknowledge reception
of the notification. It is currently uncommon for UACs to receive
PUBLISH requests, but a SUBSCRIBE with a body containing the
repairable response could be feasible. This would require
standardization of a new event package, e.g. the "fix" event. A
NOTIFY could then be used to carry the modified INVITE (and terminate
the subscription). However, currently the NOTIFY is required to be
sent promptly, while it could take some time (in particular in case
of user interaction) before the modified INVITE is ready to be sent.
3.2.2. Forwarding/routing of the modified INVITE request
The question is how the modified INVITE request gets from the UAC to
the element that sent the repairable error. There are several things
to consider here:
o The modified request cannot be directly targeted at the element
that sent the 'repairable' error response. To understand why,
consider the case that this element is in a different domain than
the forking proxy (i.e. the proxy did a rewrite of the domain part
of the request URI). Then a request targeted at this domain will
likely not pass through the proxy and follows a different route,
thus violating the requirements.
o If the modified INVITE is not sent with the established route of
the original request attached, it is not guaranteed that it will
follow the same route. Theoretically a proxy along the path could
base its routing decision on any property of the request,
including some that are modified from the original INVITE.
o If the modified INVITE is sent within an early dialog established
by a provisional response to the initial INVITE, proxies that did
not Record-Route the original will not receive the modified
request. This could be troublesome if the network depends on
these elements for inserting particular information in INVITE
requests. It could be assumed that such elements would be
configured to Record-Route, but this would restrict applicability
of the solution
o The forking proxy has insufficient information to calculate a
Route which would take the modified request along exactly the same
van Bemmel Expires February 2, 2006 [Page 13]
Internet-Draft A solution for the HERFP August 2005
path as the initial request. It can extract information from Via
headers and Record-Route headers, but for proxies that did not
Record-Route it cannot determine whether they are strict or loose
routers.
o RFC3261[2] section 19.1.5 strongly discourages UACs to accept
Route headers encoded in a Contact URI
The best way to guarantee that the modified request arrives at the
proxy without passing through other elements, would be to include it
in the body of a request or response targeted at the proxy. The
proxy could subsequently take the request from the body, possibly
modify some headers and then forward it to the element that sent the
repairable error.
3.2.3. Formulation of the HERFP notification
The HERFP notification sent to the UAC to notify it of a repairable
error SHOULD contain the following information:
o The response code that was sent
o Any headers from the response relevant for determining how the UAC
should react
o All information required to match the notification to an INVITE
sent previously by the UAC
o Information needed to associate the response with the branch on
which the error occurred (for proper routing of the modified
request at the forking proxy) or the request URI that the proxy
used to forward the original INVITE (in which case matching is not
needed).
To be robust the best solution would probably be to send the received
response including most headers and its body to the UAC. For both
efficiency and security reasons non-essential information SHOULD be
stripped. A guideline for stripping some headers is that the
response should be received by the UAC as if it was sent as a final
response by the proxy. This means all but the last Via header (which
the UAC put in there) should get removed. Including the response
body does not constitute an additional security issue, since this is
what the UAC would receive if the repairable error were the only
response received by a non-modified proxy.
3.2.4. Formulation of the modified INVITE request
The modification to the INVITE request depends on the specific error
van Bemmel Expires February 2, 2006 [Page 14]
Internet-Draft A solution for the HERFP August 2005
response received. Typical changes consist of
o Adding some headers, e.g. an authentication response
o Changing the format of the request body, e.g. removing MIME
multipart bodies
It is expected that the modified INVITE request will for the most
part be the same as the original request, with only minor
modifications. Given the HERFP solution requirements it SHOULD
contain any headers added by proxies along the path of the original
request, but the UAC is not aware of these. Moreover, for security
reasons it should not be informed about these headers. Therefore it
seems better to have the forking proxy append any missing headers,
and possibly remove or adjust some others. In fact, the UAC could
send only the required (minimal) changes and the proxy could apply
this as a 'patch' to the original request it received. The set of
allowed modifications should be well defined (specific for each
repairable error) to avoid security holes, otherwise the UAC could
e.g. insert headers that are not allowed. On the other hand, given
the end-to-end nature of SIP it would be preferable if the endpoint
were responsible for formulating the modified INVITE request.
van Bemmel Expires February 2, 2006 [Page 15]
Internet-Draft A solution for the HERFP August 2005
4. Proposed solution
4.1. Outline
The proposed solution consists of a new method [preliminarily called
'FIX' for lack of a better name, to be discussed] used by the proxy
to inform the UAC of any repairable responses it receives during
forking. The UAC then submits a modified INVITE to the proxy as the
body of either its response or another FIX request. The proxy merges
this with the original INVITE it received, and forwards the resulting
request to the element that sent the repairable response. More
specifically:
o A UAC supporting this HERFP solution formulates an INVITE as
usual, including an 'Allow: FIX' header
o A forking proxy that receives a repairable error response on a
branch, sends an ACK and checks if the original INVITE allows
'FIX'. If so, a FIX request is formulated based on the received
response. Suitable headers for the content are added. The body
of the FIX request consists of a stripped version of the
repairable response received (MIME type: message/sipfrag), and
routing is arranged such that the request will arrive at the UAC.
A CSeq number is chosen which increases monotonically for the
response context. The FIX request is sent as a new non-INVITE
transaction, with a new Via branch parameter. The transaction is
associated with the response context (just like a forked INVITE
transaction would be). The proxy excludes the error response from
consideration as a 'best' final response for the given response
context, instead considering the branch being fixed as if a '408
Request Timeout' was received; timer C is canceled.
o A UAC that receives a FIX request determines if it is willing and
able to fix the issue. It first checks whether the FIX request
matches an ongoing call attempt (based on the transaction for the
contained repairable error response). If there is no match, it
should respond with a '481 Call/Transaction does not exist'. To
attempt a fix, the UAC responds with a 2xx code. If no fix is
possible/desired, the UAC responds with a '603 Decline'.
o If the UAC can formulate a modified INVITE within a reasonable
time (200ms), it puts this request in the body of a '200 OK'
response. If not (for example because user interaction is
required) it sends a '202 Accepted' response without a body, and
remembers the route set (including Contact header) and CSeq number
from the FIX request.
van Bemmel Expires February 2, 2006 [Page 16]
Internet-Draft A solution for the HERFP August 2005
o When the proxy receives a 2xx response to its FIX, it locates the
response context and the specific branch. If found, and the
response contains a body, the modified INVITE is processed as
below. Else a Timer R is started for that branch, and the mapping
CSeq -> branch is recorded in the response context. If the branch
is not found or the response is a retransmission, it is ignored.
o If no modified INVITE was sent in the response, at some later
point in time (likely after consulting the user) the UAC
formulates a modified version of its INVITE, taking into account
the error response received. The UAC sends this INVITE as the
body of a new FIX request it formulates. This request is sent
using the route set, Contact and CSeq that were obtained from the
proxy's FIX, using the same Call-ID and From-tag as the original
INVITE.
o If the response context still exists (lookup using Call-ID + From-
tag), the proxy locates the original branch (using the CSeq
number) and merges the modified INVITE request with changes found
in the original INVITE request. In particular, Record-Route and
Via headers are added, as well as other headers added or modified
by intermediate elements. It then adds a new Via header of its
own and sends this modified INVITE to the same target that sent
the repairable error response (in many cases, using the same
request URI). This new INVITE client transaction is added to the
response context, as a new branch. Unlike the description in
RFC3261 section 8.1.3.5, the patched INVITE MUST have the same
CSeq value as the original INVITE.
o The UAS (or other element) that originally sent the repairable
error now receives the modified INVITE. If the problem is solved
it will likely generate zero or more provisional responses and a
2xx response, resulting in a new dialog.
o Any provisional or final responses that result from the modified
INVITE are included in the response context processing as usual.
A new repairable response is handled as under point (2) above
(even if it is the same as before).
o When all transactions have ended and no Timer R is active anymore,
the proxy selects a final response for forwarding if none was sent
yet, counting branches for which a FIX was sent as '408'.
o When the response context is destroyed (e.g. the original request
is CANCELed), the proxy should also terminate any FIX transactions
associated with the response context (treat them as if '487
Request Terminated' was received but not CANCEL them) and cancel
any timer R.
van Bemmel Expires February 2, 2006 [Page 17]
Internet-Draft A solution for the HERFP August 2005
Although it is not the primary objective of this solution, an UAS
could also opt to support the FIX mechanism. Instead of sending a
repairable response, it would formulate a FIX request with the
intended response (stripped of some headers). This allows for
example an optimized challenge-response sequence that takes place
only between the UAS and the UAC, without involving all intermediate
elements. An UAS supporting FIX partially solves HERFP in case a
forking proxy on the path does not support it.
4.2. Argumentation
o Like [8] this solution works with existing UAS, with modifications
to UACs and forking proxies. It also works with existing forking
proxies and modified UAC/UAS. Non-forking proxies can remain
unchanged, but enabling them to support FIX could offer a (minor)
improvement in network efficiency, in particular when many
intermediate elements are present.
o A new method is defined rather than reusing an existing one. To
reuse an existing method an additional 'Supported' header (or a
new event definition) would be needed to inform the forking proxy
that the UAC supports this HERFP solution. Rather than adding an
additional way of using an existing method it is considered more
elegant and clear to introduce a new method.
o Using a new request rather than a provisional response avoids any
effects that might affect intermediary elements. The UAC is
contacted directly (when a GRUU is used as Contact) and its reply
is guaranteed to be routed to the forking proxy. Using a request
also enables the use of the Identity header [11] such that the UAC
can determine the FIX request comes from a trusted source.
o By embedding the modified INVITE in the body of a FIX request or
response, it is guaranteed that the modified INVITE is only
received by the proxy, without any state changes in intermediary
proxies. It does mean that any existing proxy behavior based on
request properties that now get modified is bypassed. To avoid
this, proxies that are aware of this HERFP solution could Record-
Route the INVITE to receive FIX requests and their responses.
o By merging with the original INVITE it is guaranteed that any
headers added, modified or removed by proxies on the path also
appear in (or are removed from) the modified request. This avoids
the problem of having to visit all intermediaries that were
involved in the original INVITE request.
o A repairable error response will be acted upon by the first HERFP
enabled proxy that receives it, the one closest to the sender of
van Bemmel Expires February 2, 2006 [Page 18]
Internet-Draft A solution for the HERFP August 2005
that response. Any other proxies further downstream will never
see it and thus the same response is never FIXED twice.
o An earlier version of this draft proposed to have the UAC respond
with a provisional response to the proxy's FIX request if
formulating the modified INVITE would take longer than 200ms, in
order to send the modifications in the final FIX response. This
idea was abandoned since provisional responses are not allowed for
non-INVITE requests. FIX could be considered as an INVITE
request, but that would introduce other issues.
o For UAS the use of a provisional response was briefly considered.
However, this would make the solution asymmetric and complicates
processing rules. Furthermore, an Identity header could then not
be used.
4.2.1. Interaction between UAC and proxy
Three different interaction patterns between the proxy and the UAC
were considered for this document. A specific issue addressed is the
case when constructing the modified INVITE takes more time than a
typical non-INVITE transaction should take, due to user interaction.
When formulating a FIX response takes longer than 200ms, the
following alternatives could be followed:
1. The UAC sends a provisional response to the FIX
2. The UAC sends a final 486 Busy Here response to the FIX without
body but with a Retry-After header, the proxy/UAS retransmits the
FIX after that interval until a body is received (or some time
limit / max requests).
3. The UAC sends a final 202 Accepted response to the FIX without
body, the UAC formulates a new FIX request of its own (with body)
when ready.
Each of these alternatives has good and bad sides. RFC3261 states
that provisional responses SHOULD NOT be sent for non-INVITE requests
(such as FIX is). However, the user experience would be better than
option (2), since in that case the UAC has to wait for a response
opportunity (there is a tradeoff between waiting interval and network
efficiency). Option (3) does allow prompt submission when ready, but
requires the proxy to provide a Contact header, and the UAC to
construct and remember a route set. The proxy must start a timeout
timer.
The present document is written according to option (3). Discussion
is encouraged for the other options, in particular option (1) as it
van Bemmel Expires February 2, 2006 [Page 19]
Internet-Draft A solution for the HERFP August 2005
could simplify the solution and could be considered more elegant. In
combination with a different default T2 (4 seconds seems too little
for retransmission over unreliable transports while awaiting user
interaction, perhaps 10 seconds? elements unaware of FIX would still
use their own T2 values though) this could be a reasonable
compromise.
4.2.2. SUBSCRIBE/NOTIFY based alternative
For sake of discussion, this section sketches another HERFP solution
alternative based on SUBSCRIBE/NOTIFY.
A UAC sending an INVITE adds 'Allow-Events: herfp'. A proxy that
receives a repairable error checks if the UAC supports this event,
and sends a provisional response "112 HERFP Detected" containing a
Contact address (GRUU) with method=SUBSCRIBE. The UAC SUBSCRIBEs to
the 'herfp' event at this URI. The proxy then sends a NOTIFY with a
body containing the stripped repairable response received. The UAC
responds with a modified INVITE body, else a 202 and later a
reSUBSCRIBE containing the modified INVITE. The proxy merges both
INVITEs, and re-submits the resulting request (as described). The
subscription can last until the response context is destroyed.
For a UAS the scenario would be similar, noting that the 112 response
could have a to-tag if the UAS sent a provisional response before
some repairable error.
A brief comparison: to notify the UAC, this solution would use
112->SUBSCRIBE->OK,NOTIFY where this document proposes a single FIX
request. Sending non-2xx to a NOTIFY ends the subscription, so a
different solution would probably be needed for the UAC to decline a
fix.
4.3. Detailed normative guidelines
4.3.1. Construction of a FIX request
A FIX request is constructed based on both the original INVITE
request and the repairable response received for it. In particular:
o In the following statements the "received request" refers to the
received INVITE for a proxy/UAS, and to the received FIX for a
UAC.
o A proxy/UAS MUST calculate a Route set from the Record-Route
headers found in the received request. A UAC MUST do this only
when it is needed for sending a response in a FIX request body of
its own.
van Bemmel Expires February 2, 2006 [Page 20]
Internet-Draft A solution for the HERFP August 2005
o If the route set is empty, the proxy/UAS/UAC MUST place the URI
from the Contact header from the received request into the
Request-URI. It MUST NOT add any Route headers.
o If the route set is not empty, and the first URI in the route set
contains the lr parameter (see RFC3261 Section 19.1.1), the proxy/
UAS/UAC MUST place the Contact URI into the Request-URI and MUST
include a Route header field containing the route set values in
order, including all parameters.
o If the route set is not empty, and its first URI does not contain
the lr parameter, the proxy/UAS/UAC MUST place the first URI from
the route set into the Request-URI, stripping any parameters that
are not allowed in a Request-URI. The proxy/UAS/UAC MUST add a
Route header field containing the remainder of the route set
values in order, including all parameters. The proxy/UAS/UAC MUST
then place the Contact URI into the Route header field as the last
value.
o The Call-ID header value MUST be identical to the one in the
received request.
o The From header MUST be set to a value that identifies the element
constructing the FIX request. For a proxy the tag parameter MUST
be set to a unique value for each response context. A UAS MUST
set the tag according to the local tag of the dialog ID,
generating one if it does not yet exist. A UAC MUST set the tag
equal to the From-tag it used for the original INVITE.
o The URI in the To header MUST be set to the URI of the From header
in the received request. A UAS MUST use the tag value found in
the From header of the received INVITE, a Proxy/UAC MUST use the
tag value found in the To header of the repairable response.
o A CSeq header MUST be added with a method of 'FIX'. For a proxy,
a sequence number increasing monotonically for the given response
context MUST be selected ( an initial value MUST be chosen using
the guidelines of RFC3261 Section 8.1.1.5. ). For a UAC the CSeq
number MUST be equal to the one in the received request. For a
UAS the CSeq MUST be set using the value from the dialog, creating
one if it did not exist.
o A Max-Forwards header with a value of 70 MUST be added
o A single Via header with a new unique branch ID MUST be added
o For a proxy/UAS, a Contact header containing a global URI (GRUU)
that leads to the element sending the FIX MUST be added. A
van Bemmel Expires February 2, 2006 [Page 21]
Internet-Draft A solution for the HERFP August 2005
'Supported: gruu' SHOULD be added when appropriate. A UAC MUST
NOT add a Contact header.
o An Identity header SHOULD be added.
o Suitable headers for the body content MUST be added. In
particular, a Content-Type: message/sipfrag header MUST be added,
as well as a Content-Length header.
o For a proxy/UAS, a stripped version of the received/generated
repairable response MUST be used as the body. As a minimum, all
but the last Via header MUST be removed. For a UAC, the modified
INVITE request MUST be used as the body.
Sending a FIX request is very similar to sending a request within a
dialog, but strictly speaking for proxies it is not. The reason for
constructing a route set is that although the Contact URI should be a
GRUU, firewall/NAT issues could prevent reachability of the UAC. In
theory there could be several NAT domains being traversed, therefore
all Record-Route headers must be honored. Initially an optimization
was considered that if the proxy/UAS could determine the Contact URI
to be a GRUU (e.g. through presence of the 'gruu' support), it could
send the request to the UAC's Contact URI directly. However, this
idea was abandoned in favor of Record-Routing proxies that would like
to inspect (and potentially modify or block) FIX requests/responses.
4.3.2. Merging of the original and modified INVITE
TBD
4.3.3. UAC behavior
A UAC supporting the HERFP solution mechanism described in this
document MAY add an 'Allow: FIX' header to any INVITE it creates. It
MAY do so selectively, i.e. for some requests but not for others,
based on a local policy.
When a UAC receives a FIX request, it SHOULD perform general request
processing as specified in Section 8.2 (UAS behavior) in RFC3261.
Next it SHOULD attempt to locate a matching ongoing call attempt (by
locating the transaction for the repairable response). If no match
is found, the UAC SHOULD respond with a '481 Call/Transaction does
not exist'. If a matching call attempt has already resulted in an
active session, the UAC MAY decide to fix the additional branch based
on local policy.
The UAC SHOULD verify that the response matches its original INVITE
van Bemmel Expires February 2, 2006 [Page 22]
Internet-Draft A solution for the HERFP August 2005
transaction.
The UAC MAY challenge the FIX request using a '401 Unauthorized'.
After the above steps, the UAC checks if it is willing and able to
provide a suitable fix response. This step MAY require user
interaction. If the time to formulate a final response is more than
200ms (as is e.g. the case when user interaction is required), the
UAC SHOULD send a '202 Accepted' response without a body and retain
the route set (including Contact URI) and the CSeq number. This
state SHOULD be removed after a FIX request with the modified the
INVITE has been sent or when the INVITE transaction terminates.
If the FIX request has a To-tag, the UAC MUST check if it matches any
existing (early) dialog. If so, and the UAC responds with 2xx it
MUST discard any SDP offer/answer received for that dialog. If the
UAC declines the fix, it SHOULD consider any matching dialog as
terminated.
To attempt a fix, the UAC formulates a modified INVITE request,
taking into consideration the repairable error response that was
received in the body of the FIX request.
If the modified INVITE was not sent in the FIX response body, the UAC
formulates a new FIX request. This request is sent using the
recorded route-set (including the Contact header of the proxy/UAS).
The modified INVITE MUST be set as the body of this FIX request.
When the original INVITE transaction terminates (e.g. it is CANCELed
either by the UAC itself or by some other element, or a 6xx response
is received) the UAC SHOULD respond with '487 Request Terminated' to
any pending FIX transactions, and stop any FIX related user
interaction. When a 2xx response is received to the original INVITE,
it is up to local policy whether to abort FIXing other branches.
4.3.4. B2BUA behavior
A B2BUA supporting the HERFP solution mechanism described in this
document MAY add an 'Allow: FIX' header to any INVITE it creates. It
MAY do so selectively, i.e. for some requests but not for others,
based on a local policy.
When a 'FIX' request is received, the B2BUA SHOULD determine whether
it can resolve the error locally. If not and the original caller is
a SIP element that allows FIX, the B2BUA MUST respond with a '202
Accepted' and retain the route set (including Contact) and CSeq
number.It MUST then formulate a FIX request of its own to send
upstream.
van Bemmel Expires February 2, 2006 [Page 23]
Internet-Draft A solution for the HERFP August 2005
For non-SIP elements, the B2BUA SHOULD use any suitable mapping onto
a mechanism supported by such an element if possible. If no such
mapping exists, the B2BUA SHOULD respond with a '603 Decline'. TBD:
More
4.3.5. Forking proxy behavior
Proxy behavior intended to solve HERFP SHOULD be configurable by
local policy. This policy SHOULD define the set of status codes (the
'HERFP set') for which a FIX is attempted, which MAY be empty. It is
foreseen that a future specification COULD define a mechanism to
selectively disable HERFP behavior on a per-request basis.
When the proxy receives a repairable error response which is in the
'HERFP set', it MUST treat the corresponding branch as if a '408
Request Timeout' was received and cancel Timer C for that INVITE
transaction.
For repairable responses in the 'HERFP set' a FIX request should be
sent according to the rules in Section 4.3.1.
When a 200 response to a FIX is received, the proxy MUST process the
INVITE contained in the body.
When a 202 response to a FIX is received, the proxy MUST start a
timer R and store the CSeq -> branch (with Request URI used) relation
in the response context.
When a FIX request containing an INVITE body is received, the proxy
SHOULD lookup the corresponding branch using the CSeq number. If it
is not found, the proxy MUST respond with a 487. Otherwise it MUST
cancel Timer R associated with that branch and process the INVITE
body.
When the proxy receives a 401 FIX response with a challenge, it
SHOULD resubmit the FIX request with the challenge response and a new
CSeq number (taken from the response context). If no credentials can
be provided, it SHOULD be handled as a non-2xx response (see below).
When the proxy receives a non-2xx response to its FIX request or
Timer R fires, it SHOULD check if all transactions in the response
context have now terminated (both FIX and INVITE client transactions)
and no Timer R is pending. If so, the proxy SHOULD select a final
response for the INVITE if none was sent yet, choosing amongst those
received if available or '408 Request Timeout' (without to-tag)
otherwise.
To process a received modified INVITE body, the proxy SHOULD check
van Bemmel Expires February 2, 2006 [Page 24]
Internet-Draft A solution for the HERFP August 2005
the INVITE request provided against a security policy of allowed
changes. When verified, the proxy MUST construct a new INVITE
request that results from merging the modified INVITE with the
original INVITE request, as specified in Section 4.3.2.
To send the modified INVITE the proxy SHOULD set the Request-URI to
the value that was used for the original INVITE on that branch (TBD:
except when there was some issue with it), and send the result using
a new client transaction. This client transaction SHOULD be
associated with the response context.
A timeout of a FIX transaction SHOULD be handled as if a 408 response
was received.
When the response context is destroyed (e.g. because a 2xx/6xx
response is received on any of the INVITE branches or the original
INVITE is CANCELed), all FIX transactions SHOULD be terminated in
addition to CANCELing all remaining INVITE transactions. All
remaining timer Rs SHOULD be canceled.
A proxy that receives a FIX request or response for which it is not
the final destination, MUST forward the request/response rather than
process it locally. A FIX request MUST NOT be forwarded to more than
one destination.
4.3.6. UAS behavior
A UAS supporting this HERFP solution SHOULD generate a FIX request
instead of a repairable error response to an incoming INVITE (both
new and re-INVITEs), if the INVITE indicates the UAC supports this
(i.e. it contains an 'Allow: FIX' header). If the UAS already sent a
provisional response to the INVITE containing a to-tag, the FIX
request SHOULD be sent within that dialog (i.e. have the same to-tag
and an increasing CSeq number for multiple FIXes). The UAS SHOULD
create a new client transaction and associate this with the INVITE
servertransaction. If no 100 Trying for the INVITE was sent before,
this MUST be done first to quench any retransmissions.
Upon reception of a 2xx FIX response which matches a proceeding
INVITE server transaction, the UAS SHOULD check if the response
contains a valid modified INVITE request. If so, it MUST merge this
request with the original INVITE (following the rules in
Section 4.3.2), and MUST act as if the resulting INVITE was received
instead. In case the UAS already sent a provisional response to the
original INVITE containing a to-tag, the UAS MUST update relevant
dialog state and use the same to-tag for any provisional or final
responses to the patched INVITE. The UAS MAY use a different offer
or answer than was sent for the original INVITE.
van Bemmel Expires February 2, 2006 [Page 25]
Internet-Draft A solution for the HERFP August 2005
4.4. Open issues
o Identify common scenarios in which intermediate proxies would
behave differently for the modified request, and bypassing them
creates problems
o There may be more elements that should be stripped from the
response before sending it to the UAC, for security reasons or
other
o If the URI is the problem, it should be specified how the proxy
would be involved in resolving it.
o Should a proxy apply this solution also when the first element in
a list of targets tried sequentially returns a repairable error
response, or is it better to simply forward that response and stop
forking?
o Merging the request might break an integrity protection scheme
that was applied by either the UAC or an intermediary element.
o Should a header be defined to disable the use of this feature,
e.g. for use by proxies that are aware of this HERFP feature and
know that it would break a feature they provide?
o Should FIX be considered as an INVITE-transaction instead,
including an ACK from the proxy?
o Should update RFC3841 with a request disposition regarding the
application of HERFP fixes by proxies?
o Definition of non-repairable responses not specified in RFC3261.
o What about 3xx class responses?
o Should a proxy that forwards to only 1 destination apply HERFP
procedures too or not?
o Should add a 'Content-Disposition: fix' to a FIX request?
o An unaware intermediate element may see inconsistent SDP offer/
answers passing by, when the UAS sent a provisional response
before a FIX was made. In some situations this might be an issue.
o What happens if the modified INVITE requires a change of
transport?
van Bemmel Expires February 2, 2006 [Page 26]
Internet-Draft A solution for the HERFP August 2005
5. Security Considerations
An attacker that somehow learns the Call-ID, From-tag and Contact
address for an ongoing call attempt (e.g. by intercepting an INVITE)
could forge a FIX request and bomb the victim with it, resulting in a
DoS attack. If the fixing of the selected response code involves
significant computing (e.g. cryptographic calculations) and/or user
interaction, this could effectively take out the UAC. To reduce the
impact of such an attack, an UAC could put an upperlimit on the
number of FIX requests accepted per call attempt, and ignore any
requests beyond this limit. Alternatively, in some environments the
UAC could respond with an authentication challenge.
If the Identity header [11] is present, it can be used to verify the
source of the FIX request.
Some network configurations might depend on border proxies to strip
certain confidential information from responses, such as IP addresses
of intermediate elements (topology hiding), charging information,
etc. The body of a FIX request would bypass such a stripping
element, and thus potentially exposes sensitive information to the
UAC. To avoid this, implementors should carefully consider which
parts of the response to be fixed are needed by the UAC to compose a
fix, and leave out any unnecessary (sensitive) information.
van Bemmel Expires February 2, 2006 [Page 27]
Internet-Draft A solution for the HERFP August 2005
6. IANA Considerations
This document registers a new method name.
6.1. New Methods
This document registers a new SIP method name, defined by the
following information, which has been added to the method and
response-code sub-registry under
http://www.iana.org/assignments/sip-parameters
Method Name: FIX
Reference: [ XXXXXXX ]
This table expands on tables 2 and 3 in SIP [2]; headers not
mentioned in this table are not allowed
+--------------------+-------+-------------------+
| Header | Where | FIX |
+--------------------+-------+-------------------+
| Accept | R | o |
| | | |
| Accept-Encoding | R | o |
| | | |
| Accept-Language | R | o |
| | | |
| Allow | 405 | m |
| | | |
| Authorization | R | o |
| | | |
| Call-ID | c | m |
| | | |
| Contact | R | m (for proxy/UAS) |
| | | |
| Content-Encoding | | o |
| | | |
| Content-Length | R | m |
| | | |
| Content-Length | 200 | m |
| | | |
| Content-Type | R | m |
| | | |
| Content-Type | 200 | m |
| | | |
| CSeq | c | m |
| | | |
| Error-Info | R | o |
| | | |
van Bemmel Expires February 2, 2006 [Page 28]
Internet-Draft A solution for the HERFP August 2005
| From | c | m |
| | | |
| Max-Forwards | R | m |
| | | |
| MIME-Version | | o |
| | | |
| Retry-After | 413 | o |
| | | |
| Require | R | o |
| | | |
| Timestamp | | o |
| | | |
| To | c | m |
| | | |
| Unsupported | 420 | m |
| | | |
| User-Agent | | o |
| | | |
| Via | c | m |
| | | |
| WWW-Authenticate | 407 | m |
+--------------------+-------+-------------------+
Table 3: Usage of headers in FIX requests and responses
This table lists allowed non-RFC3261 headers; headers not mentioned
in this table are not allowed
+--------------------+-------+-----+
| Header | Where | FIX |
+--------------------+-------+-----+
| Identity | R | o |
+--------------------+-------+-----+
Table 4: Usage of non-RFC3261 headers in FIX requests and responses
van Bemmel Expires February 2, 2006 [Page 29]
Internet-Draft A solution for the HERFP August 2005
7. Acknowledgements
The author would like to thank Vijay Gurbani of Lucent Technologies
for his valuable comments on an earlier version of this draft. This
work is part of the Freeband AWARENESS project
(http://awareness.freeband.nl). Freeband is sponsored by the Dutch
government under contract BSIK 03025.
van Bemmel Expires February 2, 2006 [Page 30]
Internet-Draft A solution for the HERFP August 2005
8. References
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[3] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002.
[4] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of
Resource Management and Session Initiation Protocol (SIP)",
RFC 3312, October 2002.
8.2. Informative References
[5] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.
[6] Jennings, C., Peterson, J., and M. Watson, "Private Extensions
to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks", RFC 3325, November 2002.
[7] Donovan, S. and J. Rosenberg, "Session Timers in the Session
Initiation Protocol (SIP)", RFC 4028, April 2005.
[8] Mahy, R., "A Solution to the Heterogeneous Error Response
Forking Problem (HERFP) in the Session Initiation Protocol
(SIP)", draft-mahy-sipping-herfp-fix-00 (work in progress),
July 2005.
[9] Rosenberg, J., "Unifying Early Media, Manyfolks, And HERFP",
draft-rosenberg-sip-unify-00 (work in progress), January 2002.
[10] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-rosenberg-sip-gruu-01 (work in progress),
December 2003.
[11] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
draft-ietf-sip-identity-05 (work in progress), May 2005.
van Bemmel Expires February 2, 2006 [Page 31]
Internet-Draft A solution for the HERFP August 2005
Author's Address
Jeroen van Bemmel
Lucent Technologies
Larenseweg 50
Hilversum
The Netherlands
Email: jbemmel@lucent.com
URI: http://www.lucent.com
van Bemmel Expires February 2, 2006 [Page 32]
Internet-Draft A solution for the HERFP August 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
van Bemmel Expires February 2, 2006 [Page 33]
