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

[Hadriel Kaplan <[e-mail]>]

Hi Mary,
Responses inline...

On Aug 28, 2010, at 6:03 PM, Mary Barnes wrote:


I do not think that this URI parameter will cause the problems you
mention - responses inline below [MB].

On Wed, Aug 25, 2010 at 6:46 PM, sipcore issue tracker
<[e-mail]<mailto:[e-mail]>> wrote:
> #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)

[MB] The parameter is only used in the Contact-URIs in the 3xx
response.  The current text is intended to imply that  the URI
parameter is set in the same manner that the target element is
determined, but we can add more text here to clarify that.  The reason
this has to be done by the Redirect server is that it is the one that
knows the mechanism by which those entries are determined.  The URI
parameter is used by proxies that implement 4244bis to determine the
value for the target parameter when it uses the specific contact-URI
to build an hi-entry. In this manner all the hi-entries have the same
format - i.e., you don't use the value of the URI parameter in the
hi-entries.[ /MB]


Right that's what I figured.

>  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.
[MB] I'm not at all clear about what bad things you think might
happen. If the proxy has not implemented 4244bis, then the URI
parameter is ignored (and may be removed by the proxy as can any URI
parameter). But, that doesn't provide any less functionality since a
proxy that only implements 4244 will NOT use the target  URI parameter
anyways and a proxy that doesn't implement History-Info at all totally
ignores the parameter.  [/MB]

If UA Alice does not understand History-Info and sends a request which goes to a redirect server that includes the hit param in the 3xx's contact, and the 3xx goes back to Alice, Alice will generate a request with a request-URI containing the hit param.  Let's say she got redirected to Proxy-B.  Proxy-B will now generate a H-I entry containing a hit parameter, and may or may not be able to process this req-uri.

>  Second, it accounts for SIP/SIPS but not TEL URIs.
[MB]  The value for this URI parameter is determined by the same
mechanisms by which the target parameter is determined by a proxy when
accessing a location service database.  So, it's not clear to me why
this URI parameter introduces a specific problem for tel-URIs.  [/MB]

Well for one the draft actually says the hit param is put in a SIP or SIPS URI, not TEL.
For another, a TEL URI's params become URI user parameters (not URI parameters) when converted to SIP.

> Third, it should be a
>  header param not a URI param, I think (which would solve the previous
>  issues).

[MB] It's not at all clear to me why you think this needs to be a
header parameter or how such would solve the problems you anticipate
(although that's because I don't understand what problems you think
will happen with the current approach).[/MB]

If it's a header param, then it's not part of the URI in the contact that becomes the request-uri of the recursed/new request, does not matter if it's SIP or TEL, and is ignored if not understood.

-hadriel