Re: [sipcore] 4244bis: Describing redirections

 +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

On Jul 1, 2011, at 11:55 PM, Hadriel Kaplan wrote:

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