Re: [sipcore] 4244bis: Describing redirections

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: sipcore-bounces@ietf.org
> [mailto:sipcore-bounces@ietf.org] Im Auftrag von Worley, Dale R (Dale)
> Gesendet: Donnerstag, 30. Juni 2011 21:18
> An: sipcore@ietf.org
> Betreff: [sipcore] 4244bis: Describing redirections
>
> 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
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>