Subject: RE: [Sipping] Generic Request History capability

From: "Ben Wang"<[email-masked]>
Date: Fri, 11 Jan 2002 15:16:40 -0600

-----Original Message-----
From: David R. Oran [mailto:[email-masked]]
Sent: Monday, January 07, 2002 12:04 PM
To: 'Drage, Keith (Keith)'; [email-masked]; Watson, Mark
[MDN05:EP10:EXCH]
Subject: RE: [Sipping] Generic Request History capability

> -----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.

[Ben] I think it might be useful to know who are the anticipated users of
this "call history" info. Some use cases will be helpful in order to work
out the detail such as what triggers "call history" recording and what
information elements need to be included in a record. To a callee/callee's
delegate, "personal info" such as who is the original caller, why and from
where (last hop) the call is forwarded/directed to here is important; While
for intermediate network entities the call-progress-process is more
important, then information such as your "contact-tried", chronological
ordering (for loop detection) become relevant. If we also intend to notify
the orginal caller about this "call history", then privacy control becomes
inevitable.

> 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:
> 
> 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).
> 
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.

> 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).
>
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.

[Ben] I guess there are at least two scenarios for a call
redirected/forwarded "from one user to another"
1) night service
2) a secretory answering phone for her/his boss (through 3rd party
registration)

> 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 
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.

[Ben] This is a scope question. Personally I think we should make it broad
enough in order to support future advanced/personalized services (such as
presence/availability-enabled services)
 
> 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.
>
Modulo privacy policy, I agree with this, and would contend that the
contacts-visited scheme accommodates both quite handily.

[Ben] Privacy control is important but a difficult issue, especially if a
callee/redirecting entity want to have different level of privacy control
depending who is calling (assuming privacy control is primarily for backward
notification)

Ben

Dave.
 
> 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
> 

_______________________________________________
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: "Eric Burger" <[email-masked]>
Date: Tue, 22 Jan 2002 08:37:43 -0500

Comments in-line marked by [EWB].  Heavily snipped from the message's
original 5 pages...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Ben
Wang
Sent: Friday, January 11, 2002 4:17 PM
-----Original Message-----
From: David R. Oran [mailto:[email-masked]]
Sent: Monday, January 07, 2002 12:04 PM
> Sent: Thursday, January 03, 2002 6:01 AM
[snip]

[EWB] This is very problematic.  *How* does an intermediate node know what
is or is not important down-stream?  Unless pruning proxies cooperate with
down-stream proxies, this is not solvable.  And, that's not solvable!  Why?
Because a proxy up-stream of a proxy that wants "history" cannot know
a'priori that (a) the down-stream proxy exists and (b) what its needs are.
If you are in a single administrative domain, maybe.  However, that becomes
an issue of local policy, which would be outside the protocol.

[snip]
[From Dave:]

[EWB] Both of these examples explain Dave's point:
1) the night service provides call answering FOR the "main number"
2) the secretary provides call answering FOR the boss

Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping

---

From: "David R. Oran" <[email-masked]>
Date: Sun, 27 Jan 2002 12:28:03 -0500

> From: Eric Burger [mailto:[email-masked]] 
> Sent: Tuesday, January 22, 2002 8:38 AM
> To: Ben Wang; David R. Oran
> Cc: [email-masked]
> Comments in-line marked by [EWB].  Heavily snipped from the 
> message's original 5 pages...
> 
> [snip]
> > 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.
> 
> [EWB] This is very problematic.  *How* does an intermediate 
Well, anything involving policy is problematic :-)
The point is that correctness ought not to depend on this kind of
feature (nor on the alternative formulations like call redirection)
because such a header could be undetectably removed anyway.

> node know what is or is not important down-stream?  Unless 
If it's a forking proxy serving the callee in the To: field, then at
least in principle it knows the policy of the callee and if it forked to
places it knows the upstream doesn't want/need/should know about it
seems perfectly appropriate to eithernot putthe information in, or
remove information put in by a downstream proxy.

> pruning proxies cooperate with down-stream proxies, this is 
> not solvable.  And, that's not solvable!  Why? Because a 
> proxy up-stream of a proxy that wants "history" cannot know 
> a'priori that (a) the down-stream proxy exists 
It doesn't need to know this a priori, as far as I can tell. It only
needs to observe what comes back in responses, and when forwarding an
invite, whether the next hop (be it proxy or UA) should get the info
from a policy standpoint.

and (b) what 
> its needs are. If you are in a single administrative domain, 
> maybe.  However, that becomes an issue of local policy, which 
> would be outside the protocol.
>
All I'm proposing in the protocol is a way to include the history
information. The policy about what/which/whether to include is of course
outside the protocol - that's what policy is all about.
 
> [snip]
> [From Dave:]
> 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.
> 

Well said :-)