Re: [sipcore] 4244bis: Describing redirections

That's why I proposed always adding the "rc" param when the req-uri is changed, regardless of how it was changed (except for the case of "mp"), so that the dotted-number pointer can always be there. 

In other words, don't have "rc", "gr" and "hi" - just "rc" and "mp", where "rc" now means 'req-uri changed'.  Because it doesn't actually matter how the req-uri got changed. (it's not reliably useful info to the UAS)

-hadriel

On Jun 30, 2011, at 3:17 PM, Worley, Dale R (Dale) wrote:

> 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