Re: [Sip] Deficiencies of History-Info

[Dale.Worley at comcast.net]

   From: "Hans Erik van Elburg" <hanserik.van.elburg at ericsson.com>

   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.

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.

   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.

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->|                  |        |        |
      |            |                  |        |        |
      |            |--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;\
------------------------------------------------^^^
Yes, that should be "486".
	  text="Temporarily Unavailable" >;index=1.2,
	  <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