[sipcore] #4: The new "hit" parameter is gonna cause problems

["sipcore issue tracker" <[e-mail]>]

#4: The new "hit" parameter is gonna cause problems
------------------------------------+---------------------------------------
 Reporter:  hkaplan@…               |       Owner:            
     Type:  defect                  |      Status:  new       
 Priority:  major                   |   Milestone:  milestone1
Component:  rfc4244bis              |     Version:  2.0       
 Severity:  In WG Last Call         |    Keywords:            
------------------------------------+---------------------------------------
 If I understand it right, this draft creates a new SIP/SIPS URI param
 named "hit", whose value indicates the type of H-I entry that will be
 added when processing the SIP/SIPS URI as a target.  It's used in the
 Contact-URI of a 3xx, or location service database entries, to
 differentiate registered-contact targets vs. mapped targets, right?  In
 other words, it's a way to signify when the retargeting is simply routing
 to the same identity vs. diverting to a new identity, right?  (I am
 inferring this, since there's no text I can find that actually just says
 that in a simple sentence)

 If so, it's got issues.  First, it assumes the processor of the 3xx
 response actually understands the new param - if a legacy proxy sends a
 request to a H-I-capable redirect server, and the redirect server encodes
 this "hit" param in the contact-uri of the 3xx, bad things happen.
 Second, it accounts for SIP/SIPS but not TEL URIs.  Third, it should be a
 header param not a URI param, I think (which would solve the previous
 issues).

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/sipcore/trac/ticket/4>
sipcore <http://tools.ietf.org/sipcore/>