It is my contention that the "retargeting problem" is more complex than
people have been allowing for. In examples that have been presented,
there have usually been at most two relevant retarget/redirect
operations, and all of them have been associated with one single AOR.
For example, in section 2.1 of
draft-rosenberg-sip-target-uri-delivery-00, "Unknown Aliases", the
situation is:
sip:worley-al...@serviceprovider -> (alias address)
sip:wor...@serviceprovider -> (AOR)
sip:10.1.1.123 (registered contact)
Both of these mappings are tightly coupled with AOR
sip:wor...@serviceprovider.
But let us consider a more complicated example:
I am included as an element of a "hunt group" for some work-related
purpose: sip:h...@group -> sip:wor...@serviceprovider
I have a UA that registers: sip:wor...@serviceprovider -> sip:10.1.1.1
However, I am vacationing at a friend's Roman villa, and since I haven't
paid serviceprovider for call forwarding, I direct my home UA to forward
my calls: sip:10.1.1.1 -> sip:am...@fornitorediservizio
I take another UA to the Roman villa, where it registers:
sip:am...@fornitorediservizio -> sip:10.2.2.2
sip:h...@group ->
sip:wor...@serviceprovider ->
sip:10.1.1.1 ->
sip:am...@fornitorediservizio ->
sip:10.2.2.2
Each of these mappings is associated with a different
business/social/technological activity.
Now let us assume that a call initially directed to sip:h...@group
arrives as sip:10.2.2.2. What should my UA do with it? Or rather,
which request-URI should it consider to be the "real" target of the
call?
Once you look at it, the answer clearly depends on which of these URIs
the UA has knowledge of. If it is stupid, all it can understand is that
there is an incoming call, and alert me. If it has some knowledge about
the AOR sip:am...@fornitorediservizio, it can base its action on the
fact that the call came to that AOR, or in variants of this scenario,
that the call came via a request-URI that was related to this AOR.
If the phone understands that sip:wor...@serviceprovider has been
forwarded to sip:am...@fornitorediservizio, it can alert in a different
manner than it would for calls that are "just" to
sip:am...@fornitorediservizio (*). And if the phone knows about
sip:h...@group, it could provide yet another alternative action.
So I think that any solution to the "retargeting problem" that is going
to be practical in the long run -- that is, will be adaptable to future
networks where multiple "features" are ganged together -- because it is
the only solution that has "recursiveness", "If you can do it
[retargeting] once, you can do it many times." Recursiveness requires
that the entire request-URI history of the call be presented to the UAS,
and that the UAS will inspect that history for the earliest request-URI
that it has knowledge of to determine the "context" that it should apply
to this request.
Fortunately, History-Info is (or is close to being) the needed solution.
Conversely, all other proposed solutions fail to provide enough
information: They either provide the *next-to-last* request-URI
(P-Called-Party-Id) or the *first* request-URI (From or Target header).
This data is insufficient, as can be seen from the carefully constructed
example (*) above -- where the UAS does not understand the first
request-URI, and the last and next-to-last request-URIs do not contain
the information the UAS should act on -- only the 2nd of the 5
request-URIs contains the needed information.
Dale
_______________________________________________
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
