ENUM-based Softswitch Requirement < draft-ietf-enum-softswitch-req-01.txt>

1. ENUM-based Softswitch Requirement<draft-ietf-enum-softswitch-req-01.txt> 4 Dec. 2007 Joonhyung Lim / NIDA Weon Kim / NIDA Chanki Park / NIDA Lawrence Conroy / Roke Manor Research 70th IETF – Vancouver

2. Reminder • This draft is advisory. • Does not define or modify any standard material • Provides report of experience to help implementers • Taken from Deliverables of KR (+82) Infrastructure ENUM trial • This draft also contains discussion of topics important for implementers: • Carrier-level ENUM provisioning IETF.69

3. Current status • 67th Meeting (Nov 2006) • Individual draft was published • draft-lim-kim-enum-based-softswitch-00.txt • 68th Meeting (Mar 2007) • WG approved • draft-lim-kim-enum-based-softswitch-01.txt • started cooperation with WG people • draft-ietf-enum-softswitch-req-00.txt • 69th Meeting (July 2007) • Request for reports/experiences of other trials • Prepare for WG Last call on 70th meeting • Currently available • draft-ietf-enum-softswitch-req-01.txt • (minor typo error fixed on Table1, section 5) IETF.69

4. Since 69th Meeting • Result of requests for trial experiences • No responses received yet. • Current Issues to solve • None • Comments from WG people • writes out "unwritten" assumptions, worthwhile addition(Otmar) • Infrastructure trials should contribute to this draft - very useful(Jim) IETF.69

5. Ready for WG Last Call? • Since 69th meeting, (for 3 months), we havne’t received any responses giving trials experiences from anywhere. • We need to ship this document soon if it is going to be useful to carriers to help in their decisions. • This draft is designed to help in their practical decisions • Intended not to have sensitive or contentious items • Recent experiences are better in this case than waiting. IETF.69

6. There was one piece of feedback… • Section 2.5 of RFC 3761 "What constitutes an 'Enum Resolver'? says: There has been some confusion over what exactly an ENUM Resolver returns and what relation that has to the 'Note 1' section in RFC 3402. On first reading it seems as though it might be possible for an ENUM Resolver to return two Rules. The ENUM algorithm always returns a single rule. Specific applications may have application-specific knowledge or facilities that allow them to present multiple results or speed selection, but these should never change the operation of the algorithm. • Not all uses of a SIP URI will succeed. For example:- • An ENUM domain has two NAPTRs - one NAPTR with a “sip” Enumservice and another NAPTR with a “voice:tel” Enumservice. The NAPTR with a “sip” Enumservice has a better order and priority, and is selected. • If the subsequent SIP call fails (for example, because there is no common agreement between end points on supported Codecs, or that the called SIP entity rejects the INVITE due to lack of authorisation), a softswitch would normally ignore the “winning” NAPTR and continue with the next entry (in this case, the one with the “voice:tel” Enumservice). • But... the initial ENUM process has completed; it returned a single rule (the “winner”). • It seems that RFC 3761 section 2.5 does not permit the option of re-starting the ENUM query process while ignoring the initial winner. That could be interpreted as "changing the operation of the algorithm". • However, for good reason, that is what Carriers are very likely to do. • Maybe there should be clarification in RFC 3761bis that, until a call following an ENUM query is completed/placed correctly, the ENUM process still exists, and evaluation of the ENUM entries may continue if there is a failure (in the call processing, as well as the more immediate DNS/ENUM selection process)? IETF.69

7. Thank You! IETF.69