1 / 8

Request History Information

SIP WG Meeting IETF-59. Request History Information. draft-ietf-sip-history-info-02.txt. Mary Barnes (mary.barnes@nortelnetworks.com). Changes from -01. Miscellaneous editorial nits. Merged the SIPPING WG requirements draft into this document.

royal
Download Presentation

Request History Information

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SIP WG Meeting IETF-59 Request History Information draft-ietf-sip-history-info-02.txt Mary Barnes (mary.barnes@nortelnetworks.com)

  2. Changes from -01 • Miscellaneous editorial nits. • Merged the SIPPING WG requirements draft into this document. • Removed redirect server from ISSUER-req since the solution identified this as not being required (or desirable). • Added an explicit privacy requirement (PRIV-req-3) for the proxy's role in recognizing and maintaining privacy associated with a Request-URI being captured in History-Info due to local policy. (Note, that the text was already there, it just wasn’t highlighted as an explicit requirement). draft-ietf-sip-history-info-02

  3. Changes from -01 • Clarified the use of CRLF and spacing in the example in section 4.2. • Removed the compact form for the header since unknown headers with multiple entries would not be recognized (i.e. this may cause parsing problems). • Added a summary of Application Considerations to address concerns about the optional usage of History-Info. draft-ietf-sip-history-info-02

  4. Issue 1 – Privacy – addt’l tags • Proposal • Add an additional field to tag HI entries that are added when privacy restrictions are involved. • Indicates whether the entry is to be removed when it’s being forwarded outside that domain (per local policy). • Allows network services to make use of the information within the domain. • Need more list discussion as to whether this is a good idea. • Privacy • Previous discussion on this point resulted in keeping things simple and if there are privacy considerations indicated by the Privacy header or local policy, then History-Info is not included. • This didn’t preclude local policies that might allow the information to be added, but required it be removed when leaving that domain. • Issue: • Folks wanting to make use of History-Info indicate this isn’t sufficient. draft-ietf-sip-history-info-02

  5. A. Options for a mechanism: • Keep only the 1st and last index in a branch. • Keep only x. • Keep only to a certain depth or breadth. Issues with option A: • How is this option indicated? • When would the option be applied? • Only when you hit a certain limit or always? • Local policy? • Need more list discussion as to whether this is a good idea. Issue 2 – Limit the number of entries? • Should or can there be a limit on the number of History-info entries captured? • Issue: implementors have indicated that messages get quite large with lots of retargets. • Options: A. Define a mechanism that allows “pruning” of the entries. B. Leave it to the end applications (i.e. protocol shouldn’t define this). draft-ietf-sip-history-info-02

  6. Next Steps • Request additional feedback on the mailing list on open issues. • Feedback in the form of alternative text on any other issues identified is most constructive. • Update the flows in the appendix including additional details & annotations. • Dependency on the security solution as identified by the requirements draft: draft-barnes-sipping-sec-inserted-info-01.txt draft-ietf-sip-history-info-02

  7. Backup draft-ietf-sip-history-info-02

  8. B is serial forking first to C then to D. C is parallel forking. Solution draft – History-Info – Index Example A  B  C  E       |         \  F       |        \ D  G • A sends INVITE targeted to B. HI: B, n=1. • B retargets to C. HI: B, n=1; C, n=1.1 is sent in INVITE and response to A. • 3) C parallel forks to E and F. • HI: B, n=1; C, n=1.1; E, n=1.1.1 sent in INVITE to E and response to B,A • HI: B, n=1; C, n=1.1; F, n=1.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, n=1; C, n=1.1; E, n=1.1.1; F, n=1.1.2; D, n=1.2 draft-ietf-sip-history-info-02

More Related