Subject: [Sip] History-Info and retargeting

From: [email-masked]
Date: Mon, 24 Mar 2008 22:14:18 -0500

The core of the "retargeting" problem is that (relative to the current
situation), some rewritings of the request-URI are considered to be a
change of destination, a change of "name", and others are considered
to be indications of how to progress to the "implementation" of a
"name".  Current SIP does not distinguish these two.  And so, there
can be no hard-and-fast rules within current SIP as to what
constitutes a retargeting vs. a routing.  It is additional information
that must be supplied from a higher layer of the architecture.

The current proposals are fundamentally mechanisms to capture the
"target name", the request-URI as it was after the most recent
retargeting operation (or at the UAC, if there have been no
retargetings).

In draft-rosenberg-sip-ua-loose-route-02, the target name is kept in
the request-URI, and rewritings that are routings put their URIs in
Route headers.

In draft-holmberg-sip-target-uri-delivery-01, the target name is
stored in the Target header.

If we want to use History-Info for this purpose, we need a further
indicator, because History-Info does not now distinguish retargeting
from routing.  If we marked the URIs generated by retargeting
operations (and initial request-URIs, which are similar) with the
'target' field-parameter, then this example in
draft-rosenberg-sip-ua-loose-route-02:

   INVITE sip:[email-masked] SIP/2.0
   Route: <sip:[email-masked];lr>
   From: sip:[email-masked];tag=555af9g7
   To: sip:[email-masked]

would be expressed as:

   INVITE sip:[email-masked] SIP/2.0
   From: sip:[email-masked];tag=555af9g7
   To: sip:[email-masked]
   History-Info: <sip:[email-masked]>;target;index=1,
	<sip:[email-masked]>;index=1.1;current

To find the target name, the recipient reads up the stack of
History-Info elements starting at the current element until it finds
an element tagged with 'target'.  Note that for this to work, the
elements need to be traversable in "address translation" order rather
than "forking" order; something like the 'redir' field-parameter needs
to be implemented.

An interesting consequence of this method is that the recipient can
tell not only the current target name, but the entire sequence of
target names, which may yield additional information.  (One can
imagine complex sequences of redirection what a subordinate set of
routing/retargeting is needed to get from a target name to its
destination.)

Dale
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 25 Mar 2008 08:12:23 +0200

> than "forking" order; something like the 'redir' field-parameter needs

this sounds very complicated to me.  it is unlikely that sip ua vendors
would ever implement such algorithms.  same for proxies if they would
first need to process such things in order to be able to add new
components.

-- juha