Subject: RE: [Sipping] Generic Request History capability

From: "Mark Watson" <[email-masked]>
Date: Thu, 3 Jan 2002 11:56:47 -0000

Keith,

The conclusion at IETF-52 was that people wanted a more generic history
'capability', not requirements for a 'forwarding' or 'redirection' service.
This is why I tried to come up with a history capability, and yes, it is a
protocol capability, not a service. (Personally, I think that Call
Redirection of the kind you describe is a perfectly acceptable 'service
capability' and does not in itself have to constitute a specific service,
but this was not the view at IETF52 - if the view on the list is different,
then let's discuss).

I agree that complete call history is not required in all cases - indeed
rarely required - and so I had envisaged this as primarily a 'best effort'
capability. Nodes which supported the capability would add the information,
but there would be no guarantee that the information was complete.

i.e.
   Call History received => call has been forwarded/redirected/'indirected'
(please can we
                                 just choose a term ?? they are all as good
as each other!)
   No call history received => call may or may not have been forwarded etc.

In any case, most applications of this will be at the terminating end - the
originating end will likely have no clue whether the information is needed
or not.

Nevertheless, I did add requirement 12 which was for the case that the UAC
knows that complete information is required and would prefer to have no
session at all unless this information is available.

...Mark

> -----Original Message-----
> From: Drage, Keith (Keith) [mailto:[email-masked]]
> Sent: 03 January 2002 11:01
> To: [email-masked]; Watson, Mark [MDN05:EP10:EXCH]
> 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.
> 
> 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
> > 
>

---

From: "Sanjoy Sen" <[email-masked]>
Date: Thu, 3 Jan 2002 15:06:46 -0600

I agree with Keith that complete call history may not be needed for all
services, and perhaps this should somehow be reflected in the requirement #
12. Also, 
Requirement # 2 - we need to think what else can trigger generation of
request history (e.g., sometimes generation of a new dialog can be the
trigger - with REFER?).
Reqmt # 5 does not specify REFER as a message carrying request history, but
reqmt # 9 makes a specific case with REFER. I think reqmt 9 should be made a
more generic requirement: In case a call spawns multiple dialogs, it may be
required to transfer the request history information to the entities
involved in the new dialogs.
 
Sanjoy

-----Original Message-----
From: Watson, Mark [MDN05:EP10:EXCH] 
Sent: Thursday, January 03, 2002 5:57 AM
To: 'Drage, Keith (Keith)'; [email-masked]
Subject: RE: [Sipping] Generic Request History capability

Keith, 

i.e. 

...Mark 

> From: Drage, Keith (Keith) [ mailto:[email-masked]
<mailto:[email-masked]> ]

---

From: Michael Hammer <[email-masked]>
Date: Thu, 03 Jan 2002 16:40:17 -0500

Sorry, I was not at SLC.  Is the intent to carry information such as the 
Record-Route  from one transaction attempt to set up a dialog over into 
subsequent transactions and dialog attempts that eventually get the session 
setup?

Mike

At 03:06 PM 1/3/2002 -0600, Sanjoy Sen wrote:
>services, and perhaps this should somehow be reflected in the requirement 
># 12. Also,
>Reqmt # 5 does not specify REFER as a message carrying request history, 
>but reqmt # 9 makes a specific case with REFER. I think reqmt 9 should be 
>made a more generic requirement: In case a call spawns multiple dialogs, 
>it may be required to transfer the request history information to the 
>entities involved in the new dialogs.
>
>Sanjoy
>
>>'capability', not requirements for a 'forwarding' or 'redirection' 
>>service. This is why I tried to come up with a history capability, and 
>>yes, it is a protocol capability, not a service. (Personally, I think 
>>that Call Redirection of the kind you describe is a perfectly acceptable 
>>'service capability' and does not in itself have to constitute a specific 
>>service, but this was not the view at IETF52 - if the view on the list is 
>>different, then let's discuss).
>>
>>rarely required - and so I had envisaged this as primarily a 'best 
>>effort' capability. Nodes which supported the capability would add the 
>>information, but there would be no guarantee that the information was complete.
>>
>>i.e.
>>    Call History received => call has been 
>> forwarded/redirected/'indirected' (please can we
>>                                  just choose a term ?? they are all as 
>> good as each other!)
>>In any case, most applications of this will be at the terminating end - 
>>the originating end will likely have no clue whether the information is 
>>needed or not.
>>
>>Nevertheless, I did add requirement 12 which was for the case that the 
>>UAC knows that complete information is required and would prefer to have 
>>no session at all unless this information is available.
>>
>>...Mark
>>
>> > From: Drage, Keith (Keith) 
>> [<mailto:[email-masked]>mailto:[email-masked]]

_______________________________________________
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: "Sanjoy Sen" <[email-masked]>
Date: Fri, 4 Jan 2002 14:32:07 -0600

The information set is broader than just record-route but the primary
intent, I think, is what you've described. Again, I was also not present at
SLC, so I would let Mark Watson or somebody else comment on this.  Thanks.

> From: Michael Hammer [mailto:[email-masked]]
> Sent: Thursday, January 03, 2002 3:40 PM
> To: Sen, Sanjoy [NGB:B692:EXCH]
> Cc: Watson, Mark [MDN05:EP10:EXCH]; 'Drage, Keith (Keith)';
> [email-masked]