Re: [sipcore] 4244bis-05: the infamous "rc" param

[Shida Schubert <[e-mail]>]

Hadriel;

 So you are suggesting to change the semantics so 
"rc" will be used for any retarget where R-URI is modified 
while the target of the R-URI represents the same user?

 And to use "mp" as defined currently, which is when 
R-URI is changed and the target of the R-URI represents 
a different user. 

 I thought about this a bit and it will solve some issues 
relating to RFC4244. As RFC4244 doesn't add "rc", 
4244bis compliant UAS would assume the entry without 
"rc" to be "not registered via REGISTER", making the 
semantics of "rc" even less relevant. 

 So I think this is a good idea to change the semantics of 
"rc". 

 Regards
  Shida

On Jun 18, 2011, at 1:07 AM, Hadriel Kaplan wrote:

> 
> I was one of the ones arguing for reducing/removing the other tags as "fluff", but that included removing the "rc" tag.  That was because, at the time there was an "aor" tag - the "aor" and "mp" tags were the only ones actually used by receiving UAS applications, so the other tags just add confusion.  
> 
> Now there is no "aor" tag, because it's incredibly difficult for a system to know when a URI is an "Address of Record".  But having the "rc" tag doesn't solve the problem - it just moves it around. Now you're just *implying* the entry before the "rc" tagged one is an AoR, which is just as error prone as before.
> 
> It's error-prone because:
> 1) It will have false-positives - cases where the entry prior to the "rc" tagged one is not the one the application actually wants.
> 2) It will have false-negatives - cases where there is no "rc" tag because the UAS did not use Registration model to receive a request, or the intermediate proxy/ies did not know that it was due to a registration.
> 
> My point is that the real purpose of using History-Info and having these tags is to enable applications on the UAS.  Some of those applications need to find target URIs that were changed along the way.  *Why* they were changed matters, but not *how* they were changed.  Whether it was due to a SIP-Registration database, ENUM database, LDAP lookup, or reading tea leaves doesn't matter.
> 
> What "rc" should actually stand for is "Request-uri Changed".  It should be populated in ALL cases where the request-URI is changed, but where the new target is still the same identity (ie, it's not an "mp" tag instead), and it should still use an index to point to the previous H-I entry it changed from as it does now.
> 
> -hadriel
> 
> 
> On Jun 16, 2011, at 3:41 AM, Shida Schubert wrote:
> 
>> I don't recall exactly why we decided to limit the scope of "rc". 
>> 
>> I vaguely remember the debate on allowing "rc" to be used for resolution 
>> beside the current intended context, resulting in convoluting the 
>> tag and overloading it making it indeterministic. I think it was about non-REGISTER 
>> could raise the question of "How do you know that it was for AoR-to-Contact resolution?". 
>> 
>> For example when barnes-sipcore-rfc4244bis-02 has 4 tags of which 
>> "cc" covers the cases you expressed the concerns for, but I can't recall 
>> the exact reason why we limited the scope. 
>> 
>> 	"rc": The entry is a contact that is bound to an AOR in an
>>        abstract location service.  The AOR-to-contact binding has been
>>        placed into the location service by a SIP Registrar that
>>        received a SIP REGISTER request.
>> 
>>     *  "cc": The entry is a contact that is bound to an AOR in an
>>        abstract location service.  The AOR-to-contact binding has been
>>        placed into the location service implicitly through a means
>>        other than a SIP Registrar acting on a REGISTER request, e.g.,
>>        the user may be currently logged into a Web Portal that
>>        implements a Presence and IM service, or it could be manually
>>        configured.
>> 
>>     *  "mp": The entry is a URI that represents another user.  This
>>        occurs in cases where a request is statically or dynamically
>>        retargeted to another user.
>> 
>>     *  "rt": The entry is "routed", i.e., it is either a no-op like a
>>        proxy forwarding, predetermined by a maddr in the Request-URI,
>>        or the Request-URI is changed to a new URI that represents the
>>        same user, and is not a contact in a SIP Registrar.
>> 
>> By the time it was revised to 03 the tag was reduced to the two we 
>> currently have. So there was a conclusion made sometime between the 
>> 02 and 03. 
>> 
>> I personally don't have a strong opinions on this and would be happy to change 
>> the definition of the "rc" tag but I wasn't the one who raised the concerns, so I think 
>> we need to find those that lead us to the current status on this issue.. 
>> 
>> Regards
>> Shida
>> 
>> On Jun 16, 2011, at 4:52 AM, Hadriel Kaplan wrote:
>> 
>>> Howdy,
>>> I still have concerns regarding the "rc" param in this draft.  Right now, the "rc" is only added for request-uri retargeting due to AoR-to-contact resolution, populated by a SIP Registrar from a REGISTER.  That's it.  So "rc" is not added due to static/provisioned Aor-to-contact mappings, for example.  Nor is it added due to ENUM resolution.  Nor, apparently, if the Proxy doing the routing doesn't know how the database's entry was populated.
>>> 
>>> So... why does it matter how the abstract location database got populated?   Example applications in this draft, as well as in rfc4244bis-callflows, apparently rely on the existence of an "rc" param to perform their logic.  Afaict, however, it's NOT the case that they actually care whether it was due to a REGISTER or not.  They only care about finding the first or last relevant URI they understand.
>>> 
>>> For example: in a sip trunking context, a la Martini-GIN, request routing to GIN-PBX bulk-registered contacts would get the "rc".  But request routing to PBX's UAs using 3263 or static provisioning would not.  Should the application service logic or behavior be different for these different ways of deploying SIP trunks?
>>> 
>>> -hadriel
>>> 
>>> _______________________________________________
>>> sipcore mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/sipcore
>> 
>