Page 1I IETF ENUM WG IETF 70 – ENUM WG Enumservices for Voice and Video Messaging 4 Dec 2007 Co-Authors: Jason Livingood Don Troshynski Contributors: Rich Ferrise Chris Harvey Hadriel Kaplan Tong Zhou

Page 2I IETF ENUM WG History of the Draft Started with two individual I-Ds: –Voicemsg –Videomsg Combined into one WG I-D Three Enumservice Types Are Registered By This Draft: 1.Name = voicemsg Type = voicemsg Sub-types = SIP, SIPS, TEL, HTTP, HTTPS URIs (respectively) = SIP, SIPS, TEL, HTTP, HTTPS 2.Name = videomsg Type = videomsg Sub-types = SIP, SIPS, HTTP, HTTPS URIs (respectively) = SIP, SIPS, HTTP, HTTPS 3.Name = unifmsg Type = unifmsg Sub-types = SIP, SIPS, HTTP, HTTPS URIs (respectively) = SIP, SIPS, HTTP, HTTPS

Page 3I IETF ENUM WG Why? Abstract: This document registers the Enumservice named "vmsg", which is used to facilitate the real-time routing of voice and/or video communications to a messaging system. This vmsg Enumservice registers three Enumservice types; "voicemsg", "videomsg", and "unifmsg". Real-time routing to IP voice messaging systems today: –Static configuration for routing of calls, on Call Forward / Busy / No Answer. –Generally, one IP messaging destination per proxy / softswitch. –This was fine when the number of mailboxes was relatively low and when there were just one or two monolithic messaging systems. But what happens when you have: –Millions of IP voice messaging mailboxes? –Multiple datacenter locations? –A desire to have primary and real-time active backup sites? –And want fail-over / re-routing to be immediate and automatic? –And within a datacenter you wanted to have multiple, modular messaging pods? Then you may need many IP voice messaging systems to represent to proxies / switches. –And yet, each of these switches can have but one route. Or can it?

Page 4I IETF ENUM WG Well Then… Consider the capabilities of existing proxy / softswitch systems: –Most now support ENUM for real-time routing of calls. –Some service domains (the really cool ones of course) now support ENUM records, and often on a per-subscriber basis. –So, a good ENUM infrastructure is in place and can be easily leveraged. Configure the proxy / switch to perform an ENUM lookup on call forward / busy / no answer, and determine the location of the subscriber’s IP voice messaging mailbox. As an added bonus: – Load balance across multiple destinations. –Configure primary / secondary locations. –Have separate voice messaging and video messaging locations, per subscriber. voicemsg videomsg –Have a single unified voice & video messaging location. unifmsg –Use it for HTTP/HTTPS (like, say, for VoiceXML, or web access to voic ). –Use a single external TN for users to access voic via non-IP PSTN, internally route from central point(s) to the proper message store.

Page 5I IETF ENUM WG Comments / Feedback / Suggestions? We’re planning to add a few more examples to illustrate load balancing and failover use cases, to enable easy adoption. (Mentioned at a high level in Section 10.1) We’re considering consolidating the use cases for each service type (there are pros and cons to this). Other comments? –Incorporate any WG feedback here. –Make change(s) above, publish -01, and then probably ready for WGLC.