Generic Request History Capability - Requirements Mary Barnes Mark Watson Cullen Jennings Jon Peterson Chris Hogg IETF-53 draft-watson-sipping-req-history-00

3/15/2002 draft-watson-sipping-request-history-00 2 AProxy1Proxy2 BCDE General problem: 1) Information is lost as the INVITE is retargetted 2) Caller is unaware of where the call is going 3) Callee is unaware of where call has been INVITE R-Uri: To: From: INVITE R-Uri: To: From: 1 2 INVITE R-Uri: To: From: 3 INVITE R-Uri: To: From: 5 INVITE R-Uri: To: From: 6 INVITE R-Uri: To: From: Proxy2 does not know that was tried E does not know that or was tried A does not know that or were tried A does not know is unavailable until alerting Busy Here 8

3/15/2002 draft-watson-sipping-request-history-00 3 UA1Proxy1Proxy2 UA2UA3UA4UA Example 1: UA 1 sends a call to proxy 1 which sequentially tries several places before retargetting the call to a second proxy which unfortunately tries many of the same places.

3/15/2002 draft-watson-sipping-request-history-00 4 Example 2: UA 1 called UA A which had been forwarded to UA B which forwarded to a UA VM (voic server) which needs information (e.g. reason the call was retargetted) to make a policy decision about what mailbox to use, which greeting to play etc. UA 1Proxy UA AUA B UA VM 1 (INV) 3 (INV) 4 (302) 5 (INV) 6 (INV)

3/15/2002 draft-watson-sipping-request-history-00 5 Summary of proposed requirements: Record old URI in request when ‘retargetting’ (changing of Request-URI) occurs Inform UAC when retargetting occurs Provide reason for retargetting Possible to detect completeness of information (i.e. operates in ‘best-effort’ or ‘complete’ modes)

3/15/2002 draft-watson-sipping-request-history-00 6 Issues discussed on the mailing list: IssueDiscussion Predicated on a specific solution – Draft presupposes no specific solution – Draft suggests an analysis of various solutions Trying to solve a narrow problem domain – Objective is to get recognition of the usefulness of a generic capability applicable to a variety of problems. –Certainly, a variety of solutions could be applied to each of the specific example Scenarios. Attempting to replicate legacy services – Certainly, the solution should provide the capability for provision of equivalent services that are deemed desireable –BUT solution should be a generic SIP capability

3/15/2002 draft-watson-sipping-request-history-00 7 Questions for IETF-53 Is the general problem (information loss) worth solving ? Are the requirements in draft-watson- sipping-req-history sufficient to solve this problem ? Would example scenarios be a useful appendix to the draft? Should we begin evaluation of solutions ?