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

[Mary Barnes <[e-mail]>]

Hadriel,

Okay, I see your point.   So, rather than escaping a URI parameter in
the Contact URI, you are suggesting to define a new header parameter
for the Contact header and History-Info headers. That seems like a good idea,
although not a small change.  Per the response to issue #41, I also
think it's a good idea to
have the index for all the values.

The Tel URIs are actually a separate concern because even with
History-Info header as defined in 4244, we were escaping the privacy
header and reason header in the targeted-to-URI to avoid redefining
those, so you have the same issue there.

We had some discussion at IETF-75 about Tel-URIs and the
conclusion there was that they were considered out of scope, but if
someone wanted to provide text, we could considering how to support.
http://www.ietf.org/proceedings/75/minutes/sipcore.html#Tel-URIs

My suggestion is that we document these restrictions with regards to
History-Info
and Tel-URIs - i.e., they'll be properly captured, but won't have the reason
or per-entry privacy attributes.  I don't see the point in crafting a
sub-optimal or complex solution
just so that Tel-URIs can be supported.

Thanks,
Mary.




On Mon, Aug 30, 2010 at 3:48 PM, Hadriel Kaplan <[e-mail]> wrote:
>
> On Aug 30, 2010, at 1:51 PM, Hadriel Kaplan wrote:
>
>>>
>>> > 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.
>
> And once we agree on it being a header param, the next thing I'll ask for is to not make it a "hit=" but rather just the two params "rc" and "mp".  Then all the proxy needs to do is copy the contact-URI to H-I, as it would have done with a request-URI.  It doesn't have to look for the "hit" param and convert its value to a new param name.  Seems simpler to me.
>
> -hadriel
>
>