Subject: [Sip] RE: Question on Histrory-Info: the basic rules for adding the ind ex

From: "Mary Barnes" <[email-masked]>
Date: Mon, 24 May 2004 10:17:35 -0400

The intent of capturing the URI in step 2 is to ensure that the URI is
captured prior to retargeting (i.e. the History-Info URI in the most recent
entry is that of the Request when it is forwarded). This ensures that the
retargeted-from is automatically captured when retargeting occurs.  If you
go back to past discussions, we originally were capturing 2 URIs, the
retargeted-from and retargeted-to for each instance of retargeting.
However, that resulted in duplicate information and thus was less efficient.

I think your concern arises in viewing History-Info only as a mechanism to
capture redirections, however, the intent also was that it captured the
entire History of the flow of a Request.

Regards,
Mary. 

-----Original Message-----
From: Takuya Sawada [mailto:[email-masked]] 
Sent: Monday, May 24, 2004 4:51 AM
To: Barnes, Mary [NGC:B601:EXCH]; [email-masked]
Subject: Question on Histrory-Info: the basic rules for adding the index

Hi,

In the summarized basic rules for adding the index in section 4.3.3.1 of
History-Info draft, item 2 says;

>     2. If the Request-URI indicates a resource that this proxy is not 
>     responsible for, then the lowest/last digit of the index is 
>     incremented (i.e. a new level is not created).  For example, if the 
>     index in the History-Info header of the received request was 1.2, 
>     then the index in the History-Info header field added by this proxy 
>     would be 1.3.

In RFC 3261, section 16.5, on determining request targets at SIP proxy;

>    If the domain of the Request-URI indicates a domain this element is
>    not responsible for, the Request-URI MUST be placed into the target
>    set as the only target,
<snip>
>       A proxy can only change the Request-URI of a request during
>       forwarding if it is responsible for that URI.  If the proxy is not
>       responsible for that URI, it will not recurse on 3xx or 416
>       responses as described below.

Note that Request-URI in the above sentense is after preprocessing at the
proxy. 
I think that If the Request-URI indicates a resource that the proxy is not
responsible for, the Request-URI will not change. Retargeting on receiving
3xx will not ocuur, neither. Why do you need to record the history of
Request-URI at the proxy which is not responsible for the Request-URI?

I think the basic rules item 1 is enough and simpler solution.

Then, for example, the sequence in section 4.5 can be seen as the following;

   UA1        Proxy1  Proxy2     UA2      UA3      UA4      UA5 
                
   |            |         |        |        |        |        | 
   |--INVITE -->|         |        |        |        |        | 
   |            |-INVITE->|        |        |        |        | 
                 Supported: Histinfo 
                 History-Info: <sip:Bob@P1>;index=1, 
                               <sip:Bob@P2>; index=1.1 
   |            |         |        |        |        |        | 
   |            |         |-INVITE>|        |        |        | 
                  History-Info: <sip:Bob@P1>;index=1,  
                                <sip:Bob@P2>; index=1.1, 
                                <sip:User2@UA2>; index=1.1.1 
   |            |         |        |        |        |        | 
   |            |         |-----INVITE ---->|        |        | 
                  History-Info: <sip:Bob@P1>;index=1,  
                                <sip:Bob@P2 >; index=1.1, 
                                <sip:User3@UA3>; index=1.1.2 
   |            |         |        |        |        |        | 
   |            |         |-------INVITE------------>|        |  
                  History-Info: <sip:Bob@P1>;index=1,  
                                <sip:Bob@P2 >; index=1.1, 
                                <sip:User4@UA4 >; index=1.1.3 

   /* All Responses from the INVITEs indicate non-success/non-
   availability*/   
  |            |         |        |        |        |        | 
  |            |<-480 ---|        |        |        |        | 
               History-Info: <sip:Bob@P1>;index=1,  
                  <sip:Bob@P2>; index=1.1,   
                  <sip:User2@UA2?Reason:SIP;\ 
                   cause=408;text="RequestTimeout">;index=1.1.1,

                  <sip:User3@UA3?Reason:SIP; \        
                   cause=487;text="Request Terminated">; index=1.1.2, 
                  <sip:User4@UA4?Reason:SIP;\         
                   cause=603;text="Decline">; index=1.1.3 
  |            |         |        |        |        |        | 
 /* Upon receipt of the response, P1 determines another route for the 
  INVITE, but finds that it matches some routes already attempted  
 (e.g. UA2 and UA3, thus the INVITE is only forwarded to UA5, where  
  the session is successfully established  */ 
  |            |         |        |        |        |        | 
  |            |----------------INVITE --------------------->| 
                History-Info: <sip:Bob@P1>;index=1, 
                   <sip:Bob@P2>; index=1.1,  
                   <sip:User2@UA2?Reason:SIP;cause=408;\ 
                    text="RequestTimeout">;index=1.1.1,

                   <sip:User3@UA3?Reason:SIP;cause=487;\ 
                    text="Request Terminated">; index=1.1.2, 
                   <sip:User4@UA4?Reason:SIP;cause=603;\ 
                    text="Decline">; index=1.1.3 
                  <sip:User5@UA5>;index=1.2  
  |            |         |        |        |        |        | 
  |            |<-----200 OK---------------------------------| 
  |<--200 OK---|         |        |        |        |        | 
  |            |         |        |        |        |        |  
  |--ACK --------------------------------------------------->| 

Regards,
Takuya

--------
Takuya Sawada
KDDI Corporation (KDDI)
Garden Air Tower, 3-10-10, Iidabashi, 
Chiyoda-ku, Tokyo 102-8460, Japan
Tel: +81-3-6678-2997
Fax: +81-3-6678-0286
[email-masked]