[Sip] Deficiencies of History-Info

[Dale.Worley at comcast.net]

I've looking at History-Info (RFC 4244) and I think that as it is
currently defined, it has a deficiency in regard to capturing the
forking structure of a request.

Let us look at an example that parallels the first example of RFC 4244
Appendix A (with non-significant messages omitted):

   UA1      Proxy1                UA2      UA3      UA4
   |            |                  |        |        |
   |-INVITE F1->|                  |        |        |
   |            |                  |        |        |
   |            |--INVITE F2------>|        |        |
   |            |                  |        |        |
   |            |<-302 F4----------|        |        |
   |            |                  |        |        |
   |            |-------INVITE F5 --------->|        |
   |            |                  |        |        |
   |            |<-------486 F6 ------------|        |
   |            |                  |        |        |
   |            |------INVITE F8 ------------------->|
   |            |                  |        |        |
   |            |<-200 F10 --------------------------|
   |            |                  |        |        |
   |            |-- ACK F11------------------------->|
   |<--200 F12--|                  |        |        |
   |            |                  |        |        |
   |--ACK F13-->|                  |        |        |
   |            |                  |        |        |

Assuming that each agent applies History-Info, the History-Info
headers will look like this:


      F1 INVITE UA1 ->Proxy1

      History-Info: <sip:UA2 at example.com>; index=1


      F2 INVITE  Proxy1 ->UA2

      History-Info: <sip:UA2 at example.com>; index=1,
       <sip:UA2 at ims.example.com>; index=1.1


      F5 INVITE Proxy1 -> UA3

      History-Info: <sip:UA2 at example.com>; index=1,
       <sip:UA2 at ims.example.com?Reason=SIP;\
       cause=302; text="Moved Temporarily">; index=1.1,
       <sip:UA3 at example.com>;index=1.2


      F8 INVITE Proxy1 -> UA4

      History-Info: <sip:UA2 at example.com>; index=1,
       <sip:UA2 at ims.example.com?Reason=SIP;\
       cause=302; text="Moved Temporarily">;index=1.1,
       <sip:UA3 at example.com?Reason=SIP;cause=480;\
       text="Temporarily Unavailable" >;index=1.2,
       <sip:UA4 at example.com>;index=1.3


These History-Info headers correctly give the forking structure of the
INVITE.

The difficulty is that History-Info does not tell us why UA4 was
chosen as a target -- It could have been generated by Proxy1 as a
target for UA2, or it could have been a Contact in the 302 response
F4.  As one thinks about call routing, UA4 could be a consequence of
UA2 at example.com, or it could have been a consequence of
UA2 at ims.example.com which was itself a consequence of UA2 at example.com.

It seems to me that we need a further indicator when a target is added
to the target set by a received 3xx response.  Let me propose that the
indicator be an additional field parameter "redir" whose value is the
"index" value of the URI whose 3xx response added the target.

In the above example, if both UA3 and UA4 were from the 302 response,
F8 would become:

      F8 INVITE Proxy1 -> UA4

      History-Info: <sip:UA2 at example.com>; index=1,
       <sip:UA2 at ims.example.com?Reason=SIP;\
       cause=302; text="Moved Temporarily">;index=1.1;redir=1,
       <sip:UA3 at example.com?Reason=SIP;cause=480;\
       text="Temporarily Unavailable" >;index=1.2;redir=1,
       <sip:UA4 at example.com>;index=1.3

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