Subject: [Sipping] Generic Request History capability

From: "Mark Watson" <[email-masked]>
Date: Thu, 20 Dec 2001 21:09:58 -0000

All,

At IETF 52, the conclusion from the Redirection discussion was that a more generic mechanism for passing around the 'Call History' should be considered.

Below is a straw-man proposal for the requirements for such a mechanism.

True to the new SIP change control process, discussion at this stage should focus purely on whether such a mechanism is required at all, and the detailed requirements - i.e. we don't need to discuss headers, coding etc. now.
 
Requirements proposal: Request History

1) The Request History capability will provide a capability to inform proxies and UAs involved in processing a request about the history/progress of that request
 
2) Request History information shall be generated when the Request-URI is modified or when a new Request-URI supplied for the request [See note 1 below].
 
3) Request History information can be generated by a UA (?), proxy or redirect server.
 
4) The Request History information, for each occurence of redirection, shall include:
4.1) The new URI to which the request has been directed
4.2) The identity of the entity which modified the Request-URI, or the identity of the user on whose behalf this modification was carried out (e.g. by a CPL script), or both (?)
4.3) The reason for the Request-URI modification {See note 2 below]
4.4) chronological ordering of the Request History information

5) Request History is applicable to requests not sent within an established session (i.e. INVITE, REGISTER, MESSAGE and OPTIONS (?)).

6) Request History information may be passed from the generating entity backwards towards the UAC

7) Request History information may also be included by the generating entity in the request, if it is forwarded onwards

8) An entity (UA or proxy) acting on a response from a redirect server shall include the Request History information in the new request.

9) An entity (UA or proxy) acting on a REFER request shall include the Request History received in the REFER in the new Request.

10) In an environment with trust relationships between SIP entities, it shall be possible to pass Request History information which is subject to privacy constraints (i.e. cannot be passed to untrusted entities)

11) In an environment with trust relationships between SIP entities, it shall be possible to mark Request History information as verified by a trusted proxy

12) It shall be possible for a UA to require that the request be failed if complete Request History information cannot be supplied (How do you know if it is not supplied?)

Note 1: A key issue is what consititutes 'modification' of the Request-URI in this context. We have two options for this problem:
(a) agree a clear definition of what type of modifications to the Request-URI should trigger Request History and which do not
(b) specify that this is a matter for the application which is re-writing the Request-URI

Note 2: The reason for the modification of the Request-URI is only known to the application peforming the modification. However, it does make sense to define a set of reasons which will be commonly required, for example the response codes which can be returned by a Redirect Server.

Comments ?

Regards,

Mark Watson
Nortel Networks