Generic Request History Capability - Requirements

1
Generic Request History Capability - Requirements
SIP/SIPPING WG Interim Meeting May 6-7, 2002
draft-watson-sipping-req-history-01
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
Changes in -01

• Examples (next charts) added to the appendix
• Updated requirements
• Req 4.2 clarified (URI from which request was
  retargetted)
• Req 4.3 (Identity which modified) and Req 9
  (completeness) removed.
• Added a section that highlights additional
  considerations introduced by specific
  requirements
• Clarified that the optionality of Request History
  would likely be determined by local policy
• Recommendation that internal retargetting also
  be captured.
• Proposal to use the Reason header to capture the
  Reason for retargetting.

3

• 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

4

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

5

• 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
6
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.

7
Questions for SIP/SIPPING Interim?

• Is the general problem (information loss) worth
  solving ? Hum vote IETF-53 indicated yes
• Are the requirements in draft-watson-sipping-req-h
  istory sufficient to solve this problem ?

8
If the answers are Yes

• Propose the following
• Evaluation of existing SIP headers that might be
  suitable analyzed against the requirements
• Remote Party ID
• Cookie
• State
• If these are deemed unsuitable
• Propose the definition of a new SIP header.

9
Existing SIP Headers

• Remote-Party-Id (RPI)
• Advantages
• Can leverage the existing privacy framework
  (draft-ietf-sip-privacy-04.txt)
• Stack multiple headers for multiple redirections
• Extensible
• Disadvantages
• Recent updates to the existing privacy framework
  restrict the applicability of this header so its
  not really a generic header.
• Cookie
• Advantages
• Flexible and extensible
• Disadvantages
• Generally used for keeping persistent state
  information across sessions. May not be a match
  here.
• State
• Advantages
• Existing SIP header used for carrying state
  information between the Proxies and the endpoints
• Disadvantages
• Needs behavior change in Proxies and UAs in
  treating this header.

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

• Request-History Header
• Advantages
• Captures retarget information.
• Calling party is able to be notified of
  retargetting information.
• Captures the new URI