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

[Shida Schubert <[e-mail]>]

 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