Hans Erik,
Following your detailed description, it seems that the UAS serving a
freephone number could receive one of the following (assuming H-I is
supported by all relevant nodes):
1) H-I containing:
- the freephone number (tagged);
- the AoR (tagged);
- the contact URI (not tagged).
Or
2) H-I containing:
- the freephone number (tagged);
- the contact URI (not tagged).
The latter would occur when the same proxy translates the freephone
number (via the AoR) to the contact directly.
So how does this help the UAS to figure out the freephone number? It
seems the UAS would have to search back through the tagged entries
looking for one that matches a freephone number it recognises? Does the
tagging really add much value?
John
________________________________
From: [email protected] [mailto:[email protected]] On
Behalf Of Hans Erik van Elburg
Sent: 12 March 2009 21:26
To: Mary Barnes
Cc: Hans Erik van Elburg; [email protected]
Subject: Re: [Sip] Issue 3 - two tags (was RE:
I-DACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
Inline...
/Hans Erik van Elburg
On Thu, Mar 12, 2009 at 7:10 PM, Mary Barnes
<[email protected]> wrote:
I think there is another solution proposal that we
should pursue for issue 3 identified in the email summary sent by Shida
earlier this week - I've snipped all the text except for that issue and
issue 2 in the summary below. I do think the discussion has confounded
the two issues and I think it ought to be clarified that if we agree to
the two tags per issue 3, that the options for the terminology MUST
change. And, perhaps this is why the other discussion threads aren't
progressing well.
Agree.
So, Hans Erick, I would like clarification on as to your
view on the solution:
In general, ISTM that one of the issues we're having in
this terminology thread is that you are considering the solution to be
that the hi-entries are tagged as they
are added to the request. And, just for clarification
from my perspective, that is NOT the solution in either 4244bis or
target-uri.
The principle should be that the node that has the information
about what type of rewrite is performed should add the tag. (This is
done by the current target-uri draft allthough the solution is not
complete.)
For the freephone service, that would be the freephone service.
For the AOR that is the home proxy.
Assume that the freephone service receives an INVITE request
that either
1. received request contains History-Info header that contains
the freephone number (as in R-URI) as last entry, THEN when rewriting
the Request-URI it has to tag that existing received entry AND add the
new entry with the new value of the Request-URI. (I think that was how
History-Info works right.)
2. received request contains History-Info header that does not
contain the freephone number as last entry, THEN when rewriting the
Request-URI it has add an entry with the freephone number and tag that
entry AND add the new entry with the new value of the Request-URI.
3. received request does not contain a History-Info header, THEN
when rewriting the Request-URI it has to add an entry with the freephone
number and tag that entry AND add the new entry with the new value of
the Request-URI.
After forwarding this request it arrives at the home proxy:
1. received request contains History-Info header that contains
the AOR (as in R-URI) as last entry, THEN when rewriting the Request-URI
it has to tag that existing received entry AND add the new entry with
the new value of the Request-URI i.e. the registered contact. (I think
that was how History-Info works right.)
2. received request contains History-Info header that does not
contain the AOR (as in R-URI) as last entry, THEN when rewriting the
Request-URI it has add an entry with the AOR and tag that entry AND add
the new entry with the new value of the Request-URI i.e. the registered
contact.
3. received request does not contain a History-Info header, THEN
when rewriting the Request-URI it has to add an entry with the AOR as in
the Request-URI and tag that entry AND add the new entry with the new
value of the Request-URI i.e. the registered contact..
I don't view it as a problem necessarily if you'd like
to pursue an alternate solution, we just need to be clear that's what
you're advocating. In that case, I would agree the "retarget" is not an
appropriate tag for the entries, as you don't know at the point in time
that you add an hi-entry that it will be retargeted. In the case of this
approach to the solution, you do have to alter the mechanism for
determining the hi-entry that your services would want to use. You would
need to skip the most recent/last hi-entry (as that would contain the
same as the Request-URI in the incoming request), since it would be
tagged if you use this solution approach.
Yes, but only if the previous proxy added it. As History-Info is
optional one never knows really.
Thus, you'd have to take the next hi-entry that you find
that has the desired "tag". I will posit that we could accomplish this
solution without any changes to 4244 by just registering new SIP URI
parameter(s). And, that's not to say we shouldn't do a 4244bis as
there are other issues to address in that document, but that allows the
target-uri to describe a solution that makes use of 4244bis "as is".
Are you proposing to decouple the target-uri and the 4244bis
discussion?
So, feedback on this specific point (from Hans Erik and
others) would be appreciated.
Mary.
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip
