Generic Request History Capability - Requirements

1
Generic Request History Capability - Requirements
SIPPING WG Meeting IETF-54
draft-watson-sipping-req-history-02
Mary Barnes (mbarnes_at_nortelnetworks.com) Mark
Watson (mwatson_at_nortelnetworks.com) Cullen
Jennings (fluffy_at_cisco.com) Jon Peterson
(jon.peterson_at_neustar.biz)
2

• 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 ltDgt To ltBgt From ltAgt
5
1
INVITE R-Uri ltBgt To ltBgt From ltAgt
A
Proxy1
Proxy2
8
INVITE R-Uri ltEgt To ltBgt From ltAgt
4
INVITE R-Uri ltBgt To ltBgt From ltAgt
2
302 ltDgt
INVITE R-Uri ltDgt To ltBgt From ltAgt
6
3
7
Busy Here
INVITE R-Uri ltCgt To ltBgt From ltAgt
B
C
D
E

• Proxy2 does not know that ltCgt was tried
• E does not know that ltCgt or ltDgt was tried
• A does not know that ltCgt or ltDgt were tried
• A does not know ltBgt is unavailable until ltEgt
  alerting

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

4
Changes in -02

• Defined specific security requirements
• SEC-req-1 The entity receiving the Request
  History must be able to determine whether any of
  the previously added Request History content has
  been altered.
• SEC-req-2 The ordering of the Request History
  information must be preserved at each instance of
  retargeting.
• SEC-req-3 The entity receiving the Request
  History must be able to determine whether a
  previously added Request History content has been
  removed.
• SEC-req-4 The entity receiving the information
  conveyed by the Request History must be able to
  authenticate the source of the information. .
• SEC-req-5 To ensure the overall integrity of the
  chain of Request History information, the
  transport must be secure.

5
Changes in -02

• Defined specific requirements related to Privacy
  
• PRIV-req-1 The entity retargeting the Request
  must ensure that it maintains the privacy
  associated with the original Request URI which is
  retargeted.
• PRIV-req-2 The entity receiving the Request
  History must maintain the privacy associated with
  the information.

6
Changes in -02

• Further clarified the optionality of Request
  History, by providing examples of the impact
  without Request History.
• Examples (next charts) expanded to further
  clarify the optionality aspect to the appendix

7

• 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
8

• 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)
6 (INV)
UA 1
Proxy
UA VM
3 (INV)
4 (302)
5 (INV)
UA A
UA B
Use of Request History enables the Voicemail
Service.
9
Changes in -02

• Removed references (section 6) to existing
  headers (discussed at SIP/SIPPING Interim) as
  they dont meet the requirements.

10
Previous New SIP Headers Proposed

• Diversion Header
• Advantages
• Captures retarget information.
• Disadvantages
• Calling party is not identified as being able to
  be notified of retargetting information.
• Doesnt capture the new URI (which allows the
  entire history to be captured without depending
  upon information derived from other instances of
  Contacts-Tried)
• Contacts-Tried Header
• Advantages
• Contains a list of contacts tried, reason and
  status.
• Disadvantages
• Doesnt capture the new URI (which allows the
  entire history to be captured without depending
  upon information derived from other instances of
  Contacts-Tried)
• Calling party is not identified as being able to
  be notified of Contacts-Tried information.

11
Propose the definition of a new header

• History-Information Header
• Advantages
• 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.

12
Questions for SIPPING WG?

• Are the requirements in draft-watson-sipping-req-h
  istory sufficient to solve this problem,
  including the security requirements ?
• Should this be a SIPPING WG document?

13
If the answers are Yes

• Propose the following
• Further scenario analysis to better understand
  the necessary applicability guidelines wrt
  optionality (and Privacy) aspects and the
  potential impact on functionality.
• Propose to include this in an initial solution
  draft (can be removed later).
• Begin work on complete solution, including
  security.