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

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 15 Jun 2011 15:52:21 -0400

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

---

From: Shida Schubert <[email-masked]>
Date: Thu, 16 Jun 2011 16:41:31 +0900

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:

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 17 Jun 2011 12:07:22 -0400

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

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 17 Jun 2011 16:02:56 -0400

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

I'm not so concerned about the different categories of redirection and how we record them,
but that there will be some redirections to which neither "rc" nor "mp" will apply.
In those cases, there is no way to record which URI this URI is derived from, because the
back-pointer is the value of rc/mp.

And it doesn't look like the draft thinks about that case much.  There three examples that
I can find where a URI is not the same as its parent but does not have an rc/mp parameter:

Messages F6 and F9 in B.1 and one message in B.2:

   F6 INVITE example.com -> office

   INVITE sip:[email-masked] SIP/2.0

   History-Info: <sip:[email-masked]>;index=1
   History-Info: <sip:[email-masked]?Reason=SIP%3Bcause%3D302>;\
                 index=1.1;rc=1
   History-Info: <sip:[email-masked]>;index=1.2;mp=1
   History-Info: <sip:[email-masked]>;index=1.2.1 <------------------

   F9 INVITE example.com -> home

   INVITE sip:[email-masked] SIP/2.0

   History-Info: <sip:[email-masked]>;index=1
   History-Info: <sip:[email-masked]?Reason=SIP%3Bcause%3D302>;\
                 index=1.1;rc=1
   History-Info: <sip:[email-masked]>;index=1.2;mp=1
   History-Info: <sip:[email-masked]?Reason=SIP%3Bcause%3D408>;\
                 index=1.2.1>;index=1.2.1
   History-Info: <sip:[email-masked]>;index=1.3;mp=1
   History-Info: <sip:[email-masked]>;index=1.3.1 <----------------------

  |                |   INVITE sip:[email-masked];p=x
  |                |--------------->|                |
  | History-Info: <sip:[email-masked]>;index=1
  | History-Info: <sip:[email-masked];p=x>;index=1.1

[Though the last one was due to anonymization.]

I think we need to adjust the parameters to put the back-pointer into a separate
parameter from the "type of redirection" information.

Dale

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 21 Jun 2011 16:07:18 -0700

On Jun 17, 2011, at 9:07 , Hadriel Kaplan wrote:

> 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),
+1

---

From: Shida Schubert <[email-masked]>
Date: Fri, 24 Jun 2011 21:16:49 +0900

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

---

From: Shida Schubert <[email-masked]>
Date: Fri, 24 Jun 2011 21:16:58 +0900

I believe Hadriel's suggestion of adding the "rc" tag 
whenever R-URI is changed. 

 I think it might have been overlooking the message as 
I think the 2 former entries you pointed out obviously is a 
contact address, which should have had the "rc" parameters. 

 But again as it currently limits the use only when the address 
is registered via REGISTER, this could easily happen in 
the deployment. 

 Regards
  Shida