1 / 12

Request History – Solution

SIP WG Meeting IETF-58. Request History – Solution. draft-ietf-sip-history-info-01.txt. Mary Barnes (mary.barnes@nortelnetworks.com). History Info: changes from -00. Miscellaneous editorial changes (i.e. HistInfo -> Histinfo, etc.)

johntbrown
Télécharger la présentation

Request History – Solution

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-58 Request History – Solution draft-ietf-sip-history-info-01.txt Mary Barnes (mary.barnes@nortelnetworks.com)

  2. History Info: changes from -00 • Miscellaneous editorial changes (i.e. HistInfo -> Histinfo, etc.) • Removed definitions of new terms, only referencing the terms from the requirements in the context of the fundamental SIP processing implied by the terms. • Fair amount of rewriting to be more explicit about the fundamental processing associated with the header, including applicability to loose routing. • Clarified the Index and the related processing in terms of how it’s calculated and maintained.

  3. History-Info: changes from -00 • Added more detail addressing the privacy requirements in terms of impact of Privacy header and local policies, per previous email discussion on requirements. • Added a bit more detail on security. The security solution remains in a separate document and this document will need updating once that is completed. • Updated the examples (in section 2.5 and appendix). • Corrected the Reason description in section 2.1. There had been an error in the description of the processing that was a remnant of the change to include only a single URI for each History-Info header.

  4. Options: • Capture only at the point of retargeting • BUT, that leads to the loss of information that was the premise for this draft. • Proposal: • Reason is only added for History-Info entries added by the retargeting entity, thus it’s not a security issue as much as a complexity issue. History-Info – Issues • Per the current model, the Request URI is captured as the request is forwarded, thus requiring the Reason for retargetting to be added to the previous History-Info entry. • Premise for this being that it provides a “complete” history. • Issue: this appears to make the security even more complicated.

  5. History-Info – Issues • Alternatives: • Add tags to allow HI to be added when privacy restrictions are involved, but must be removed when it’s being forwarded to non-trusted domain (per local policy). • Proposal: • Keep it simple and update normative processing in section 2 (Protocol details) to reflect that information is not included when there are privacy considerations. 2. Privacy • Section 1.3 is now explicit in that HI SHOULD not be added if there is priv-value of Session or Header level privacy. Consistent with conclusions to previous email discussions on Requirements (and normative RFC 3323 text). • Due to the ability of HI to reveal general routing information that may be subject to privacy, also MAY be excluded due to Local Policy.

  6. Next Steps • Complete the additional details/annotations to the flows in the Appendix. • Bring the requirements into this document? • Request additional feedback on the mailing list. • Dependency on the security solution - this draft can’t complete without a well progressed security solution.

  7. Potential Applications of History-Info • Value proposition of History-Info in the overall SIP security scheme. • Voicemail

  8. Request History Example– Enhancing SIP security • “A” calls “B@home.com” but the call is answered by “C@bubba.com”. • With secured HI “A” can be certain that “C@bubba.com” is a valid destination for the user associated with “B” whose only address A knows is “B@home.com”. 200 HI: <B,C> 7 200 HI:<B,C> Proxy1 Proxy2 8 200 HI: <B,C> 6 INVITE R-Uri: <C> HI: <B,C> A C@bubba.com INVITE R-Uri: <B> To: <B> From: <A> HI: <B> 1 4 INVITE R-Uri: <C> To: <B> From: <A> HI: <B,C> 5 3 302 <C> INVITE R-Uri: <B> HI: <B> 2 B@home.com

  9. History-Info – Applicability to Voicemail • Alternatives for Voicemail solutions: • Service specific URI mechanism based on RFC 3087 • Service specific URI mechanism discussed in draft-jennings-sip-voicemail-uri-00. • Requires the proxy to understand the valid targets for the UM system, thus distributing the service logic between the proxy and the UM system. • Makes use of netann service specific URIs. • Proposes the addition of a Reason and Target parms to the Request URI.

  10. History-Info – Applicability to Voicemail • History-Info header based solution: • Allows the proxy to pass call related history information that allows an intelligent UM system to make decisions about handling of the call. Proxy merely makes routing decision. • Makes use of the Reason captured with the Request URIs in the History-Info • Keeps the voicemail specific processing in the UM server.

  11. Backup

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

More Related