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 PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Friday, March 21, 2008 3:44 AM
To: [email protected]
Subject: Re: [Sip] Deficiencies of History-Info

   From: "Hans Erik van Elburg" <[EMAIL PROTECTED]>

   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:[EMAIL PROTECTED]>; index=1


         F2 INVITE  Proxy1 ->UA2

         History-Info: <sip:[EMAIL PROTECTED]>; index=1,
          <sip:[EMAIL PROTECTED]>; index=1.1


         F5 INVITE Proxy1 -> UA3

         History-Info: <sip:[EMAIL PROTECTED]>; index=1,
          <sip:[EMAIL PROTECTED];\
          cause=302; text="Moved Temporarily">; index=1.1,
          <sip:[EMAIL PROTECTED]>;index=1.2


         F8 INVITE Proxy1 -> UA4

         History-Info: <sip:[EMAIL PROTECTED]>; index=1,
          <sip:[EMAIL PROTECTED];\
          cause=302; text="Moved Temporarily">;index=1.1,
          <sip:[EMAIL PROTECTED];cause=480;\
------------------------------------------------^^^
Yes, that should be "486".
          text="Temporarily Unavailable" >;index=1.2,
          <sip:[EMAIL PROTECTED]>;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 PROTECTED] for questions on current sip Use
[EMAIL PROTECTED] 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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip

Reply via email to