Internet DRAFT - draft-jbemmel-sipping-herfp-solution
draft-jbemmel-sipping-herfp-solution
Network Working Group J. van Bemmel
Internet-Draft Lucent Technologies
Expires: March 18, 2006 September 14, 2005
A solution for the HERFP caused by forked SIP INVITE requests
draft-jbemmel-sipping-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 March 18, 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 March 18, 2006 [Page 1]
Internet-Draft A solution for the HERFP September 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. Formulation of the HERFP notification . . . . . . . . 13
3.2.3. Formulation of the modified INVITE request . . . . . . 14
3.2.4. Forwarding/routing of the modified INVITE request . . 14
4. Proposed solution . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2. Argumentation . . . . . . . . . . . . . . . . . . . . . . 17
4.3. Detailed normative guidelines . . . . . . . . . . . . . . 18
4.3.1. Construction of a FIX request . . . . . . . . . . . . 18
4.3.2. UAC behavior . . . . . . . . . . . . . . . . . . . . . 20
4.3.3. B2BUA behavior . . . . . . . . . . . . . . . . . . . . 21
4.3.4. Forking proxy behavior . . . . . . . . . . . . . . . . 22
4.3.5. UAS behavior . . . . . . . . . . . . . . . . . . . . . 23
4.4. Example call flow . . . . . . . . . . . . . . . . . . . . 24
4.4.1. FIX forking proxy -> UAC . . . . . . . . . . . . . . . 25
4.5. Open issues . . . . . . . . . . . . . . . . . . . . . . . 25
5. Security Considerations . . . . . . . . . . . . . . . . . . . 27
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
6.1. New Methods . . . . . . . . . . . . . . . . . . . . . . . 28
6.2. New headers . . . . . . . . . . . . . . . . . . . . . . . 30
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1. Normative References . . . . . . . . . . . . . . . . . . . 32
8.2. Informative References . . . . . . . . . . . . . . . . . . 32
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 34
van Bemmel Expires March 18, 2006 [Page 2]
Internet-Draft A solution for the HERFP September 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 March 18, 2006 [Page 3]
Internet-Draft A solution for the HERFP September 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 March 18, 2006 [Page 4]
Internet-Draft A solution for the HERFP September 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 |------------------------------------------>|
|<----------| | |
Figure 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 March 18, 2006 [Page 5]
Internet-Draft A solution for the HERFP September 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 March 18, 2006 [Page 6]
Internet-Draft A solution for the HERFP September 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 forked
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
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:
van Bemmel Expires March 18, 2006 [Page 7]
Internet-Draft A solution for the HERFP September 2005
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 March 18, 2006 [Page 8]
Internet-Draft A solution for the HERFP September 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 March 18, 2006 [Page 9]
Internet-Draft A solution for the HERFP September 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) |
| | |
| 500 Server internal | When caused by the information in the |
| error | INVITE |
| | |
| 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 March 18, 2006 [Page 10]
Internet-Draft A solution for the HERFP September 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 (if not) likely to be |
| | generated by all branches. |
| | |
| 408 Request Timeout | Not caused by something the UAC can fix. |
| | |
| 483 Too Many Hops | The UAC has little control over the number |
| | of hops the request traverses. 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. |
| | |
| 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 | Never forwarded by proxies unless they can |
| Unavailable | determine it will always be the case, so |
| | notifying the UAC would imply that it is |
| | not repairable. |
+---------------------+---------------------------------------------+
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 March 18, 2006 [Page 11]
Internet-Draft A solution for the HERFP September 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 March 18, 2006 [Page 12]
Internet-Draft A solution for the HERFP September 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. 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.
van Bemmel Expires March 18, 2006 [Page 13]
Internet-Draft A solution for the HERFP September 2005
3.2.3. Formulation of the modified INVITE request
The modification to the INVITE request depends on the specific error
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. If the modified INVITE should contain the same
headers added by proxies along the path of the original request, the
UAC should not be made aware of these. In that case it would be
necessary 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. This avoids
complex merging by the proxy and several other issues.
3.2.4. 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 could be directly targeted at the element
that sent the 'repairable' error response. However, it will not
follow the same route (it will likely not go through the proxy,
and possibly through additional elements). This could mean that
it has additional headers or is missing headers that were present
when the original INVITE was received.
o If the modified INVITE is sent to the same request URI as
originally, 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
van Bemmel Expires March 18, 2006 [Page 14]
Internet-Draft A solution for the HERFP September 2005
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
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.
If it is acceptible that the modified INVITE does not follow the same
route, then sending it directly to the element that sent the
repairable error seems easiest. If a request URI is used that is not
an AoR, the modified request would (normally) not be forked again, at
least not until it reaches the target element (which could be a
forking proxy).
van Bemmel Expires March 18, 2006 [Page 15]
Internet-Draft A solution for the HERFP September 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 proxy reports the URI it used to forward the INVITE.
The UAC may then decide to submit a modified INVITE to this contact
directly. 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 stops timer C. It then 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/
sip), and the proxy adds a Contact header that contains the URI it
used for the branch. 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).
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 The proxy retains the status code of the FIX request. If the best
response algorithm selects a repairable error for which a FIX was
sent, the proxy adds a 'FIX-Status' header with the response code
received from the UAC.
o The UAC formulates a modified version of its INVITE, taking into
account the error response received. The UAC sends this INVITE
using the route set and Contact received in the FIX request, as a
new call attempt.
o The UAS (or other element) that originally sent the repairable
error now receives the modified INVITE. If the problem is solved
van Bemmel Expires March 18, 2006 [Page 16]
Internet-Draft A solution for the HERFP September 2005
it will likely generate zero or more provisional responses and a
2xx response, resulting in a new dialog.
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).
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 going via all intermediate
elements. A 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). Using a
request also enables the use of the Identity header [10] such that
the UAC can determine if the FIX request comes from a trusted
source. The UAC could also challenge the FIX.
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
that response. Other proxies further downstream could receive it
when it is selected as best response, but since the FIX status is
attached such a proxy would not attempt a second FIX unless the
first one failed (e.g. due to timeout or transport failure).
van Bemmel Expires March 18, 2006 [Page 17]
Internet-Draft A solution for the HERFP September 2005
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.
o An earlier version of this draft had the UAC send its modified
INVITE in the body of the FIX response or a new FIX request, which
the proxy would merge with the original. This is now considered
too complex; the concession made is that the modified INVITE does
not follow the same route, and may therefore have different
headers upon arrival. The UAC could perhaps use Caller
preferences [ref] and send the INVITE using the original Request
URI. However, that would still not guarantee that it will follow
the same route.
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 A proxy/UAS MUST calculate a Route set from the Record-Route
headers found in the received INVITE request, taken in order and
preserving any parameters.
o If the route set is empty, the proxy/UAS MUST place the URI from
the Contact header from the received INVITE 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 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 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 MUST add a Route
header field containing the remainder of the route set values in
order, including all parameters. The proxy/UAS 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 INVITE.
van Bemmel Expires March 18, 2006 [Page 18]
Internet-Draft A solution for the HERFP September 2005
o The From header MUST be set to a value that identifies the element
constructing the FIX request. The tag parameter MUST be equal to
the tag value from the From header in the received INVITE.
o The URI in the To header MUST be set to URI of the From header in
the received request. The tag MUST be omitted.
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 UAS the CSeq
number MUST be set equal to the CSeq number received in the
INVITE.
o A Max-Forwards header with a recommended value of 70 MUST be added
o A single Via header with a new unique branch ID MUST be added
o A proxy MUST add a Contact header containing the information that
was obtained from the location service for the branch that
received the repairable response (in particular the request URI
that was used). A UAS MUST add a Contact header reflecting an
address at which it can be reached. The URI used in the Contact
header SHOULD be a GRUU. If it is, a 'Supported: gruu' SHOULD be
added.
o If the request URI is not a GRUU and not directly addressable by
the UAC, a proxy MUST add a single Record-Route header, pointing
to itself (including a 'lr' parameter).
If the Contact is not a GRUU, it is assumed that it is only
reachable via the proxy. Therefore it must stay in the path to
forward the request. This is not needed if the UAC is in the
same private network.
o An authentication service SHOULD be used, such that an Identity
header is added.
o Suitable headers for the body content MUST be added. In
particular, a Content-Type: message/sip header MUST be added, as
well as a Content-Length header.
o A stripped version of the received/generated repairable response
MUST be used as the body. As a minimum, all but the last Via
header (which was inserted by the UAC) MUST be removed.
A FIX request is sent as an out-of-dialog request. The reason for
constructing a route set is that although the INVITE Contact URI
van Bemmel Expires March 18, 2006 [Page 19]
Internet-Draft A solution for the HERFP September 2005
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. Even
if the proxy/UAS can determine that the Contact URI is a GRUU (e.g.
through presence of the 'gruu' support), the route MUST be followed
to avoid bypassing proxies that Record-Route the FIX.
4.3.2. 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.
The UAC SHOULD use a GRUU in the Contact URI of every INVITE it
sends; if applicable, it SHOULD add a 'Supported: gruu' header.
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 use the additional contact
based on local policy.
The UAC SHOULD verify that the response matches its original INVITE
transaction.
The UAC MAY challenge the FIX request using a '401 Unauthorized'.
If the FIX contains an Identity header, the UAC SHOULD validate it.
If not, the UAC MAY accept the FIX based on local policy, or respond
with an '428 Use Identity Header' otherwise.
After the above steps, the UAC checks if it is willing and able to
construct a modified INVITE request. If so, it MUST send a 200
response. If not, it MUST send a '603 Decline'. If user interaction
is required to decide and/or perform the fix, the UAC MUST respond
with a '202 Accepted' promptly before engaging in user interaction.
To attempt a fix, the UAC SHOULD formulate a modified INVITE request,
taking into consideration the repairable error response that was
received in the body of the FIX request.
The UAC MUST construct a route set from the Record-Route headers
contained in the received FIX, taken in order, according to the
van Bemmel Expires March 18, 2006 [Page 20]
Internet-Draft A solution for the HERFP September 2005
procedures defined in RFC3261. It MAY prepend any locally configured
route set entries, but each entry MUST be unique.
Constructing the route set enables proxies to Record-Route the FIX
request in order to receive the modified INVITE too (when sent).
An outbound proxy may have Record-Routed the FIX, so the UAC
should be careful when appending additional entries.
If the route set is empty, the UAC MUST place the Contact URI found
in the FIX into the Request-URI. The UAC MUST NOT add a Route header
field to the request.
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 UAC MUST
place the Contact URI found in the FIX into the Request-URI and MUST
include a Route header field containing the route set values in
order, including all parameters.
If the route set is not empty, and its first URI does not contain the
lr parameter, the 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 UAC MUST add a Route header field containing
the remainder of the route set values in order, including all
parameters. The UAC MUST then place the Contact URI found in the FIX
into the Route header field as the last value.
Just like re-INVITEs, the modified INVITE is targeted at a
specific UA (or proxy) instance rather than an address-of-record.
For this reason, it will not be forked until it reaches this
element.
The UAC MAY add an Accept-Contact header in the modified INVITE
request, e.g. using information from the Contact header received in
the FIX.
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), it is up to local policy whether to cancel any modified
attempts.
When the UAC receives a repairable error containing a 'FIX-Status'
with a status denoting success, it MUST NOT send a new INVITE as an
attempt to resolve the problem.
4.3.3. 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
van Bemmel Expires March 18, 2006 [Page 21]
Internet-Draft A solution for the HERFP September 2005
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 and the Contact. It MUST then
formulate a FIX request of its own to send upstream.
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 '503 Service
Unavailable'.
TBD: More?
4.3.4. 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 a proxy receives a repairable error response which is in the
'HERFP set', it MUST stop Timer C for that INVITE transaction. It
MUST associate a FIX status with the branch, initialized to the value
of a 'FIX-Status' header contained in the response, or '503' if no
such header exists.
For repairable responses in the 'HERFP set' a FIX request should be
sent according to the rules in Section 4.3.1, if the FIX status of
the branch matches 4xx or 5xx (except 481). If not, a FIX request
MUST NOT be sent.
When the proxy receives a response to a FIX request, it MUST update
the FIX status of the corresponding branch with the status code of
the received response.
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 '481 Call does not exist' FIX response, it
MUST CANCEL all remaining INVITE transactions and terminate any
remaining FIX transactions.
van Bemmel Expires March 18, 2006 [Page 22]
Internet-Draft A solution for the HERFP September 2005
A timeout of a FIX transaction SHOULD be handled as if a 408 response
was received.
A transport error for a FIX transaction SHOULD be handled as if a 503
response was received.
When the "best response selection algorithm" selects a response for
which a FIX status exists, the proxy MUST add (or update) a 'FIX-
Status: nnn' header to the response with 'nnn' set to the FIX status
of the branch.
The proxy SHOULD consider responses with a 2xx FIX status as 'better'
than responses with a non-2xx FIX status.
In case the selected best response is a 401 or 407 and contains
aggregated authentication headers as described in RFC3261 section
16.7 point 7, the FIX status MUST also be aggregated. It MUST be set
to 2xx when at least one of the corresponding branches has a 2xx FIX
status. The proxy MUST NOT add authentication headers from branches
with a 6xx FIX status.
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
(considered as if 487 was received) in addition to CANCELing all
remaining INVITE transactions.
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.5. UAS behavior
A UAS supporting this HERFP solution MAY generate a FIX request
before responding with a repairable error response to an incoming
INVITE (both new and re-INVITEs), if the INVITE indicates the UAC
allows 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 with the from-tag and an
increasing CSeq number taken from that dialog. The UAS SHOULD create
a new client transaction and associate this with the INVITE
servertransaction. If no provisional response for the INVITE was
sent before, a 100 Trying MUST be sent first to quench any
retransmissions.
Upon reception of a response to the FIX, the UAS MUST add a 'FIX-
Status: nnn' header to the repairable response, with 'nnn' set to the
van Bemmel Expires March 18, 2006 [Page 23]
Internet-Draft A solution for the HERFP September 2005
status code of the FIX response. It MUST then submit this response
to the original INVITE server transaction.
4.4. Example call flow
To illustrate the workings of the proposed mechanism, this example
shows how HERFP is solved for the call flow shown in Figure 1,
assuming that UAC, UAS1 and UAS2 are all in the same private network.
UAC Forking Proxy UAS1 UAS2
| INVITE | | |
|---------->| | |
| | INVITE | |
| |-------------------------------->| |
| | INVITE | |
| |------------------------------------------>|
| | 415 Unsupported Media Type | |
| |<--------------------------------| |
| | ACK | |
| |-------------------------------->| |
| FIX(415) | | |
|<----------| | |
| 200 OK | | |
|---------->| | |
| | 180 Ringing | |
| 180 |<------------------------------------------|
|<----------| | |
| | | |
| | INVITE (modified) | |
|-------------------------------------------->| |
| | 200 OK | |
| 200 |<------------------------------------------|
|<----------| | |
| | ACK | |
|------------------------------------------------------>|
| | 180 Ringing | |
|<--------------------------------------------| |
| | | |
| | 200 OK | |
|<--------------------------------------------| |
| | ACK | |
|-------------------------------------------->| |
| | BYE | |
|------------------------------------------------------>|
| | 200 | |
|<------------------------------------------------------|
Figure 2: Sample call flow illustrating the HERFP solution
van Bemmel Expires March 18, 2006 [Page 24]
Internet-Draft A solution for the HERFP September 2005
When the proxy receives the 415 repairable error, it formulates a FIX
and sends it to the UAC. The UAC can repair it without user
interaction so it responds with 200 OK, and formulates a modified
INVITE. In the mean time the second branch returns 180 and then 200,
which ends the response context at the proxy. The UAC attempts the
modified INVITE which succeeds; the user then decides to end the
dialog with UAS2 (e.g. a voice response system) and continues with
UAS1.
4.4.1. FIX forking proxy -> UAC
FIX sip:uac@example.com SIP/2.0
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKnashds8
Max-Forwards: 70
To: UAC <sip:uac@example.com>
From: Forking Proxy <sip:proxy@example.com>;tag=630285328
Call-ID: a84b4c76e66710
CSeq: 1234 FIX
Contact: <sip:uas1@uas1.example.com>
Supported: gruu
Identity: "..."
Identity-Info: <https://id.example.com/cert>;alg=rsa-sha1
Content-Type: message/sip
Content-Length: 266
SIP/2.0 415 Unsupported media type
Via: SIP/2.0/UDP uac.example.com;branch=z9hG4bKxy567ep
;received=192.0.2.2
To: Callee <sip:callee@example.com>;tag=a6c85cf
From: UAC <sip:uac@example.com>;tag=630285328
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Content-Length: 0
Accept: application/sdp
Note that the based64 encoded Identity value is omitted for clarity
reasons.
4.5. Open issues
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 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?
van Bemmel Expires March 18, 2006 [Page 25]
Internet-Draft A solution for the HERFP September 2005
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 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 A Contact header normally contains an element's own URI, perhaps a
different header should be used to convey the Request URI for the
element that sent a repairable error.
o Perhaps a new unique from-tag for the FIX is better than copying
the one found in the INVITE?
van Bemmel Expires March 18, 2006 [Page 26]
Internet-Draft A solution for the HERFP September 2005
5. Security Considerations
An attacker that intercepts an INVITE could forge a FIX request and
cause the victim to INVITE a target UA of his choice. This cannot be
detected, but the attacker's chance to succeed can be reduced by
using request authentication for the FIX (e.g. requiring an Identity
header or responding with a WWW-Authenticate challenge).
Interception of the INVITE can be mitigated by using sips.
An attacker that intercepts 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.
If the Identity header [10] 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 March 18, 2006 [Page 27]
Internet-Draft A solution for the HERFP September 2005
6. IANA Considerations
This document registers a new method name and a new SIP header.
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 |
| | | |
| Content-Language | R | o |
| | | |
| Content-Encoding | R | o |
| | | |
| Content-Length | R | m |
| | | |
| Content-Type | R | m |
| | | |
| CSeq | c | m |
| | | |
| Error-Info | R | o |
| | | |
| From | c | m |
| | | |
van Bemmel Expires March 18, 2006 [Page 28]
Internet-Draft A solution for the HERFP September 2005
| Max-Forwards | R | m |
| | | |
| MIME-Version | R | o |
| | | |
| Proxy-Require | R | o |
| | | |
| Record-Route | R | o |
| | | |
| Retry-After | 413 | o |
| | | |
| Require | R | o |
| | | |
| Supported | | 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 |
+--------------------+-------+-----+
| Allow-Events | | o |
| | | |
| Identity | R | o |
+--------------------+-------+-----+
Table 4: Usage of non-RFC3261 headers in FIX requests and responses
van Bemmel Expires March 18, 2006 [Page 29]
Internet-Draft A solution for the HERFP September 2005
6.2. New headers
This table expands on tables 2 and 3 in SIP [2], as amended by the
changes described in Section 6.1.
+------------+---------+---+---+---+---+---+---+---+---+---+---+----+
| Header | where | p | A | B | C | F | I | O | R | P | S | NO |
| field | | r | C | Y | A | I | N | P | E | R | U | T |
| | | o | K | E | N | X | V | T | G | A | B | |
| | | x | | | | | | | | | | |
+------------+---------+---+---+---+---+---+---+---+---+---+---+----+
| FIX-Status | 4xx,5xx | a | - | - | - | - | o | - | - | - | - | - |
| | | m | | | | | | | | | | |
+------------+---------+---+---+---+---+---+---+---+---+---+---+----+
Table 5: New SIP headers
van Bemmel Expires March 18, 2006 [Page 30]
Internet-Draft A solution for the HERFP September 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 March 18, 2006 [Page 31]
Internet-Draft A solution for the HERFP September 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] 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 March 18, 2006 [Page 32]
Internet-Draft A solution for the HERFP September 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 March 18, 2006 [Page 33]
Internet-Draft A solution for the HERFP September 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 March 18, 2006 [Page 34]
