Considering again how History-Info handles 3xx responses, let me
construct this example of multi-stage translation:
Let us assume that sip:[EMAIL PROTECTED] routes to proxy 1. Proxy 1
knows that (one) target of this URI is Alice's AOR,
sip:[EMAIL PROTECTED], which then routes to proxy 2. Proxy 2 knows the
phone address for sip:[EMAIL PROTECTED], which is sip:[EMAIL PROTECTED]
As the request reaches the UA at 10.1.1.1, the History-Info looks like
this:
History-Info: <sip:[EMAIL PROTECTED]>;index=1,
<sip:[EMAIL PROTECTED]>;index=1.1,
<sip:[EMAIL PROTECTED]>;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 PROTECTED] ->
sip:[EMAIL PROTECTED] ->
sip:[EMAIL PROTECTED]
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 PROTECTED]>;index=1,
<sip:[EMAIL PROTECTED];cause=302>;index=1.1,
<sip:[EMAIL PROTECTED]>;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 PROTECTED]
The apparent derivation of the destination address is:
sip:[EMAIL PROTECTED] ->
sip:[EMAIL PROTECTED]
(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 PROTECTED]>;index=1,
<sip:[EMAIL PROTECTED];cause=302>;index=1.1,
<sip:[EMAIL PROTECTED]>;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 PROTECTED]>;index=1,
<sip:[EMAIL PROTECTED];cause=302>;index=1.1,
<sip:[EMAIL PROTECTED];cause=486>;q=1.0;index=1.2;redir=1.1
<sip:[EMAIL PROTECTED]>;q=0.9;index=1.3;redir=1.1
As an elaboration, if we suppose UA sip:[EMAIL PROTECTED] redirected the
request to sip:[EMAIL PROTECTED], we could get:
History-Info: <sip:[EMAIL PROTECTED]>;index=1,
<sip:[EMAIL PROTECTED];cause=302>;index=1.1,
<sip:[EMAIL PROTECTED];cause=486>;q=1.0;index=1.2;redir=1.1
<sip:[EMAIL PROTECTED];cause=302>;q=0.9;index=1.3;redir=1.1
<sip:[EMAIL PROTECTED]>;index=1.4;redir=1.3
This illustrates that the forking structure is flat (arranging the
entries by their indexes):
sip:[EMAIL PROTECTED]
sip:[EMAIL PROTECTED]
sip:[EMAIL PROTECTED]
sip:[EMAIL PROTECTED]
sip:[EMAIL PROTECTED]
whereas the address derivation is more complex (placing each entry
under the entry referenced by its 'redir' parameter):
sip:[EMAIL PROTECTED]
sip:[EMAIL PROTECTED]
sip:[EMAIL PROTECTED]
sip:[EMAIL PROTECTED]
sip:[EMAIL PROTECTED]
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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
