Last Modified: 2005-01-17
|Done||Initial draft of Service ENUM Requirements|
|Done||Initial draft of ENUM Protocol|
|Done||Revised draft of ENUM Protocol|
|Done||Submit ENUM Protocol document to IESG for publication as Proposed|
|Done||Revise and update RFC 2916 appropriate to DDDS (revision of 2915)|
|Done||ENUM service registrations for SIP and H.323|
|Aug 03||Document appropriate ENUM Security and Privacy Issues (Informational)|
|Nov 03||Document appropriate ENUM Registration and Provisioning Procedures (Informational)|
|RFC2916||PS||E.164 number and DNS|
|RFC3482||I||Number Portability in the Global Switched Telephone Network (GSTN): An Overview|
|RFC3761||Standard||The E.164 to URI DDDS Application (ENUM)|
|RFC3762||Standard||ENUM Service Registration for H.323 URL|
|RFC3764||Standard||enumservice registration for SIP Addresses-of-Record|
|RFC3953||Standard||Enumservice Registration for Presence Services|
|RFC4002||Standard||IANA Registration for ENUMservices web and ft|
Telephone Number Mapping WG (enum)
IETF 62 Minneapolis, MN
Wednesday, March 9 at 1300-1500
CHAIRS: Patrik Faltstrom <firstname.lastname@example.org>
Richard Shockey <email@example.com>
Transport Area Advisor:
Allison Mankin <firstname.lastname@example.org>
To Subscribe: email@example.com
In Body: subscribe
SCRIBE : Spencer Dawkins <firstname.lastname@example.org>
Report from APEET SIP/ENUM trial at Apricot 2005 at Kyoto.
* Informational item - Yoshiro Yoneya
* Goal of APEET is to conduct joint trials and promote ENUM and related technologies, including SIP
* Trial goal was to provide ENUM/SIP experience for every Apricot attendee
* Not providing telephony service - no warranties!
* Provided 802.11 handsets and id/passwords for ENUM directory
* Participants communicated with other attendees, overseas, registered ENUM information/opt-in phone book
* About 100 participants registered in phonebook, about 30 with more than two URIs
* Registration prototype now available as free software
* Supported three common SIP phone types
* 888-205-xxxx calls, overseas calls made with ENUM lookup
* About 7800 200-OKs, 300 other responses
* SIP really can use ENUM for call routing
* Authentication mechanism from SIP server to MGW is different for each gateway - requires testing
* Handover between access points is still difficult
* RTP within same AP still difficult
* Planning to offer same service at IETF 64 (500-2000 handsets) in Vancouver
* Was this trial only on ENUM operation or on delegation, etc? Mostly providing experience for participants
1. Discussion of the ENUM dip indicator on behalf of the IPTEL WG.
* Left out an author in 00 draft - will add in 01 after blackout period
* Enumdi syntax has not changed
* Replaced MUST NOT retrieve with SHOULD NOT retrieve
* Updated examples as example.com domain names
* Recommending IPTEL WGLC on this document
2. Status from Patrik on what is happening with the IANA and enumservice registrations.
* Issues resolved on Monday of this week - everything has been sorted out with IANA
* Are VPIM registrations consistent with what we want? Yes, with no additional changes identified on the mailing list - they have been approved by IESG and are good to go now
* Enum+? This will be updated in RFCs
2b. There seems to be a sense that we need to at least discuss some of the structure issues in enumservice registrations in general terms ..this seems to be a warm issue recently with various requirements coming out of 3GPP etc . In particular we do not have a TEL URL enum registration document as of yet and someone needs to take on that task.
* VOPI registration draft? Make this a working group item, as informational document?
* Still need a standards-track TEL URL document - we'll clarify all this on the list
3. Issues related to IRIS for ENUM -- We have had no in-depth discussion of this draft on the list and we'd like to see more.
* Who has read it? Not a lot of people in the room
* Opinions or concerns about this document? ENUM administrations are looking at this document as a potential requirement
* This is a wonderful document ...
* Minimal changes since last revision, fourth version as WG document
4. New Item Enumservice registrations for Conferencing Alan Johnston 20M
A URL for this Internet-Draft is:
* conf-web and conf-uri registrations
* conf-web is discovery mechanism for web conferences - URI is a source of information about the conference
* either HTTP or HTTPS
* Value over RFC 4002 web? Don't know a web URI is about a conference
* Will a single phone number route to a single person or to a conference? Why would a UA ever do this lookup?
* My phone number might have a web page associated with it, but most callers won't bring up the web page unless they know it's part of the conference
* Madness lies this way - there's no end to what we might treat as a special case
* If both web and conf-web are present, they probably point to the same URI
* Problem we're solving is telling a caller "this is a conference" - even if it doesn't exist on the IP network at all? Is this even an ENUM problem?
* Do see difference between web and conf-web - should they refer to different phone numbers?
* Not finding a resource, but providing information about the resource - this isn't how we want to use ENUM service tags
* If the service provider needs to provide multiple URIs, multiple ENUM tags make sense
* Is this a phone number that identifies a conference, or a conference server? If it's a conference server, that's ludicrous, if it's a conference, it makes more sense
* Would a user go to a single web server to enter a PIN number? What about different PINs for different components of the conference?
* We're moving along discovering how much information we want to publish for ENUM services, and there are lots of potential kinds of things to publish - "the client might want to know" doesn't let us draw the line anywhere
* SIP has a negotiation capability so we don't need this in SIP - this is more about the kind of thing you'll find if you call the resource - picture of a dog on the web page? conversations about communism? What does a client do differently when they see this tag?
* Is interpretation based on human intelligence, or does it accommodate automatons? Automatons would require a lot more structure than we're talking about here.
* Isn't this the same as isfocus in SIP? If we needed that, we need this
* We should be keying off a specific kind of XML document, not off an enumservice tag
* Conf-uri is actually the controversial part of the proposal...
* Says that the resource is a focus
* How many telephone numbers are true conference URIs with no passcode or PIN needed?
* Is it OK to have both a sip and a conf-uri URI?
* Not hearing clear consensus on what to do with this document, or what to do with conferences in enumservice registrations (is it needed or is this part of normal SIP negotiation?)
* Concern is that devices who don't understand this tag won't be able to connect to a conference - need to include sip if you include conf or conf-uri
* What's wrong with just saying "isfocus" in the SIP URI returned from the lookup?
* Is it necessary to know that it's a conference before you start negotiating?
* Is there anything you'd differently before you contact the URI? That's the critical question
* We're trying to create boundaries on what a service is, on an ad hoc basis, and that's not working well
* Alan to respin this document with more use cases to see if we can move forward
* We need to be a lot better at deciding what is a service than we are now... it can't be this painful every time someone proposes an enumservice!
* We also need to worry about URI schemes defined by people who didn't think about any of this
5. In private discussions with folks there seems to me a demonstrable need to create a SOAP binding for EPP-164. I believe this is an extremely important project and I'd like to see if there is A. sufficient interest in the project and if there is sufficient interest B. find some folks who would be willing to work on the draft.
* Mostly enterprise-level interest, and their toolkits are based on SOAP. Anything that helps with provisioning is good.
6. ENUM Validation update w/Bernie Hoeneisen
* Ensure that ENUM owner == E.164 owner at registration time
* Version 01 is adding requirements section, split into transport and content, handling renewal and transfer, adding acknowledgements and corrections/updates
* Should this be a working group item? as Informational item? Room hum is "yes"
7. Status of ENUM Operational Experiences draft?
* No new items in document - can we WGLC a new revision before Paris? Yes
8. WG next steps?
* Enumdi loops when we're trying to prevent loops? discussion on mailing list - if you get the same tel URI back, this is just loop detection with one bounce - can we just cover the general loop case with hop count > 1? What do you do when you get a loop back with or without enumdi? Use first one, last one ...
* GSMA or 3GPP may be requesting ENUM for GRX network - two NAPTR, one with SIP and one with e-mail for SMS messages. If there is an IMS enum service, should the enumservice be ims: or sip+ims:? This is another slippery slope - is this IMS release 5, IMS release 6, ... but it sounds really wrong. Do we need to take on a liaison on this? Slippery slope is about 80-percent incline. Doesn't matter if we have an official liaison or not - we need to know what to tell them, either way. ETSI has asked and we can give them our opinions. Why do you need to know that a user is within the IMS system? We have no idea. This is using the DNS as a replacement for negotiation. There's an IAB draft on DNS assumptions that's in last call - please look at this and comment! ENUM idea is that you look up one number and get back one URI - if you voice and IM from the same SIP URI, this has to come from one provider, right? Where do we multiplex- ENUM or SIP? How much SIP call routing do we put in DNS (suggested answer = none). If we don't want to do this, we need to make sure people can't try, or they'll try for sure.