Subject: [sipcore] 4244bis: Describing redirections

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 30 Jun 2011 15:17:35 -0400

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:[email-masked]>;index=1;hi
   History-Info: <sip:[email-masked]?Reason=SIP%3Bcause%3D302>;index=1.1;p=1;rc
   History-Info: <sip:[email-masked]>;index=1.2;p=1;mp
   History-Info: <sip:[email-masked]>;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

---

From: <[email-masked]>
Date: Fri, 1 Jul 2011 05:42:31 +0200

Hi Dale,
How often will this happen?
Due to the fact that the hi-target-param is an optional parameter I would put in nothing.
I think additional parameters would more confuse than help.

Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: [email-masked]
> [mailto:[email-masked]] Im Auftrag von Worley, Dale R (Dale)
> Gesendet: Donnerstag, 30. Juni 2011 21:18
> An: [email-masked]
> Betreff: [sipcore] 4244bis: Describing redirections
>
>    History-Info:
> <sip:[email-masked]?Reason=SIP%3Bcause%3D302>;index=1.1;p=1;rc
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>