[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[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:list at a.example.com routes to proxy 1.  Proxy 1
knows that (one) target of this URI is Alice's AOR,
sip:10 at b.example.com, which then routes to proxy 2.  Proxy 2 knows the
phone address for sip:10 at b.example.com, which is sip:10 at 10.1.1.1.

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

    History-Info: <sip:list at a.example.com>;index=1,
	    <sip:10 at b.example.com>;index=1.1,
	    <sip:10 at 10.1.1.1>;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:list at a.example.com ->
		sip:10 at b.example.com ->
			sip:10 at 10.1.1.1

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:list at a.example.com>;index=1,
	    <sip:10 at b.example.com?Reason=SIP;cause=302>;index=1.1,
	    <sip:10 at 10.1.1.1>;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:10 at b.example.com.
The apparent derivation of the destination address is:

	sip:list at a.example.com ->
		sip:10 at 10.1.1.1

(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:list at a.example.com>;index=1,
	    <sip:10 at b.example.com?Reason=SIP;cause=302>;index=1.1,
	    <sip:10 at 10.1.1.1>;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:list at a.example.com>;index=1,
	    <sip:10 at b.example.com?Reason=SIP;cause=302>;index=1.1,
	    <sip:10 at 10.1.1.1?Reason=SIP;cause=486>;q=1.0;index=1.2;redir=1.1
	    <sip:10 at 10.2.2.2>;q=0.9;index=1.3;redir=1.1

As an elaboration, if we suppose UA sip:10 at 10.2.2.2 redirected the
request to sip:alice at c.example.com, we could get:

    History-Info: <sip:list at a.example.com>;index=1,
	    <sip:10 at b.example.com?Reason=SIP;cause=302>;index=1.1,
	    <sip:10 at 10.1.1.1?Reason=SIP;cause=486>;q=1.0;index=1.2;redir=1.1
	    <sip:10 at 10.2.2.2?Reason=SIP;cause=302>;q=0.9;index=1.3;redir=1.1
	    <sip:alice at c.example.com>;index=1.4;redir=1.3

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

	sip:list at a.example.com
		sip:10 at b.example.com
		sip:10 at 10.1.1.1
		sip:10 at 10.2.2.2
		sip:alice at c.example.com

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

	sip:list at a.example.com
		sip:10 at b.example.com
			sip:10 at 10.1.1.1
			sip:10 at 10.2.2.2
				sip:alice at c.example.com

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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip