Opened 11 years ago

Last modified 11 years ago

#4 new defect

The new "hit" parameter is gonna cause problems

Reported by: hkaplan@… Owned by:
Priority: major Milestone: milestone1
Component: rfc4244bis Version: 2.0
Severity: In WG Last Call Keywords:
Cc:

Description

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).

Change History (1)

comment:1 Changed 11 years ago by worley@…

"hit" is defined as a URI-parameter on the Contact values in 3xx responses, but in reality, it is metadata *describing* the URI, not *part* of the URI. Naively it would seem that "hit" should be a header parameter.

This change would require some parallel changes in the description of proxy functioning.

This change would remove some processing steps in which the "hit" URI-parameter value is removed from the URI portion of the Contact value.

This change would also aid backward compatibility, in that a proxy that does not understand 4244bis that receives a 3xx response with a Contact header that contains a "hit" header parameter would automatically not transfer the "hit" value to the request-URIs of further forked requests.

Note: See TracTickets for help on using tickets.