[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Further observations about History-Info
Hi Dale,
I have a few clarifications added below [MB].
Mary.
-----Original Message-----
From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of
Dale.Worley at comcast.net
Sent: Friday, March 21, 2008 10:28 PM
To: sip at ietf.org
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: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.)
[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:
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
[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]
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
_______________________________________________
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