request history capability – requirements & solution
DESCRIPTION
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 ([email protected]). Changes from individual –02 to WG –00 (Requirements). - PowerPoint PPT PresentationTRANSCRIPT
Request History Capability – Requirements & Solution
Mary Barnes ([email protected])
SIPPING WG MeetingIETF-55
draft-ietf-sipping-req-history-00.txtdraft-barnes-sipping-history-info-00.txt
11/20/2002 draft-ietf-sipping-request-history-00draft-barnes-sipping-history-info-00
2
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-00draft-barnes-sipping-history-info-00
3
Solution draft
• Defines History-Info Header 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-00draft-barnes-sipping-history-info-00
4
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
11/20/2002 draft-ietf-sipping-request-history-00draft-barnes-sipping-history-info-00
5
Solution draft – History-Info - ABNF Issues
1. Current ABNF results in duplication of header field for multiple entries.
Should be modified to comma delimit multiple entries.
2. Replicates (rather than reuses) Reason Header.
Proposal that Reason header can be used and included as part of the captured retargeted URI.
11/20/2002 draft-ietf-sipping-request-history-00draft-barnes-sipping-history-info-00
6
Solution draft – History-Info - ABNF Issues
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).
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.
11/20/2002 draft-ietf-sipping-request-history-00draft-barnes-sipping-history-info-00
7
Solution draft – History-Info - ABNF Issues
4. 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.
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?
11/20/2002 draft-ietf-sipping-request-history-00draft-barnes-sipping-history-info-00
8
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).
1) A sends INVITE targeted to B2) B retargets to C. History-Info: B, C, n=1 is sent in INVITE and
response to A3) 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-00draft-barnes-sipping-history-info-00
9
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).
1) A sends INVITE targeted to B2) B retargets to C. History-Info: B, C, n=1 is sent in INVITE and
response to A3) 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-00draft-barnes-sipping-history-info-00
10
Solution draft – Issues/concerns - Forking
Have some basic scenarios using sequential forking.
Assumption that it would also be controlled by local policy as to whether parallel Forking is captured.
• Concerns 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.
11/20/2002 draft-ietf-sipping-request-history-00draft-barnes-sipping-history-info-00
11
Solution draft – Issues/concerns - Privacy
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.
• Issues/Concerns 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).
11/20/2002 draft-ietf-sipping-request-history-00draft-barnes-sipping-history-info-00
12
Solution draft – Issues/concerns - Privacy
Options:1. Just don’t capture
Request URIs. Pros: Simple
implementation for HI. Cons: Could
potentially limit applicability/use of HI.
2. 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.
Propose to go with Option 2, but welcome further discussion on the list around these issues/options.
11/20/2002 draft-ietf-sipping-request-history-00draft-barnes-sipping-history-info-00
13
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:1. Open to suggestions.
Proposal: Complete the security
protocol details in the draft.
11/20/2002 draft-ietf-sipping-request-history-00draft-barnes-sipping-history-info-00
14
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-00draft-barnes-sipping-history-info-00
15
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-00draft-barnes-sipping-history-info-00
16
Backup - Examples
11/20/2002 draft-ietf-sipping-request-history-00draft-barnes-sipping-history-info-00
17
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.
11/20/2002 draft-ietf-sipping-request-history-00draft-barnes-sipping-history-info-00
18
UA1 Proxy1 Proxy2
UA2 UA3 UA4 UA5
1
2 34
5
67 8
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.
Use of Request History optimizes sequential forking for terminations
11/20/2002 draft-ietf-sipping-request-history-00draft-barnes-sipping-history-info-00
19
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.
UA 1 Proxy
UA A UA B
UA VM1 (INV)
3 (INV) 4 (302) 5 (INV)
6 (INV)
Use of Request History enables the Voicemail Service.