Weon Kim / NIDA. Chanki Park / NIDA. Lawrence Conroy / Rok

1
ENUM-based Softswitch Requirementltdraft-ietf-enu
m-softswitch-req-01.txtgt

• 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

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)

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)

5
Ready for WG Last Call?

• Since 69th meeting, (for 3 months), we havnet
  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.

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
  voicetel 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
  voicetel 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".

7

• Thank You!