Subject: Re: [sipcore] 4244bis: Describing redirections

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 1 Jul 2011 10:55:59 -0400

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:[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
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 7 Jul 2011 15:07:56 -0400

> From: Hadriel Kaplan [[email-masked]] 
> 
> 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)

Essentially, that proposal is to have two cases, "mp" and other.  That
does the job.  In any case, we need to have a way of tagging "other".
I'm not really sure that we need to distinguish any cases.

I think that the way to "solve" this question is to examine the
application logic -- what cases do we need to distinguish to ensure
that the application logic can make the decisions that people want to
make?

I've posted alternative application logic, but I suspect that version
is shaky too.  Others needs to review it.

Dale

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 7 Jul 2011 15:08:34 -0400

________________________________________
From: [email-masked] [[email-masked]]

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.
_______________________________________________

I think it is important to record the URI from which each URI is derived, to the
extent that it is possible to do so.  I think that relationship is more important then
the particular reason for each derivation.

But those beliefs are due to the way I've constructed the application logic, which is
very different from the application logic in the current draft.  There may be a better way
organize the application logic.  I think we need to review the application logic more carefully
and after examining how to make such decisions, it will be clearer what information needs
to be recorded in H-I.

Dale

---

From: Shida Schubert <[email-masked]>
Date: Sun, 10 Jul 2011 18:21:47 +0900

It's "mp" and "rc". The "other" you mention below is "rc". 

 You tag it with "mp" when you know for certain that 
the target user represented by the R-URI is different 
from one before. Otherwise you simply tag it with "rc".

 If the URI doesn't change when forwarded due to 
the Route header, you simply don't tag it because 
R-URI did not change. We used to have a tag called 
"np" (no-op) for that.

 Regards
  Shida

---

From: Shida Schubert <[email-masked]>
Date: Sun, 10 Jul 2011 20:02:01 +0900

+1
 
 In the example you indicated below, the entity receiving the 
3xx will log the Contact in 3xx in H-I and add "rc" as it will 
not know whether it is a different target user from the 
previous R-URI but it knows that Contact URI is different 
from the R-URI that cause the 3xx.  
 
 *Based on the new semantics of "rc" that everybody seems to 
   be in favor of.
 
 Regards
  Shida