1 / 5

Real-time Routing of Voice and Video Messaging for ENUM Services

This draft document registers the Enumservie named "vmsg" which facilitates real-time routing of voice and video communications to a messaging system. The document also discusses the need for multiple IP voice messaging systems and the use of ENUM for routing calls.

jkesler
Download Presentation

Real-time Routing of Voice and Video Messaging for ENUM Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IETF 70 – ENUM WGEnumservices for Voice and Video Messaging<draft-ietf-enum-vmsg-00> 4 Dec 2007Co-Authors:Jason LivingoodDon TroshynskiContributors:Rich FerriseChris HarveyHadriel KaplanTong Zhou

  2. 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: • Name = voicemsgType = voicemsgSub-types = SIP, SIPS, TEL, HTTP, HTTPSURIs (respectively) = SIP, SIPS, TEL, HTTP, HTTPS • Name = videomsgType = videomsgSub-types = SIP, SIPS, HTTP, HTTPSURIs (respectively) = SIP, SIPS, HTTP, HTTPS • Name = unifmsgType = unifmsgSub-types = SIP, SIPS, HTTP, HTTPSURIs (respectively) = SIP, SIPS, HTTP, HTTPS

  3. 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?

  4. 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 voicemail). • Use a single external TN for users to access voicemail via non-IP PSTN, internally route from central point(s) to the proper message store.

  5. 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.

More Related