Subject: [Sip] Problems with History-Info

From: "Dale Worley" <[email-masked]>
Date: Sun, 01 Feb 2009 14:53:56 -0500

To get discussion going for 2009, let me start with some complaints
about the History-Info header.

One problem is identifying which value in the History-Info header
corresponds to the request carrying the header, that is, which branch
of the History-Info request tree represents the current request.

Reading RFC 4244, it's clear that what is intended is that the
History-Info values will be written in depth-first tree-walk order,
and that syntactically *last* value corresponds to the request
carrying the History-Info header.  Neither of these principles is
stated explicitly as far as I can tell.

Difficulty arises when there is parallel forking, or any similar
situation when a request has multiple redirects or retargets that
become known in one processing step.  If one maintains the rule that
the enclosing request corresponds to the last History-Info value, one
must choose among:

(Assume that sip:[email-masked] has been retargeted to
sip:[email-masked] and sip:[email-masked].) 

1.each derived request carries only one of the new History-Info values

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

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

2.each derived request carries only the new History-Info values that
  are "before" (in some ordering) the one for the current request

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

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

3.each derived request carries all of the new History-Info values, but
  in each request, they are ordered so that the value corresponding to
  the request is last

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

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

Solutions 1 and 3 are troublesome because the generated History-Info
values are not consistent between the derived requests, and solutions
1 and 2 are troublesome because the downstream network elements are
given less information than is available about the forking of the
request.

Note that this isn't just a theoretical problem,
draft-rosenberg-sip-target-uri-delivery-00 is already running up
against it (section 5):  "Furthermore, if that URI had an 'index' of
N, the URIs with indices N.M for all M, are the registered contacts to
that URI."  If the I-D is taken at face value, solution 3 must be
used, giving different History-Info values on different derived
requests.

Let us then consider putting all known targets of a request in
History-Info, but not require that the last History-Info value
corresponds to the containing request.  In terms of the above example,
both derived requests would have the same History-Info header:

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

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

If we do this, we need to be able to identify the value that
corresponds to the current request by some method other than the index
values and syntactic ordering.

In a perfect world, we could compare the request-URI with the URIs in
History-Info to see which one matches.  However, this fails if:

- two URIs in History-Info are the same (In theory, this should not
  happen, but it can happen sensibly if two derived requests differed
  substantially in some manner which could affect the ultimate
  resolution of the request-URI; e.g., caller preferences.)

- if an intermediate proxy has changed the request-URI but not updated
  History-Info (In this case, we want to know which History-Info value
  corresponds to the most recent parent request that was logged in
  History-Info.)

A more reliable solution would be to add a "current" marker to the
leaf of the History-Info tree that corresponds to the containing
request.  In the example above:

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

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

----------------------------------------------------------------------

A second problem with History-Info as it is currently structured is in
the handling of requests generated as a consequence of recursing on
3xx responses.

History-Info as it is now defined correctly shows the "forking
structure" of a request.  But we also want to know the "derivation" of
the current request-URI, the sequence of transformations from the
original request-URI (presumably the same as the To URI) to the
current request-URI.  Assuming that the transformations are done in
the ordinary manner by proxies, History-Info carries the needed
information.  From RFC 4244 section 4.5:

   UA1                      Proxy1                    Proxy2                       UA2

   |                          |                         |                           |
   |--INVITE sip:Bob@P1... -->|                         |                           |
      History-Info: <sip:[email-masked]>;index=1
   |                          |-INVITE sip:Bob@P2... -->|                           |
                                History-Info: <sip:[email-masked]>;index=1,
                                              <sip:[email-masked]>;index=1.1
   |                          |                         |                           |
   |                          |                         |-INVITE sip:User2@UA2...-->|
                                                          History-Info: <sip:[email-masked]>;index=1,
                                                                        <sip:[email-masked]>;index=1.1,
                                                                        <sip:[email-masked]>;index=1.1.1

In the last INVITE, starting with the last URI and working our way up
the tree, we see that the URI sequence is:

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

However, if one of the transformations is supplied by a 3xx response
(e.g., if the request is sent to a "redirect server"), the
History-Info data does not effectively show the source of the current
request-URI:

   UA1                      Proxy1                    Proxy2      UA2

   |                          |                         |          |
   |--INVITE sip:Bob@P1... -->|                         |          |
      History-Info: <sip:[email-masked]>;index=1
   |                          |-INVITE sip:Bob@P2... -->|          |
                                History-Info: <sip:[email-masked]>;index=1,
                                              <sip:[email-masked]>;index=1.1
   |                          |<-- 302
                                   Contact: <sip:[email-masked]>
   |                          |                         |          |
   |                          |-INVITE sip:User2@UA2...----------->|
                                History-Info: <sip:[email-masked]>;index=1,
                                              <sip:[email-masked]?Reason=SIP%3Bcause%3D302>;index=1.1,
                                              <sip:[email-masked]>;index=1.2

The apparent URI sequence is:

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

There is no unambiguous way determine that the target
sip:[email-masked] came from the 302 response to the request to
sip:[email-masked].

What is needed is a pointer from a History-Info value to the value
representing the request which yielded the 3xx response that cause the
value in question.  I suggest using a parameter named "3xx" for this
purpose, so that the last request in the above example becomes:

    INVITE sip:[email-masked]
    History-Info: <sip:[email-masked]>;index=1,
		  <sip:[email-masked]?Reason=SIP%3Bcause%3D302>;index=1.1,
		  <sip:[email-masked]>;index=1.2;3xx=1.1

Which this additional information present, the predecessor of a listed
URI is either the URI of its 3xx value (if present), or its parent in
the tree.  This allows us to recover the URI transformation sequence:

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

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: "Mary Barnes" <[email-masked]>
Date: Wed, 11 Feb 2009 10:44:37 -0600

Hi Dale,

Sorry for the delay in responding - responses below [MB].

Mary.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Worley, Dale (BL60:9D30)
Sent: Sunday, February 01, 2009 1:54 PM
To: SIP
Subject: [Sip] Problems with History-Info

One problem is identifying which value in the History-Info header
corresponds to the request carrying the header, that is, which branch of
the History-Info request tree represents the current request.

Reading RFC 4244, it's clear that what is intended is that the
History-Info values will be written in depth-first tree-walk order, and
that syntactically *last* value corresponds to the request carrying the
History-Info header.  Neither of these principles is stated explicitly
as far as I can tell. 

[MB] RFC 4244 is clear that the entries are in a tree structure - you
are correct that we don't identify it as a "depth-first" and perhaps we
can add that, although I think it's quite clear from examples and
normative text.  As far as  your concern wrt to "synctactically *last*
value corresponds to the request carrying HI", I'm not sure what you
mean here. [/MB]

Difficulty arises when there is parallel forking, or any similar
situation when a request has multiple redirects or retargets that become
known in one processing step.  If one maintains the rule that the
enclosing request corresponds to the last History-Info value, one must
choose among:

[MB] There is not a problem here. The spec is very clear about what
happens when a proxy (sip:[email-masked]) retargets either sequentially
or in parallel.  And, RFC 4244 defines a 4th choice not listed below:  

This is specified in section 4.3.3.1.3, in particular steps 2 and 3
result in the above HI entries with an example of this behavior in
section 4.5 (sorry no figure number - something we should add in the
-bis).  Per the spec, there are never any entries that are identical -
if there, it's a bug. If you think there is text in RFC 4244 that
contradicts this, please identify it and we can clarify it in the -bis. 
[/MB]

(Assume that sip:[email-masked] has been retargeted to sip:[email-masked]
and sip:[email-masked].) 

Note that this isn't just a theoretical problem,
draft-rosenberg-sip-target-uri-delivery-00 is already running up against
it (section 5):  "Furthermore, if that URI had an 'index' of N, the URIs
with indices N.M for all M, are the registered contacts to that URI."
If the I-D is taken at face value, solution 3 must be used, giving
different History-Info values on different derived requests.

If we do this, we need to be able to identify the value that corresponds
to the current request by some method other than the index values and
syntactic ordering.

A more reliable solution would be to add a "current" marker to the leaf
of the History-Info tree that corresponds to the containing request.  In
the example above:

A second problem with History-Info as it is currently structured is in
the handling of requests generated as a consequence of recursing on 3xx
responses.

History-Info as it is now defined correctly shows the "forking
structure" of a request.  But we also want to know the "derivation" of
the current request-URI, the sequence of transformations from the
original request-URI (presumably the same as the To URI) to the current
request-URI.  Assuming that the transformations are done in the ordinary
manner by proxies, History-Info carries the needed information.  From
RFC 4244 section 4.5:

   UA1                      Proxy1                    Proxy2
UA2

   |                          |                         |
|
   |--INVITE sip:Bob@P1... -->|                         |
|
      History-Info: <sip:[email-masked]>;index=1
   |                          |-INVITE sip:Bob@P2... -->|
|
                                History-Info:
<sip:[email-masked]>;index=1,
 
<sip:[email-masked]>;index=1.1
   |                          |                         |
|
   |                          |                         |-INVITE
sip:User2@UA2...-->|
                                                          History-Info:
<sip:[email-masked]>;index=1,

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

However, if one of the transformations is supplied by a 3xx response
(e.g., if the request is sent to a "redirect server"), the History-Info
data does not effectively show the source of the current
request-URI:

   UA1                      Proxy1                    Proxy2      UA2

   |                          |                         |          |
   |--INVITE sip:Bob@P1... -->|                         |          |
      History-Info: <sip:[email-masked]>;index=1
   |                          |-INVITE sip:Bob@P2... -->|          |
                                History-Info:
<sip:[email-masked]>;index=1,
 
<sip:[email-masked]>;index=1.1
   |                          |<-- 302
                                   Contact: <sip:[email-masked]>
   |                          |                         |          |
   |                          |-INVITE sip:User2@UA2...----------->|
                                History-Info:
<sip:[email-masked]>;index=1,

[MB] I don't see a problem here, as you can indeed determine that the
request was retargetted to User2 as a result of the 3xx - Proxy 1
absolutely knows that and that's the reason why the "reason" is added to
the previous HI entry - i.e., the rule being that the reason is
associated with the "Why the request was retargeted?" from the previous
HI entry ([email-masked]) to the new HI entry [email-masked]).
Thus, you can derive the sequence from the above -i.e., it's ALL there
in that last INVITE.  It does require that you look for the reason, but
you really don't need the redundant data. An old, old version of this
document actually did have redundant data in that the "old" and "new"
were captured in each entry. The current approach is that if the "old"
isn't captured, then the entity retargeting captures it along with the
"new" to ensure that you have the entire chain. If you can point to the
specific text that seems to introduce the gap you suggest, that would be
helpful and we can make sure it's clear in the -bis. 
[/MB]

	

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

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: "Dale Worley" <[email-masked]>
Date: Wed, 11 Feb 2009 16:44:25 -0500

> value corresponds to the request carrying HI", I'm not sure what you

What I see is that all examples are presented in depth-first order, and
various operations are described in terms of "adding a value".  But I
don't see a specification that the values must be listed in depth-first
order, nor that the added values must go in a certain position in the
list of values.  Given that the values are tagged with indexes, I could
interpret the text to mean that the values are associated based on their
index values, and it was just convenience or accident that all examples
presented in the RFC were written in depth-first order.

In regard to "syntactically last", I was looking at the question of
knowing which entry in History-Info is meant to describe the request
that contains it.  It seems from the examples that the current request
is described by the linearly last (lowest-rightmost in tree order)
element, but it's not clear that is intended to be specified.  One could
search for the request-URI in the History-Info elements, but (1) URI
matching is treacherous, and (2) one can construct cases where the same
request-URI can sensibly appear in more than one incarnation of an
INVITE.  It seems that the intention is that the last element is
expected to match the current request, but I don't see that stated.

> contradicts this, please identify it and we can clarify it in the -bis. 

I'll grant I overlooked that example.  The implication is that the tree
presented in History-Info can be *incomplete*, there can be a 1.2 branch
without a 1.1 branch, not because the user used weird numbering, but
because there is a 1.1. branch that is not being described in this
History-Info -- something that is not so common in representations of
trees, and doesn't seem to be explicitly pointed out in the text.

In regard to 4.3.3.1.3, the text is not very clear if you don't already
know what it means:

        Retargeting within a Proxy - subsequent instance: For each
        subsequent retargeting of a request by the same proxy, another
        branch is added.  With the index for each new branch calculated
        by incrementing the last/lowest digit at the current level, the
        index in the next request forwarded by this same proxy,
        following the example above, would be 1.1.2.

What is not stated is that the first forked request gets the xxx.1 value
added to its History-Info, the second forked request gets the xxx.2
value added to its History-Info (but not the xxx.1 value), etc.  When I
read this, I assumed that "instance" meant History-Info value, and that
each forked request was expected to have the same set of History-Info
values, namely the whole set generated by the forking, of which the
first "instance" would be numbers xxx.1, etc.

>                       <sip:[email-masked]>;index=1.1

So the correct answer is case 1, but modified in that the index for
sip:[email-masked] is 1.2; the numbering was globally consistent across
all the History-Info values, but that each value was a subset of the
global forking tree.

> helpful and we can make sure it's clear in the -bis. 

I was thinking of the case where there are two or more forks preceding
the current fork that have returned 3xx.  It seems that you'd get H-I
like:

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

>From that, I don't see how to determine whether UserC was generated from
UserA1 or UserB, or for that matter, if it was derived from UserA.

Perhaps there is an unstated rule that History-Info should contain only
that subset of the global forking tree that describes requests that are
logically ancestral to the request that contains it?

(Oh, yeah, and the example in RFC 4244 from which I derived the above
example is:

      F12 486 Busy Here Proxy1 -> UA1

      SIP/2.0  486 Busy Here
      Via: SIP/2.0/UDP example.net:5060
      From: Alice <sip:[email-masked]>
      To: Bob <sip:[email-masked]>
      Call-Id: [email-masked]
      History-Info:  <sip:[email-masked]>; index=1,
       <sip:[email-masked]?Reason=SIP;\
       cause=302; text="Moved Temporarily">;index=1.1,
       <sip:[email-masked]?Reason=SIP;cause=480;\
       text="Temporarily Unavailable" >;index=1.2,
       <sip:[email-masked]>;index=1.3
      CSeq: 1 INVITE
      Content-Length: 0

Note that it presents a case where one request-URI appears in more than
one History-Info value, which was a question I raised above.)

Dale

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 12 Feb 2009 11:20:58 -0600

More responses inline below [MB2].

-----Original Message-----
From: Worley, Dale (BL60:9D30) 
Sent: Wednesday, February 11, 2009 3:44 PM
To: Barnes, Mary (RICH2:AR00)
Cc: SIP
Subject: RE: [Sip] Problems with History-Info

On Wed, 2009-02-11 at 11:44 -0500, Barnes, Mary (RICH2:AR00) wrote:
> are correct that we don't identify it as a "depth-first" and perhaps 
> we can add that, although I think it's quite clear from examples and 

[MB2] With the indices, it actually doesn't matter if the entries are
added in depth first order. However, RFC 4244 does specify in section
4.3.3.1 that the entries MUST be added following any HI entry received
in the request.  Now, certainly, in the parallel forking situation, you
wouldn't know if an entry 1.2.1 was really added before an entry 1.3.1,
but that's more because the order of responses is entirely indeterminate
per core SIP when a request is forked. It might be sensible (but not
required for things to work) that the proxy that forked the requests
would keep the HI entries grouped logically. We could add a suggestion
to this effect in the -bis. [/MB2] 

[MB2] When a proxy receives a request that doesn't have an entry for the
hop that got the request to this proxy, then it is suggested to add an
entry, so if I understand you, yes, when a request reaches a proxy, the
last entry should be the same as the request URI in the request. I don't
know how that can be stated more clearly as that's a fundamental to how
HI is captured and comprises the basic definition of the
"Targeted-to-URI" field in the header per section 4.1.  It's also
described in section 4.3.1 (UAC behavior).  It may not be quite so clear
in section 4.3.3.1 (Proxy behavior) and we could be more explicit about
that when we discuss that "if the request doesn't contain a History-Info
header" to state the "hi-targeted-to-uri" is set to the URI in the
request". [/MB2]

[MB2] Per the spec the only reason to drop entries is due to privacy and
yes, you will know there's been a branch, you just may not know what the
request URI was for that branch nor what the leaves are - kindof like an
incomplete family tree.    And, section 5 (item 3) does highlight the
importance for applications to deal with these situations. So, I'm still
confused as to what text in the current specification is lacking. [/MB2]

[MB2] I can't see a source of confusion in the RFC - it's talking about
subsequent retargets - i.e., another instance of retargeting and it is
consistent with examples. How would you state it more accurately?
Sorry, I can't grok your point above, so I can't quite see a way to
qualify the text to resolve your concern. [/MB]

[MB2] I'm not clear on why you see case 1 as correct, when the index is
wrong. Yes, in the case of parallel forking that's all the info the
proxy has - i.e., HI can't be more deterministic or provide more
information than what you would get from looking at a message trace.
But, that wouldn't be the case for sequential. [/MB2]

> absolutely knows that and that's the reason why the "reason" is added 
> to the previous HI entry - i.e., the rule being that the reason is 
> associated with the "Why the request was retargeted?" from the 
> previous HI entry ([email-masked]) to the new HI entry
[email-masked]).

> in that last INVITE.  It does require that you look for the reason, 
> but you really don't need the redundant data. An old, old version of 
> this document actually did have redundant data in that the "old" and
"new"

> "new" to ensure that you have the entire chain. If you can point to 
> the specific text that seems to introduce the gap you suggest, that 
> would be helpful and we can make sure it's clear in the -bis.
> [/MB]

History-Info:

[MB2] I'm not sure of your use of the term "subset" here. If you're
suggesting that only the branches (and not the leaves for a given
branch) are required, that's not really the case UNLESS the privacy
header is being used for some of entries. You can't determine from the
HI entries whether UserC was in the Contact header for the response to
the request forwarded to UserA or UserB OR whether UserC was a 3rd
parallel forked request. The only way to know that for certain would be
to look at the message trace.  It's up to a proxy as to how it might
arbitrate the receipt of the 3xx responses - it is not REQUIRED that
there even be a Contact header in the 3xx. History-Info captures "Why"
the request to UserA and UserB was not successful and NOT why the new
request URI is chosen.    [/MB2]

      SIP/2.0  486 Busy Here

[MB2] Which request URI in the above example is contained in more than
one HI entry? There are 4 HI entries with 4 different request URIs:
[email-masked], [email-masked], [email-masked] and
[email-masked]   However, it really doesn't matter as there's nothing
that states that the same HI value can't be in multiple entries - it's
the indices that matter - per section  4.3.3.1, this would be just the
case if you are doing loose routing.  [/MB2]

Dale