Subject: RE: [Sipping] Generic Request History capability

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 3 Jan 2002 11:00:38 -0000

I think the discussion at IETF 52 was heading in the wrong direction, at
least as far as the Call Redirection type services is concerned.

The purpose of the information given to the forwarded-to user is NOT to give
him the history of the call. It is to give that user enough information to
determine why he has the call, and therefore allow that user to respond to
that call with an appropriate greeting or whatever.

When defining the requirements for this, obviously the type of forwarding
that might have occurred in the past may be relevant, and some of the
address(es) that were forwarded from may be relevant, but not the entire
history of the call.

The information supplied should assist the user in discovering which of the
following forwardings occurred:

i)	the call was forwarded from one address where the user normally
receives calls, to another address where the same user is temporarily
receiving calls (other users may also be receiving calls at this address).

ii)	the call was forwarded from one user to another user who is
answering calls on behalf of the first user (that second user may also be
receiving calls of his own, and on behalf of other users).

Note that multiple forwardings may occur of both types.

In order to assist this, the important information is the address to which
the calling user originally requested the call, and the reason the call was
last forwarded (unconditional, busy, no reply, deflection) and where from.
Other information is redundant to the user. Large numbers of intermediate
forwarding addresses are irrelevant to the end user in order to support a
forwarding service.

Note that the above is all that is reflected in the ISDN service definition.
Note that in the ISDN it is not normally possible to identify directly which
type of forwarding is meant (different terminal or different user, or both),
in SIP this could possibly be programmed in at time of setting up the
forwarding, and therefore just an indication of this could be sufficient.

While the requirements you have generated for a call history capability may
support this, they are essentially duplicating the ISUP solution to the ISDN
requirements, not specifying the requirements themselves.

The discussion above only reflects the information sent to the forwarded-to
user. The calling user also expects to receive information during the
progress of various forwardings, and the forwarding user should also receive
information about forwarded calls.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

> ----------
> From: 	Mark Watson[SMTP:[email-masked]]
> Sent: 	20 December 2001 21:09
> To: 	[email-masked]
> Subject: 	[Sipping] Generic Request History capability
> 
> 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
> 

_______________________________________________
Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "David R. Oran" <[email-masked]>
Date: Mon, 7 Jan 2002 13:04:11 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Drage, Keith (Keith)
> Sent: Thursday, January 03, 2002 6:01 AM
> To: [email-masked]; 'Mark Watson'
> Subject: RE: [Sipping] Generic Request History capability
> 
> 
> I think the discussion at IETF 52 was heading in the wrong 
> direction, at least as far as the Call Redirection type 
> services is concerned.
> 
> The purpose of the information given to the forwarded-to user 
> is NOT to give him the history of the call. It is to give 
> that user enough information to determine why he has the 
> call, and therefore allow that user to respond to that call 
> with an appropriate greeting or whatever.
>
If that's what you want, then that's what the subject header is for. 
The history is needed to figure out, from the CONTEXT of what's happened
so far, and which contacts have been tried, what might be the
appropriate handling of the call.

> When defining the requirements for this, obviously the type 
> of forwarding that might have occurred in the past may be 
> relevant, and some of the
> address(es) that were forwarded from may be relevant, but not 
> the entire history of the call.
>
The information may be pruned at any point, for either irrelevancy or
privacy reasons.
 
> The information supplied should assist the user in 
> discovering which of the following forwardings occurred:
> 
> receives calls, to another address where the same user is 
> temporarily receiving calls (other users may also be 
> receiving calls at this address).
> 
Yes, that can be done with the visited scheme that Henning and I
proposed a while back. The contacts-visited header would have the tried
contact address and the response code (302) saying moved temporarily so
the recipient of this on the subsequent request would know what's going
on.

> answering calls on behalf of the first user (that second user 
> may also be receiving calls of his own, and on behalf of other users).
>
I don't know what this means in the SIP context. Are you talking about
changing the To: header, or just the request URI? I find the notion of
forwarding a call "from one user to another" to be quite slippery,
especially if done by proxies. I instead think what is happening is that
a call for one user is being delivered to one of the contact addresses
for another user, but the call is still "for" the first user. Again, the
visited scheme deals with this quite handily.

> In order to assist this, the important information is the 
> address to which the calling user originally requested the 
DO you mean ADDRESS here, or the URL in the To: field? I assume you mean
the latter, because I don't think of the former as call forwarding at
all.

> call, and the reason the call was last forwarded 
> (unconditional, busy, no reply, deflection) and where from. 
> Other information is redundant to the user. Large numbers of 
> intermediate forwarding addresses are irrelevant to the end 
> user in order to support a forwarding service.
>
I think I disagree with this. The intermediaries MAY be irrelevant; then
again the may not. This should be left to application policy and not
restricted b the protocol.

> Note that the above is all that is reflected in the ISDN 
> service definition. Note that in the ISDN it is not normally 
> possible to identify directly which type of forwarding is 
> meant (different terminal or different user, or both), in SIP 
> this could possibly be programmed in at time of setting up 
> the forwarding, and therefore just an indication of this 
> could be sufficient.
>
Yes, and I think that thinking I terms of the ISDN service definition is
a big part of the problem. It assumes the endpoints are stupid, and that
the call handling is not transactional.

> While the requirements you have generated for a call history 
> capability may support this, they are essentially duplicating 
> the ISUP solution to the ISDN requirements, not specifying 
> the requirements themselves.
>
We're talking about general purpose protocol machinery that can be used
for a variety of requirements. I think the requirements as much broader
than duplicating the ISDN service definition.
 
> The discussion above only reflects the information sent to 
> the forwarded-to user. The calling user also expects to 
> receive information during the progress of various 
> forwardings, and the forwarding user should also receive 
Modulo privacy policy, I agree with this, and would contend that the
contacts-visited scheme accommodates both quite handily.

Dave.
 
> > At IETF 52, the conclusion from the Redirection discussion 
> was that a 
> > more generic mechanism for passing around the 'Call 
> History' should be 
> > considered.
> >  
> > 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.
> >   
> > 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].
> >  
> > 6) Request History information may be passed from the generating 
> > entity backwards towards the UAC
> >  
> > 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:
> > (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
> > 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>