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]