Subject: [Sip] Deficiencies of History-Info

From: [email-masked]
Date: Wed, 19 Mar 2008 16:33:26 -0500

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:[email-masked]>; index=1

      F2 INVITE  Proxy1 ->UA2

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

      F5 INVITE Proxy1 -> UA3

      History-Info: <sip:[email-masked]>; index=1,
       <sip:[email-masked]?Reason=SIP;\
       cause=302; text="Moved Temporarily">; index=1.1,
       <sip:[email-masked]>;index=1.2

      F8 INVITE Proxy1 -> UA4

      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

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
[email-masked], or it could have been a consequence of
[email-masked] which was itself a consequence of [email-masked].

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:[email-masked]>; index=1,
       <sip:[email-masked]?Reason=SIP;\
       cause=302; text="Moved Temporarily">;index=1.1;redir=1,
       <sip:[email-masked]?Reason=SIP;cause=480;\
       text="Temporarily Unavailable" >;index=1.2;redir=1,
       <sip:[email-masked]>;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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Hans Erik van Elburg" <[email-masked]>
Date: Thu, 20 Mar 2008 15:42:08 +0100

Yes.

Isn't the more fundamental design problem that causes this that the
Reason is captured on the hi-targeted-to-uri that has been retargeted
instead of being associated with the new target signifying how it came
into being.

Not sure if adding additional indexes makes things clearer.

BTW: If  UA4 is from 302, then why does UA3 line on F8 contain reason
480? I would expect it to have no attached reason.

/Hans Erik

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, March 19, 2008 10:33 PM
To: [email-masked]
Subject: [Sip] Deficiencies of History-Info

   UA1      Proxy1                UA2      UA3      UA4
   |            |                  |        |        |
   |-INVITE F1->|                  |        |        |
   |            |                  |        |        |

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

      F1 INVITE UA1 ->Proxy1

      F2 INVITE  Proxy1 ->UA2

      F5 INVITE Proxy1 -> UA3

      F8 INVITE Proxy1 -> UA4

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
[email-masked], or it could have been a consequence of
[email-masked] which was itself a consequence of [email-masked].

      F8 INVITE Proxy1 -> UA4

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
_______________________________________________
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: [email-masked]
Date: Thu, 20 Mar 2008 21:43:33 -0500

From: "Hans Erik van Elburg" <[email-masked]>

The difficulty is that you want to associate the Reason (302), the URI
that generated that reason, and the URIs that came from the 302.  RFC
4244 consistently applies the Reason to the URI that generated that
response, which seems cleanest (IMHO), in that all Reasons are
responses to some URI.

I made a mistake transcribing and modifying the example.  In the
INVITE to UA4, the cause code for UA3 should be 486.  The reason that
UA3 has a reason is that an INVITE to UA4 was sent "serially", after
the INVITE to UA3 failed.  I didn't mention that.

      UA1      Proxy1                UA2      UA3      UA4
      |            |                  |        |        |
      |-INVITE F1->|                  |        |        |
      |            |                  |        |        |

	 F1 INVITE UA1 ->Proxy1

	 F2 INVITE  Proxy1 ->UA2

	 F5 INVITE Proxy1 -> UA3

	 F8 INVITE Proxy1 -> UA4

	 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;\
------------------------------------------------^^^
Yes, that should be "486".
	  text="Temporarily Unavailable" >;index=1.2,
	  <sip:[email-masked]>;index=1.3

Dale

---

From: "Hans Erik van Elburg" <[email-masked]>
Date: Fri, 21 Mar 2008 13:54:45 +0100

I do not agree that it is cleaner. It is like attaching the reason for
an action to the action that preceded it. That sounds like asking for
problems sooner or later. The problem that you found is just a symptom
of that.

/Hans Erik

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, March 21, 2008 3:44 AM
To: [email-masked]
Subject: Re: [Sip] Deficiencies of History-Info

   Isn't the more fundamental design problem that causes this that the
   Reason is captured on the hi-targeted-to-uri that has been retargeted
   instead of being associated with the new target signifying how it
came
   into being.

The difficulty is that you want to associate the Reason (302), the URI
that generated that reason, and the URIs that came from the 302.  RFC
4244 consistently applies the Reason to the URI that generated that
response, which seems cleanest (IMHO), in that all Reasons are responses
to some URI.

I made a mistake transcribing and modifying the example.  In the INVITE
to UA4, the cause code for UA3 should be 486.  The reason that
UA3 has a reason is that an INVITE to UA4 was sent "serially", after the
INVITE to UA3 failed.  I didn't mention that.

      UA1      Proxy1                UA2      UA3      UA4
      |            |                  |        |        |
      |-INVITE F1->|                  |        |        |
      |            |                  |        |        |

headers
   will look like this:

	 F1 INVITE UA1 ->Proxy1

	 F2 INVITE  Proxy1 ->UA2

	 F5 INVITE Proxy1 -> UA3

	 F8 INVITE Proxy1 -> UA4

Dale