Request History Capability – Requirements & Solution SIPPING WG Meeting IETF-55 Request History Capability – Requirements & Solution draft-ietf-sipping-req-history-00.txt draft-barnes-sipping-history-info-00.txt Mary Barnes (mbarnes@nortelnetworks.com)

Changes from individual –02 to WG –00 (Requirements) Added a specific Requirement to address Optionality. Removed a Security Requirement which stated that MUST be able to to determine whether a previously added Request History content has been removed, as this wouldn’t be possible given the privacy requirements and local policy implications. Removed solution oriented text. 11/20/2002 draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

Solution draft Defines History-Info Header Defines HistInfo option Captures “retarget” information. Calling party is able to be notified of “retargetting” information. Captures the new URI Addresses security and privacy aspects associated with the information. Defines HistInfo option For the UAC to indicate History-Info in responses Specified in the Supported header 11/20/2002 draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

Solution draft – History-Info – Current ABNF History-Info = ("History-Info" / "h") HCOLON HI-retargeted-from-uri HI-retargeted-to-uri *( SEMI HI-param ) HI-retargeted-from-uri = name-addr HI-retargeted-to-uri= name-addr HI-param = HI-reason / HI-reason-cause / HI-reason-text / HI-extension HI-reason = "HI-reason" EQUAL HI-reason-protocol HI-reason-protocol = "SIP" / "Q.850" / token HI-reason-cause = "cause" EQUAL 1*DIGIT HI-reason-text = "text" EQUAL quoted-string HI-extension = generic-param Proposed New ABNF History-Info = ("History-Info" / "h") HCOLON HI *(COMMA HI) HI = HI-targeted-uri *( SEMI HI-param ) HI-targeted-uri = name-addr HI-param = generic-param Nothing explicit required in ABNF for Reason header since: SIP-URI = "sip:" [ userinfo ] hostport uri-parameters [ headers ] headers = "?" header *( "&" header ) name-addr = [ display-name ] LAQUOT addr-spec RAQUOT addr-spec = SIP-URI / SIPS-URI / absoluteURI 11/20/2002 draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

Solution draft – History-Info - ABNF Issues 2. Replicates (rather than reuses) Reason Header. Proposal that Reason header can be used and included as part of the captured retargeted URI. Current ABNF results in duplication of header field for multiple entries. Should be modified to comma delimit multiple entries. 11/20/2002 draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

Solution draft – History-Info - ABNF Issues Proposal that by capturing the URI prior to retargeting (I.e. “targeted-to”) Potential Issues: Might have gaps for instances where HI isn’t being captured (due to local policy). Needs further consideration and discussion on list. 3. Do we need both Retargeted-to and Retargeted-from URIs? Retargeted-to is needed to capture information for responses (for last instance where there is no retargeting). 11/20/2002 draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

Solution draft – History-Info - ABNF Issues b. Allow duplicate counts, letting the index indicate the depth. A combination of the captured URIs and counts can be used to “recreate” forking tree at application needing that level of info Issue:Will this work with only a single URI being captured? Should we have an explicit counter? Plain counter won’t work due to forking. Options include: a. Indexing using a dot delimiter (to reflect depth of forking, etc.) Issues would include, how do you limit depth and seems complex. 11/20/2002 draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

Solution draft – History-Info – Index Option a B is serial forking first to C then to D. C is parallel forking. A  B  C  E       |         \  F       |        \ D  G History-Info: X, Y indicates a retarget record from X (old URI) to Y (new URI).  A sends INVITE targeted to B B retargets to C. History-Info: B, C, n=1 is sent in INVITE and response to A 3) C parallel forks to E and F. HI: C, E, n=1.1 sent in INVITE to E and response to B,A HI: C, F, n=1.2 sent in INVITE to F and response to B,A 4) both branches of fork to C fail. B retargets to D with the following History Info entries: HI: B, C, n=1 HI: C, E, n=1.1 HI: C, F, n=1.2 HI: C, D, n=2     11/20/2002 draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

Solution draft – History-Info – Index Option b B is serial forking first to C then to D. C is parallel forking. A  B  C  E       |         \  F       |        \ D  G History-Info: X, Y indicates a retarget record from X (old URI) to Y (new URI).  A sends INVITE targeted to B B retargets to C. History-Info: B, C, n=1 is sent in INVITE and response to A 3) C parallel forks to E and F. HI: C, E, n=2sent in INVITE to E and response to B,A HI: C, F, n=2 sent in INVITE to F and response to B,A 4) both branches of fork to C fail. B retargets to D with the following History Info entries: HI: B, C, n=1 HI: C, E, n=2 HI: C, F, n=2 HI: C, D, n=3     11/20/2002 draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

Solution draft – Issues/concerns - Forking Need to work through more scenarios. Need to add more detail/recommendations with regards to processing for specific classes of responses. It is likely that for some scenarios all the information won’t be captured, but this may not be a problem. Propose to add more detail to section 2.3.3. Have some basic scenarios using sequential forking. Assumption that it would also be controlled by local policy as to whether parallel Forking is captured. 11/20/2002 draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

Solution draft – Issues/concerns - Privacy The application wanting to make use of the information MUST describe the impact of privacy. Depends upon how the privacy is implemented (i.e. Session, Header and/or Proxy-require with “privacy” tag). Proposal assumes the use of a Privacy Service as defined in the draft-ietf-sip-privacy-general. The application wanting to make use of the information MUST describe the impact of privacy. 11/20/2002 draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

Solution draft – Issues/concerns - Privacy Propose to go with Option 2, but welcome further discussion on the list around these issues/options. Options: Just don’t capture Request URIs. Pros: Simple implementation for HI. Cons: Could potentially limit applicability/use of HI. Define basic guidelines for HI interactions with Privacy Service, that would allow some applications to make use of information in requests which have associated Privacy. 11/20/2002 draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

Solution draft – Issues/concerns - Security Primary security concern is with regards to a rogue application/proxy changing HI entries. Proposal assumes the use of a Security Service/Authenticated identities as defined in the draft-peterson-sip-identity to protect the identities captured in the HI. Concerns Would likely require entities which are capturing HI to re-sign the entirety of the HI entries to ensure that order is maintained. Is that a problem? Other Options: Open to suggestions. Proposal: Complete the security protocol details in the draft. 11/20/2002 draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

Questions for SIPPING WG on Requirements draft? Is the Requirements document ready for WGLC? If NOT, what are the issues or concerns with the requirements as specified? 11/20/2002 draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

Questions/discussion for SIPPING WG on Solution draft? Is the scope of the security solution accurate? If NOT, what are the issues or concerns? Proposal going forward: Update draft for the concerns discussed with further detail for security and privacy aspects. Complete the additional details/annotations to the flows in the Appendix. Request additional feedback on the draft on the mailing list. 11/20/2002 draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

Backup - Examples 11/20/2002 draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

Summary of proposed requirements: Record old URI in request when ‘retargetting’ (changing of Request-URI) occurs. Record new URI to maintain ‘history’ for retargetting. Inform UAC when retargetting occurs Provide reason for retargetting. Chronological ordering of the information to allow the capture of each occurrence of retargetting. Retargetting is used in context of the bis-09 term “retarget” following the rules specified in Section 16.5 of bis-09. Issue with regards to using a “Service Specific Request-URI”: Advantages: client needs no special capability extensible Disadvantages: privacy requirements cannot be met not easy to maintain redirection history Configuration complexity at client Information not visible to intermediate entities (proxies, gateways) 11/20/2002 draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

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. UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 1 2 3 4 5 6 7 8 Example is provided to show the duplicity of messaging when there isn’t sufficient knowledge to optimize a sequential attempt at reaching an end user. Certainly, we can spend a tremendous amount of time specifying scenarios to demonstrate the applicability of a generic capability, with some existing solutions (or a new specification of information already carried in SIP messaging), perhaps being applicable to that specific scenario. The goal is the recognition that information is indeed lost when retargetting occurs and proposing a general mechanism to transport this information in the SIP messages. Use of Request History optimizes sequential forking for terminations 11/20/2002 draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00

Example 2: UA 1 called UA A which had been forwarded to UA B which forwarded to a UA VM (voicemail 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. 1 (INV) UA 1 Proxy 6 (INV) UA VM Certainly, another valid scenario for the support of voicemail would be that this 'policy decision' on which mailbox to use (etc.) is made by the UA which forwarded to voicemail (UA B), or by the Proxy which performed the forwarding on behalf of B. In this case, the UA or Proxy can put all the information that the Voicemail server needs to identity the correct mailbox, etc., into the Request-URI. This fits with the SIP service paradigm where the Request-URI identifies the resource (namely, the particular mailbox/greeting etc.) that is required. However, this model places service intelligence away from the system providing the key aspect of the service (the VM server). The proposal in this draft is to rely only on generic information-providing capabilities in the UA/Proxy, allowing the Voicemail system to provide more and better voicemail-related services without relying on specific capabilities in the UA/Proxy. This would allow voicemail service providers to innovate independently of the particular UA/Proxy that their customers are using, and its capabilities. Presently, with the information loss problem, VM service providers, and any other similar service providers, are limited in the services they can provide because they do not have complete information about how the call reached them. They rely on the UA/proxy of their customers having the necessary capabilities to formulate a Request-URI identifying exactly what should happen next. Finally, there is obviously a desire to use existing voicemail platforms based on PSTN/ISDN technology which operate according to the paradigm in this example.  3 (INV) 4 (302) 5 (INV) UA A UA B Use of Request History enables the Voicemail Service. 11/20/2002 draft-ietf-sipping-request-history-00 draft-barnes-sipping-history-info-00