Subject: [Sip] Further observations about History-Info

From: [email-masked]
Date: Fri, 21 Mar 2008 22:27:43 -0500

Considering again how History-Info handles 3xx responses, let me
construct this example of multi-stage translation:

Let us assume that sip:[email-masked] routes to proxy 1.  Proxy 1
knows that (one) target of this URI is Alice's AOR,
sip:[email-masked], which then routes to proxy 2.  Proxy 2 knows the
phone address for sip:[email-masked], which is sip:[email-masked].

As the request reaches the UA at 10.1.1.1, the History-Info looks like
this:

    History-Info: <sip:[email-masked]>;index=1,
	    <sip:[email-masked]>;index=1.1,
	    <sip:[email-masked]>;index=1.1.1

This clearly gives the logical derivation of the destination address
from the original request-URI (which is presumably also the To:
value):

	sip:[email-masked] ->
		sip:[email-masked] ->
			sip:[email-masked]

Now let us modify the scenario by changing proxy 2 not to route the
request itself, but rather to send a 302 response back to proxy 1.
Within SIP, any agent that potentially routes a request can choose to
send a 3xx response instead; in theory, all forking can be forced back
onto the originating UA if downstream agents always send 3xx responses
rather than routing.

With the 302 response, the History-Info looks like this (taking
liberties with the escaping):

    History-Info: <sip:[email-masked]>;index=1,
	    <sip:[email-masked]?Reason=SIP;cause=302>;index=1.1,
	    <sip:[email-masked]>;index=1.2

And this is the forking structure of the request.  But it looses the
logical structure of the translation; the UA at 10.1.1.1 does not see
that it received the request "through" its AOR, sip:[email-masked].
The apparent derivation of the destination address is:

	sip:[email-masked] ->
		sip:[email-masked]

(Although in practice the UA could guess from the "cause=302" on its
".1 sibling" that its fork was derived from the index=1.1 fork.)

And in the extreme case of a complex forking and retargeting
structure, if all other agents used 3xx responses to implement it, the
UAS would receive a History-Info whose indexes were all single
integers, obscuring completely how its address was derived.

As I proposed earlier, I think getting around this problem will
require adding an additional field-parameter to show how the address
derivations are performed.  In this example:

    History-Info: <sip:[email-masked]>;index=1,
	    <sip:[email-masked]?Reason=SIP;cause=302>;index=1.1,
	    <sip:[email-masked]>;index=1.2;redir=1.1

For diagnostic purposes, it would also be convenient if any other
field-parameters on the Contacts of a 3xx response were copied into
the derived History-Info elements.  Only the "q" parameter seems to be
useful information.  A typical "serial fork" would then look like this
when the request reached the second contact:

    History-Info: <sip:[email-masked]>;index=1,
	    <sip:[email-masked]?Reason=SIP;cause=302>;index=1.1,
	    <sip:[email-masked]?Reason=SIP;cause=486>;q=1.0;index=1.2;redir=1.1
	    <sip:[email-masked]>;q=0.9;index=1.3;redir=1.1

As an elaboration, if we suppose UA sip:[email-masked] redirected the
request to sip:[email-masked], we could get:

    History-Info: <sip:[email-masked]>;index=1,
	    <sip:[email-masked]?Reason=SIP;cause=302>;index=1.1,
	    <sip:[email-masked]?Reason=SIP;cause=486>;q=1.0;index=1.2;redir=1.1
	    <sip:[email-masked]?Reason=SIP;cause=302>;q=0.9;index=1.3;redir=1.1
	    <sip:[email-masked]>;index=1.4;redir=1.3

This illustrates that the forking structure is flat (arranging the
entries by their indexes):

	sip:[email-masked]
		sip:[email-masked]
		sip:[email-masked]
		sip:[email-masked]
		sip:[email-masked]

whereas the address derivation is more complex (placing each entry
under the entry referenced by its 'redir' parameter):

	sip:[email-masked]
		sip:[email-masked]
			sip:[email-masked]
			sip:[email-masked]
				sip:[email-masked]

The latter is more useful for attacking the "UA loose route" problem.

We still need to investigate what History-Info looks like if some of
the participating proxies do not support it.

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: Paul Kyzivat <[email-masked]>
Date: Sat, 22 Mar 2008 17:24:46 -0400

[email-masked] wrote:

[snip]

> the participating proxies do not support it.

Right! More importantly, the middle boxes that are intentionally trying 
to obscure it. It seems that it is common to want to hide all the 
details. I find it very unlikely that HI will ever be populated in a 
reliable enough way to be of use in making important decisions.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Sun, 23 Mar 2008 13:29:12 -0500

That sounds reasonable to me.

It is a bummer that History-Info is optional...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Friday, March 21, 2008 20:28
> To: [email-masked]
> Subject: [Sip] Further observations about History-Info
> 
> Considering again how History-Info handles 3xx responses, let 
> me construct this example of multi-stage translation:
> 
> Let us assume that sip:[email-masked] routes to proxy 1.  
> Proxy 1 knows that (one) target of this URI is Alice's AOR, 
> sip:[email-masked], which then routes to proxy 2.  Proxy 2 
> knows the phone address for sip:[email-masked], which is 
> sip:[email-masked].
> 
> This clearly gives the logical derivation of the destination 
> address from the original request-URI (which is presumably 
> also the To:
> value):
> 
> Now let us modify the scenario by changing proxy 2 not to 
> route the request itself, but rather to send a 302 response 
> back to proxy 1.
> Within SIP, any agent that potentially routes a request can 
> choose to send a 3xx response instead; in theory, all forking 
> can be forced back onto the originating UA if downstream 
> agents always send 3xx responses rather than routing.
> 
> With the 302 response, the History-Info looks like this 
> (taking liberties with the escaping):
> 
> And this is the forking structure of the request.  But it 
> looses the logical structure of the translation; the UA at 
> 10.1.1.1 does not see that it received the request "through" 
> its AOR, sip:[email-masked].
> structure, if all other agents used 3xx responses to 
> implement it, the UAS would receive a History-Info whose 
> indexes were all single integers, obscuring completely how 
> its address was derived.
> 
> As I proposed earlier, I think getting around this problem 
> will require adding an additional field-parameter to show how 
> the address derivations are performed.  In this example:
> 
> For diagnostic purposes, it would also be convenient if any 
> other field-parameters on the Contacts of a 3xx response were 
> copied into the derived History-Info elements.  Only the "q" 
> parameter seems to be useful information.  A typical "serial 
> fork" would then look like this when the request reached the 
> second contact:
> 
> As an elaboration, if we suppose UA sip:[email-masked] 
> redirected the request to sip:[email-masked], we could get:
> 
> This illustrates that the forking structure is flat 
> (arranging the entries by their indexes):
> 
> 	sip:[email-masked]
> 		sip:[email-masked]
> 		sip:[email-masked]
> 		sip:[email-masked]
> 		sip:[email-masked]
> 
> whereas the address derivation is more complex (placing each 
> entry under the entry referenced by its 'redir' parameter):
> 
> 	sip:[email-masked]
> 		sip:[email-masked]
> 			sip:[email-masked]
> 			sip:[email-masked]
> 				sip:[email-masked]
> 
> We still need to investigate what History-Info looks like if 
> some of the participating proxies do not support it.
> 
> Dale
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: [email-masked]
Date: Mon, 24 Mar 2008 21:56:30 -0500

From: Paul Kyzivat <[email-masked]>

   > the participating proxies do not support it.

What happens with History-Info if a proxy does not support it, a proxy
that is between the most-upstream proxy that adds History-Info and the
agent that is interpreting it?

There seem to be two messy aspects:

1) There must be an unambiguous way for the SIP agent to determine the
History-Info element that is the leaf that applies to it.  In
principle, there should be only one leaf whose URI matches the current
request-URI.  But in SIP, "address matching never works".  And if
there can be intermediate proxies rewriting the request-URI but not
updating History-Info, address matching is hopeless.

One solution is to rule that the element with the "rightmost" index is
always the applicable element.  This can probably be made to work, but
it requires that even when there is parallel forking, no fork can see
another fork until that fork has returned a final response.

Another solution is to specifically mark the applicable element with a
field-parameter.

2) The intermediate proxy can fork the request.  This results in two
or more downstream agents adding History-Info elements with the same
indexes.  Fortunately, only one of these gets back to the upstream
proxy, so from that proxy's point of view, assembling the History-Info
is unambiguous.

However, if a HERFP mechanism allows the upstream proxy to see more
than the History-Info for more than one fork under these
circumstances, it would have to integrate the History-Info's and may
have to renumber the elements.  Messy but possible.

That's only a problem if History-Info from one side of an SBC is
needed to make a decision on the other side of the SBC.  Or, if
History-Info must pass through a topology-hidden network, we would
have to ensure that the SBCs cooperate to transport the information
through the network.

Dale

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 1 Apr 2008 08:47:12 -0500

Hi Dale,

I have a few clarifications added below [MB].

Mary.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, March 21, 2008 10:28 PM
To: [email-masked]
Subject: [Sip] Further observations about History-Info

[MB] The idea of history-info is not to capture the "logical structure
of the translation". The objective is to capture the history of the
request as it makes its way to the destination. So, you do have a
complete tree of the request history and your "Although,.." is the
design intention.  [/MB]
                           
And in the extreme case of a complex forking and retargeting structure,
if all other agents used 3xx responses to implement it, the UAS would
receive a History-Info whose indexes were all single integers, obscuring
completely how its address was derived.
[MB] Again, History-Info wasn't intended to track how an address was
derived, but WHY a request was routed the way it was. So, you do know
through a series of 3xx, that retargeting occurred and you do know the
original target of the request and you do know the entity that handled
the 3xx responses. [/MB]

As I proposed earlier, I think getting around this problem will require
adding an additional field-parameter to show how the address derivations
are performed.  In this example:

For diagnostic purposes, it would also be convenient if any other
field-parameters on the Contacts of a 3xx response were copied into the
derived History-Info elements.  Only the "q" parameter seems to be
useful information.  A typical "serial fork" would then look like this
when the request reached the second contact:

[MB] History-Info wasn't intended as a diagnostic tool and it doesn't
seem reasonable to add all this other information to the entries. RFC
4244 clearly states that History-Info has limited diagnostic
capabilities:
  " Some diagnostic information for debugging SIP requests.  (Note that
     the diagnostic utility of this mechanism is limited by the fact
     that its use by entities that retarget is optional.)
The intention is that the SIP messages themselves can be captured if you
want to run diagnostics (acknowledging that you may not be able to get
all traces at all nodes). [/MB]

	

	sip:[email-masked]
		sip:[email-masked]
		sip:[email-masked]
		sip:[email-masked]
		sip:[email-masked]

whereas the address derivation is more complex (placing each entry under
the entry referenced by its 'redir' parameter):

	sip:[email-masked]
		sip:[email-masked]
			sip:[email-masked]
			sip:[email-masked]
				sip:[email-masked]

We still need to investigate what History-Info looks like if some of the
participating proxies do not support it.

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
_______________________________________________
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