[sipcore] 4244bis: Describing redirections

"Worley, Dale R (Dale)" <dworley@avaya.com> Thu, 30 June 2011 19:17 UTC

Return-Path: <dworley@avaya.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D3211E8201 for <sipcore@ietfa.amsl.com>; Thu, 30 Jun 2011 12:17:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.974
X-Spam-Level:
X-Spam-Status: No, score=-102.974 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMcOM5qWD8gT for <sipcore@ietfa.amsl.com>; Thu, 30 Jun 2011 12:17:39 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 636F911E81E8 for <sipcore@ietf.org>; Thu, 30 Jun 2011 12:17:39 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ak0HAFLLDE6HCzI1/2dsb2JhbABFDadacAeoZoNzApsfAoMegxEEl0KLNw
X-IronPort-AV: E=Sophos;i="4.65,454,1304308800"; d="scan'208";a="254272674"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 30 Jun 2011 15:17:37 -0400
Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 30 Jun 2011 15:11:00 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Thu, 30 Jun 2011 15:17:36 -0400
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: "sipcore@ietf.org" <sipcore@ietf.org>
Date: Thu, 30 Jun 2011 15:17:35 -0400
Thread-Topic: 4244bis: Describing redirections
Thread-Index: AQHMN1iiQ88nfcLVj0Oe0yxoNpSGSQ==
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B222B1F571B@DC-US1MBEX4.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [sipcore] 4244bis: Describing redirections
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jun 2011 19:17:40 -0000

Here's another unpleasant case:

Suppose sip:A is redirected to sip:B.  The UAS for sip:B returns a 3xx
response, with "Contact: sip:C", but *without* an hi-target-param
(presumably because the UAS does not support H-I).  We want to be able
to document that sip:C was derived from sip:B (as opposed to the
default sip:A, which is also true, but gives less information), but we
cannot do so because we don't know what hi-target-param would be
correct.

The H-I at this point looks like:

    History-Info: <sip:A>;index=1,
    		  <sip:B?Reason=SIP%3Bcause%3D302>;index=1.1,
		  <sip:C>;index=1.2;??=1.1

but there is nothing that can be correctly put in place of "??".

Here is one possibility:

Have one H-I parameter solely for carrying the "predecessor" pointer.
Let's give it a really short name, like "p".

Have several other H-I parameters that are flags (they have no values)
that document *how* the current URI was derived from the URI pointed
to by "p".  (If we don't mind the additional bytes, vendors can add
further proprietary values, not in replacement of the standard values,
but as additional annotations to them.)  The types of redirection that
I know of are:

- "rc" ("registered contact") - Conversion of an AOR to its contact via
  a location service (as described in RFC 3261).

- "mp" ("mapping") - Replacement of a URI by another URI that (either
  in fact or is typical for this replacement operation) is "a
  different user", in that the new URI's identity (from a human point
  of view) is not subsumed in the old URI's identity.

- "gr" ("GRUU") - Replacement of a GRUU by the GRUU's contact value.
  (Strictly, we can probably omit indicating this as the "gr"
  situation can be determined by examining the URIs.)

- "hi" ("History-Info compatibility") - This hi-entry was added when
  the request entered an entity that supports History-Info because the
  last hi-entry (if any) did not match the Request-URI.

A typical example would be:

   History-Info: <sip:bob@example.com>;index=1;hi
   History-Info: <sip:bob@192.0.2.4?Reason=SIP%3Bcause%3D302>;index=1.1;p=1;rc
   History-Info: <sip:office@example.com>;index=1.2;p=1;mp
   History-Info: <sip:office@192.0.2.5>;index=1.2.1

Alternatively, we could have the "type of redirection" be the values
of a single parameter name, or we could append the codes to the
"index" value (which would save space).

Dale