History-Info header and Support of target-uri Solution Requirements Mary Barnes Francois Audet SIPCORE WG IETF-75 draft-barnes-sipcore-4244bis-02.txt draft-rosenberg-sipcore-target-uri-delivery-01.txt Shida Schubert Christer Holmberg Hans-Erik Van Elburg

2 Since IETF 74 draft-barnes-sip-4244bis-00  draft-barnes-sipcore-rfc4244bis-00  draft-barnes-sipcore-rfc4244bis-01  draft-barnes-sipcore-rfc4244bis-02 (including authors from target-uri-delivery) draft-rosenberg-sip-target-uri-delivery-01  draft-rosenberg-sipcore-target-uri-delivery-00  (stopped updating, update depends on outcome meeting) Focus has been entirely on rfc4244bis –Main example call flows illustrates a target-uri call flow

3 What we want to achieve today Agree on the few remaining issues from mailing list Move 4244bis to Working Group Document What do we do with target-uri draft? 1.Keep separate document for use case, referring back into 4244bis (Shida is working on this) 2.Roll use cases into 4244bis ← RECOMMENDED

4 Scope of 4244bis Enable target-URI use case Fix 4244bis –Allowing distinguishing retargeting from routing (other SDOs need this, and most use case scenarios need this also) –Allow interoperability Allow for backward compatibility

5 What’s wrong with RFC 4244? In order to make it work in real life, you have to make “assumptions” on the hi-entries. Service logic, PSTN mapping, etc. First entry must be “Original Called Number” Last entry is Contact Second to last is “Called Number” Third to last is “Redirecting Number” You can’t have “redundant” entries (by proxies) in between 4244 is overly permissive This causes complexity for implementers Or just remove unwanted entries, based on what a specific proxy believe is useful

6 What’s wrong with 4244? Error in ABNF All the examples are using strict routing instead of loose routing resulting in complexity and pointlessness Repetitive text, background information that is not useful, etc. There is a gratuitous mandate to use TLS on all hops, or else remove entries Terminology issue from RFC 3261 (re-route, re-target, forward) Absorbing the changes of draft-rosenberg-sip-target-uri- delivery

7 What we did to document Added new “tags” for individual entries, useful both for target-URI and redirection use cases Replace examples with meaningful ones Significant trimming of repetitive/non-useful material Significant tightening of procedures (a lot less options which made interoperability impossible) Re-ordering of text to match current best practices Privacy is now achieved by anonymizing using RFC 3323 instead of “removing” entries

8 Issue 1: aor tag A URI entry is marked as "aor" when a proxy responsible for the URI recognizes it as an AOR (i.e., it uses it for a location server dip). One question asked on the list is how to treat IP addresses as domains? Can entries using IP addresses be AORs? –Answer: when a domain uses an IP address as a domain name instead of a proper DNS domain name, yes, it can be considered an AOR. –Proposal: Clarify in next version.

9 Issue 2: rc / cc / rt tags Alternatives: 1.“rc / cc / rt” tags, i.e., mechanichal precision 2.“fluff”, i.e., call it what it is 3.“no tag”, i.e., ignore them 4.“no entry”, i.e., ditch them 1 & 2 allow for distinguishing fluff from important pre-bis entries, 3 & 4 do not 4 result in “simpler” HI header

10 Issue 3: mp tag Unlike the "fluff" parameters, it means a "user different from the previous one". In the current draft, the "mp" tag represent the "mapped- TO" address, not the mapped-FROM address. –It tells something about why a new entry is recorded. Instead of tagging the previous entry when a new entry is recorded. –It also makes the algorithm for finding the first URI with which a user is addressed easier as it is only needed to find the last “mp” tagged entry. –However, it is not optimal for algorithms that are looking for the “mapped-from” number, e.g., the classical “Redirecting number” used by legacy voic systems and such.

11 Issue 4: algorithms for retrieving different targets by the UAS -Algorithm for retrieving the target-uri for applications such as TollFree Number: 1.traverse all H-I entries backward until an "mp" entry is found, if found this is the addressed target 2.if no "mp" found take the first H-I entry 3.if no History-Info header take the Request-URI value -Algorithm for retrieving the last used target-uri (typical Netann scenarios where parameters are needed, P-Called-Identity, etc.): 1.Pick last hi-entry marked with aor -Conclusion: there is more than one target-URI problem, thus flexibility is needed

12 Issue 5: privacy RFC 3323 was written with a 2-party model. Some of the wording in the documents was changed from 4244 to adapt to individual H-I entries. It is not clear if further enhancements to RFC 3323 are required. We are inviting people to look at it.