Request History Capability – Requirements & Solution

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.


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


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


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.


6


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.


7


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?


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


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


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

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


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.


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.


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?


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.


16

Backup - Examples


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.


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


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.

Request History Capability – Requirements & Solution

Documents

Transcript of Request History Capability – Requirements & Solution