Subject: [Enum] draft-livingood-enum-voicemsg-00

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 4 Sep 2007 11:33:43 -0400

Given that the WG is winding down, and that the co-authors of this new I-D wish to make substantive progress before IETF 70, we are requesting approval of the WG chairs to make this an official WG draft.

http://www.ietf.org/internet-drafts/draft-livingood-enum-voicemsg-00.txt

Regards
Jason Livingood

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 Sep 2007 13:54:49 -0400

I have some difficulty with this proposal.

The problem is that it uses enum to solve a problem that is not unique 
to phone-number addresses. The desire to reach a voicemail or other 
message taking service for a particular callee is applicable to sip as 
well as telephone numbered addresses. An enum solution solves half of 
the problem, and thus ensures that there will be divergent solutions.

This problem was already addressed as part of callerprefs. (RFCs 3840 
and 3841.) I don't see why that solution won't work here.

	Paul

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 4 Sep 2007 14:20:44 -0400

In theory, as co-chair, have no objections to this request. 

If anyone has objections to making this a WG document post them now or
forever hold your peace. 

This is a straight forward document well within current charter and I don’t
think it would be useful to delay this by applying the new registration
procedure, which BTW needs to be worked on NOW well in advance of Vancouver.
Hint Bernie :-) !! 

I do suggest that you beef up the issue of why RFC 4238 is not appropriate
for the application you choose. 

This will come under some scrutiny from the VPIM/LEMONADE WG people. You
might run it past them for comments etc.

>  -----Original Message-----
>  From: Livingood, Jason [mailto:[email-masked]]
>  Sent: Tuesday, September 04, 2007 11:34 AM
>  To: Richard Shockey; Patrik Fältström; [email-masked]
>  Cc: Zhou, Tong; Ferrise, Rich; Harvey, Chris; Don Troshynski; Hadriel
>  Kaplan
>  Subject: draft-livingood-enum-voicemsg-00
>  
>  Given that the WG is winding down, and that the co-authors of this new
>  I-D wish to make substantive progress before IETF 70, we are
>  requesting approval of the WG chairs to make this an official WG
>  draft.
>

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 5 Sep 2007 10:01:03 -0400

> The problem is that it uses enum to solve a problem that is 
> not unique to phone-number addresses. 

You can debate that if you like, but my use cases are for service providers offering TN-based VoIP services.  This is a problem that exists today, at scale, in my and other networks.  I am happy to discuss future, non-TN-based services and am certainly aware of the fact that SIP URIs handle this (which is a big benefit of SIP of course).  But I need to solve a very straight-forward, TN-based problem.  I want to do a DNS lookup in my ENUM servers and for a given TN be able to determine where a voice mailbox is located so that I can then route that call appropriately, inexpensively, and using open-standards-based methods.

The approach to use ENUM is also very simple and easy to implement for SPs who are now widely implementing ENUM in their VoIP service architectures.  In addition, there is not another ENUM service type that meets the needs of this application.  For all of these reasons, we believe this merits a new ENUM service type.  Furthermore, I believe in the future when the WG is no longer active, the function of approval for new types is that it is technically compliant with the general guidelines for ENUM registrations. In the end, as with most ENUM services or other RFCs, the true test is running code and then market adoption and we're confident in both.

> The desire to reach a 
> voicemail or other message taking service for a particular 
> callee is applicable to sip as well as telephone numbered 
> addresses. 

This is true.  However, I do not know of many providers offering non-TN-based voicemail.  We are trying to solve a problem that SPs have today.

> An enum solution solves half of the problem, and 
> thus ensures that there will be divergent solutions.

What is the other half??  We need to be able to (1) determine that a call is destined for voicemail (no issues, do it today), (2) figure out where the voice mailbox is located (this I-D), and then (3) route the call appropriately (no issues, do it today).

Regards,
Jason

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Sep 2007 18:44:16 -0400

> The approach to use ENUM is also very simple and easy to implement for SPs who are now widely implementing ENUM in their VoIP service architectures.  In addition, there is not another ENUM service…

I have no desire to get into a pissing match. I will leave it to others 
to decide if the expediency of the situation justifies one solution for 
phone numbers and a different solution to the same problem when the 
target is a sip address. But I think it is relevant to recognize that 
this is setting up a path with divergent solutions.

> This is true.  However, I do not know of many providers offering non-TN-based voicemail.  We are trying to solve a problem that SPs have today.

Sadly, I expect it is true that not many providers offer this. But that 
will hopefully change. Certainly providers do offer recording of text 
messages. As MSRP is implemented that will entail accepting an INVITE 
session with a media stream - just not a voice media stream. For those 
systems that support both voice and text, it will be natural for the 
same server to accept either or both.

> What is the other half??  We need to be able to (1) determine that a call is destined for voicemail (no issues, do it today), (2) figure out where the voice mailbox is located (this I-D), and then…

The other half is non-phone-number based calls.

	Paul

---

From: Daryl Malas <[email-masked]>
Date: Thu, 06 Sep 2007 09:02:47 -0600

Just a thought on this one...

Isn't a voice mail server ultimately just a UAS?  Therefore, I would
imagine a SP would simply provide a sip uri of [email-masked] as a
route and/or forward choice in the customer/subscribers routing profile?
This is similar to how some traditional (many circuit switch) LEC's
provide voice mail to their subscribers.  They simply have a hunt group
for an additional TN or TG (Trunk group).  I don't see how this is
different than capabilities that exist in the sip world today.  Whether
a subscriber dials the voice message platform directly or via a TN with
ENUM resolution, a URI is a URI...it's ultimately just a UAS?!  ...or,
am I missing something here?  Doesn't it really matter to have an
additional value in ENUM called voicemsg?

Just curious.

Thanks...--Daryl

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 7 Sep 2007 15:01:09 -0400

> I have no desire to get into a pissing match. I will leave it 
> to others to decide if the expediency of the situation 
> justifies one solution for phone numbers and a different 
> solution to the same problem when the target is a sip 
> address. But I think it is relevant to recognize that this is 
> setting up a path with divergent solutions.

I can't be the one that registers all possible ENUM services though.
;-)  

In all seriousness, my application will use a SIP URI that includes a TN
in the user address.  Now, theoretically, that could be [email-masked]
just as easily as [email-masked].  This registration would not
preclude that - the registration is for a type with specific URIs,
without regard to what is actually inside those URIs if you know what I
mean.  I added in the Tel URI as I figured it might be useful to someone
else (though not me).

> >> An enum solution solves half of the problem, and thus ensures that 
> >> there will be divergent solutions.
> > 
> > What is the other half??  We need to be able to (1) 
> determine that a call is destined for voicemail (no issues, 
> do it today), (2) figure out where the voice mailbox is 
> located (this I-D), and then (3) route the call appropriately 
> (no issues, do it today).
> 

And I do not believe this draft precludes those calls.  I would be
**more** than happy to add one or more examples to section 5 Examples
that show non-TN-based SIP URIs here if you feel that would help.  For
example, perhaps:

5.4 Example of a calling party send to a voice messaging system, Using a

    'sip' URI Scheme where the URI does not contain a telephone number
    
   $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. 
      NAPTR 10 100 "u" "E2U+voicemsg:sip" 
      "!^.*$!sip:[email-masked]!". 
    
   In this example, a calling party has attempted a session which has 
   gone unanswered after a certain period of time. The calling party's 
   session is sent to the appropriate voice messaging server, a 
   personalized greeting is played to the calling party, after which 
   they record a voice message to the called party.  The URI that this 
   session is directed to does not include a telephone number, as this 
   user has multiple service that are not particularly tied to telephone
   numbers whereby text, audio, video and other multimedia messages can
   be received and accessed.

Jason

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Sep 2007 17:56:48 -0400

> mean.  I added in the Tel URI as I figured it might be useful to someone

I'm not sure I understand. I *think* you are saying that given an E.164 
number +12155551212, you intend to use enum to map it to:
	sip:[email-masked] (the primary destination)
   and	sip:[email-masked] (for VM)

And you are saying that it would be fine with you if the mapping were 
instead:
	sip:[email-masked] (the primary destination)
   and	sip:[email-masked] (for VM)

Is that right?

If so, it means that people that are calling my E.164 number will get 
the option of my primary address or my VM, but those who know my address 
as sip:[email-masked] won't have the VM option. So the VM option is 
then only avaiable with E.164 numbers.

>    be received and accessed.

Thats fine, but its not the case I am concerned with.

My concern is when the original target of the call was 
<sip:[email-masked]> and it goes unanswered for awhile and is supposed 
to fail over to VM.

People building systems where the AORs are not phone numbers *have* a 
way to do that. Either the VM is actually registered as a lower priority 
contact, or it is *configured* as a lower priority contact.

If I have that already, and then I want to be reached via an E.164 
number as well, it would make perfect sense to register an enum entry 
for sip that points to sip:[email-masked]. But it *doesn't* make sense 
to put a separate entry in enum for my VM, because the VM will be 
handled *after* the translation is done and the call is routed to the 
translated address.

Note: it makes a big difference whether we are talking about public 
enum, or private enum, or some other kind of enum. I can see how in some 
cases you might want to use a private enum as a sip location service for 
resolving E.164-based AORs *after* they reach your domain where you are 
acting on behalf of the recipient. At that point if you want to use this 
mechanism to keep track of different classes of contacts for the AOR, I 
have no problem.

But its a different story with public enum, where it is presumed that 
the *caller* (or an agent working on behalf of the caller) is doing the 
resolving of the e.164 number. As I've been trying to explain, the 
problem is that this leads to partitioning the world into those who use 
e.164 numbers as their AORs and those who don't, with entirely different 
policies for how to reach VM in the two cases.

For instance, a caller who wants to reach VM directly without ringing 
the callee's phone first, would use ENUM to select the VM if the target 
is a phone number. But if the target is a non-e.164-sip-address then the 
way currently defined for doing that is for the caller to use 
callerprefs. And if the target is an e.164 number and there is no VM 
entry in enum, callerprefs is again the best hope.

Note that callerprefs has not been widely adopted. (Though it is 
specified in IMS.) This may partly be because it is complex, but also 
probably because nobody has a compelling need for the features it 
provides. If a *different* solution is adopted for E.164 numbers, which 
only works for E.164 numbers, then there will be features (such as 
"straight to VM") that only work for E.164 numbers. Then if the feature 
is recognized as important, the non-e.164 world will have to adopt an 
incompatible solution. And UAs that support both will need to implement 
both solutions.

I recognize that callerprefs is an ugly thing that only a parent could 
love. (I am almost a parent, and I don't love it.) I wouldn't be upset 
at a *different* solution, so long as it works for any kind of called 
address. Callerprefs does have the advantage that it is already an rfc, 
and there are is even a use-case rfc that shows how to use it to 
selectively call for VM-only, or to make a call and exclude going to VM.

	Paul

---

From: Duane <[email-masked]>
Date: Sat, 08 Sep 2007 08:57:10 +1000

> mean.  I added in the Tel URI as I figured it might be useful to someone

If you are going to this much trouble why not include a http type as
well so people can access voicemail in a webmail type fashion

-- 

Best regards,
 Duane

---

From: "Harvey, Chris" <[email-masked]>
Date: Sat, 8 Sep 2007 10:39:51 -0400

> well so people can access voicemail in a webmail type fashion

We wouldn't preclude that idea from a future registration, but currently
our plans for 'webmail type access' to voicemails are centered around a
different UA experience along with most other MSO's.

It's an interesting idea though worthy of future consideration outside
of our current proposal.

Chris Harvey

---

From: "Livingood, Jason" <[email-masked]>
Date: Sun, 9 Sep 2007 22:02:24 -0400

> > In all seriousness, my application will use a SIP URI that 
> includes a 
> > TN in the user address.  Now, theoretically, that could be 
> > [email-masked] just as easily as [email-masked].  This 
> > registration would not preclude that - the registration is 
> for a type 
> > with specific URIs, without regard to what is actually inside those 
> > URIs if you know what I mean.  I added in the Tel URI as I 
> figured it 
> > might be useful to someone else (though not me).
> 
> I'm not sure I understand. I *think* you are saying that 
> given an E.164 number +12155551212, you intend to use enum to 
> map it to:

Yes, a destination voicemail service could be [email-masked],
where ANYTHING HERE was a TN, a text name, etc.

So, call attempted to sip:[email-masked] could go to
sip:[email-masked] or it could go to sip:[email-masked]

In terms of mapping sip:[email-masked] to any particular voicemail
location, that is outside the scope of this ENUMservice since it does
not include a TN and ENUM requires a TN to perform a query.  

That being said, however, I suppose if your SIP UAS or UAC had some
internal mapping of [email-masked] to 12155551212, then I suppose that
could perform some ENUM query, but that is not really what is intended
here. 
 
> If so, it means that people that are calling my E.164 number 
> will get the option of my primary address or my VM, but those 
> who know my address as sip:[email-masked] won't have the VM 
> option. So the VM option is then only avaiable with E.164 numbers.

This is an ENUM service and so it therefore depends upon a TN to
actually do something.  This ENUM service in no way precludes a SIP UAS
or UAC from in some way mapping sip:[email-masked] to a sip-addressed
voicemail box, nor does it even attempt to address this, as it does not
involve a TN.

> <sip:[email-masked]> and it goes unanswered for awhile and 
> is supposed to fail over to VM.

That is completely cool with me, but how is that relevant to an
ENUMservice, which is by definition doing something based on a TN as
input?  I believe the case you cite, which in no way involves a TN,
functions perfectly will by itself in SIP using existing RFCs today. 

> People building systems where the AORs are not phone numbers 
> *have* a way to do that. 

I agree with you.  This ENUM service is for people where the AORs *are*
TNs. 

> Note: it makes a big difference whether we are talking about 
> public enum, or private enum, or some other kind of enum. I 
> can see how in some cases you might want to use a private 
> enum as a sip location service for resolving E.164-based AORs 
> *after* they reach your domain where you are acting on behalf 
> of the recipient. At that point if you want to use this 
> mechanism to keep track of different classes of contacts for 
> the AOR, I have no problem.

The intended case here is private ENUM.  
>From the draft here is text we included:
 
3. Distribution of Data 
    
   The authors believe that it is more likely that these records will be

   distributed on a purely private basis, but they may also be 
   distributed in public ENUM trees. Distribution of this NAPTR data 
   could be either (a) on a private basis (within a service provider's 
   internal network, or on a private basis between one or more parties 
   using a variety of security mechanisms to prohibit general public 
   access) or (b) openly available. 
 
> But its a different story with public enum, where it is 
> presumed that the *caller* (or an agent working on behalf of 
> the caller) is doing the resolving of the e.164 number. As 
> I've been trying to explain, the problem is that this leads 
> to partitioning the world into those who use
> e.164 numbers as their AORs and those who don't, with 
> entirely different policies for how to reach VM in the two cases.

I hear you, but doesn't that partitioning of TN-based communications and
non-TN-based communications already exist in the marketplace?  I am not
sure this discussion can go anywhere other than into a philosophical
debate over TNs vs. user names, besides which this is a WG that is all
doing IP-based stuff with TNs as an input.  

> For instance, a caller who wants to reach VM directly without 
> ringing the callee's phone first, would use ENUM to select 
> the VM if the target is a phone number. But if the target is 
> a non-e.164-sip-address then the way currently defined for 
> doing that is for the caller to use callerprefs. And if the 
> target is an e.164 number and there is no VM entry in enum, 
> callerprefs is again the best hope.

Please explain how, when someone dials 1-215-555-1212, which is routed
to my (Cisco BTS) Call Management Server, and no one answers, I can use
callerprefs to determine which of, say 10 different voicemail pods to
send the call to.

> Note that callerprefs has not been widely adopted. (Though it 
> is specified in IMS.) 

And this is part of my problem.  We need to deploy a workable solution
rapidly, and happen to see that this ENUM service will immediately work
to do so with minor modifications to SIP routing functions and ENUM
server functions.

> This may partly be because it is 
> complex, but also probably because nobody has a compelling 
> need for the features it provides. 

I admit to not knowing much about your callerprefs drafts, but did read
them quickly after you referred to them earlier.  I am not sure they
help me with our problem in the relatively short-term.  However, we have
what we believe is a compelling need for the features provided by this
ENUMservice.

> If a *different* solution 
> is adopted for E.164 numbers, which only works for E.164 
> numbers, then there will be features (such as "straight to 
> VM") that only work for E.164 numbers. 

In terms of voicemail, it seems to me that one could get to a SIP-based
voicemail system using a non-E.164 number just fine, and someone with
either a UAC or UAS can develop a feature to go straight to voicemail.

> Then if the feature is 
> recognized as important, the non-e.164 world will have to 
> adopt an incompatible solution. And UAs that support both 
> will need to implement both solutions.
> 
> I recognize that callerprefs is an ugly thing that only a 
> parent could love. (I am almost a parent, and I don't love 
> it.) I wouldn't be upset at a *different* solution, so long 
> as it works for any kind of called address. 
> Callerprefs does 
> have the advantage that it is already an rfc, and there are 
> is even a use-case rfc that shows how to use it to 

I absolutely 100% respect the hard work that I am sure went into those
RFCs, they are extremely detailed and thorough.  I am just not sure that
they apply to our use cases, or at least they do not appear to be as
rapidly and easily implemented.  In this case, my preference is for what
is cheapest, fastest, and simplist (just good enough to do the job).
The advantage of ENUM services for this is that once a VoIP network
supports SIP and ENUM, a new ENUM service represents nearly no
additional work or investment.

Regards
Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Sun, 9 Sep 2007 22:04:21 -0400

Excellent idea.  We can pull some similar text from RFC 4002.  This
would merely be another sub-type to the overall "voicemsg" type.

We will be able to quickly update this for the next I-D revision.

Regards
Jason 

> From: Harvey, Chris 
> Sent: Saturday, September 08, 2007 10:40 AM
> To: 'Duane'
> Cc: Paul Kyzivat; [email-masked]; Don Troshynski; Zhou, Tong; 
> Ferrise, Rich; Hadriel Kaplan; Livingood, Jason
> Subject: RE: [Enum] draft-livingood-enum-voicemsg-00
> 
>  
> We wouldn't preclude that idea from a future registration, 
> but currently our plans for 'webmail type access' to 
> voicemails are centered around a different UA experience 
> along with most other MSO's.
> 
> It's an interesting idea though worthy of future 
> consideration outside of our current proposal.
> 
> Chris Harvey
>

---

From: [email-masked]
Date: Mon, 10 Sep 2007 15:56:10 -0400

From: Daryl Malas <[email-masked]>

Or in SIP terms, an additional contact for the AOR that has a low q
value.

The sipX system uses this technique.  And I expect that just about
every natively SIP system does also.  E.g., a contact lookup for
sip:[email-masked] gets you the URI of a registered phone and the
URI for the media server, with URI parameters instructing it to
deposit voicemail in the correct mailbox:

	INVITE sip:[email-masked] SIP/2.0
	From: <sip:[email-masked]>;tag=cp41w9vzg7
	To: <sip:[email-masked];user=phone>
	Call-Id: 3c26701104e2-goolwjfexwgr
	Cseq: 26 INVITE
	Contact: <sip:[email-masked]:2051;line=cin9noi4>;flow-id=1

	SIP/2.0 302 Moved Temporarily
	Contact: <sip:[email-masked]:2072;line=6z970hiq>
	Contact:
	<sip:[email-masked]:5100;voicexml=https%3A%2F%2Flocalhost%3A8091%2Fcgi-bin%2Fvoicemail%2Fmediaserver.cgi%3Faction%3Ddeposit%26mailbox%3D9207275718>;q=0.1
	From: <sip:[email-masked]>;tag=cp41w9vzg7
	To: <sip:[email-masked];user=phone>;tag=ddpkbnbien
	Call-Id: 3c26701104e2-goolwjfexwgr
	Cseq: 26 INVITE

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Sep 2007 16:38:41 -0400

[email-masked] wrote:
> every natively SIP system does also. 

I thought this until I saw how IMS works. (I guess its arguable whether 
it is a "natively SIP system".)

It seems that the natural way to handle VM for it is:

A proxy aware of the VM policy of the user (call it the "vm-proxy") is 
in the signaling path for every call, before the "home-proxy" that does 
translation of AOR based on the location service.

Initially the vm-proxy establishes a timer, and then allows the call to 
proceed to the home-proxy and be translated based on the location 
service, including forking, etc.

If the call is answered before the timer expires, vm-proxy simply 
cancels its timer. (No VM involvement.)

If a busy response is returned before the timer expires (all downstream 
forking by home-proxy and beyond exhausted and busy is the *best* 
response) then the vm-proxy acts as a forking proxy and sends the call 
to VM.

If the timer expires without a final response having been seen, then the 
vm-proxy acts as a forking proxy - canceling the transaction to the 
home-proxy and then forking the call to the VM system.

This is roughly comparable to configuring a lowest priority entry for 
the VM system in the location service of every applicable user. But 
there are some significant differences:

THe VM-on-no-answer is timer based, and uncoordinated with how many of 
the registered candidates have been tried. It could be a problem if 
there are a number of candidates and sequential forking is being done. 
OTOH, it may be more consistent with the user experience people expect.

Another problem is that it interacts poorly with callerprefs. With 
callerprefs the candidates are collected and ranked. But here the pool 
of candidates is split into two. At best callerprefs will be applied to 
each half separately. At worst they won't be applied to the VM system at 
all. So for instance callerprefs that *prefer* VM over a live user may 
not work well (or at all).

	Paul

> E.g., a contact lookup for

---

From: [email-masked]
Date: Tue, 11 Sep 2007 15:25:52 -0400

From: Paul Kyzivat <[email-masked]>

Yeah, I've wondered that myself.

This is pretty much a forking proxy that sets an expiration time on
the first (phone) leg, and if that leg fails or times out, sends the
call to a second (voicemail) leg.

Early automobiles were steered with reins, because that was how you
had steered horses.

Dale

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 13 Sep 2007 16:55:09 -0400

In line ..PLEASE READ CAREFULLY.

>  >> setting up a path with divergent solutions.

This is an important thread since it highlights some of the critical issues
in the registration draft that we need to continue to make progress on. Hint
Hint ..

http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-04.tx
t

The issue is what are the criterion by which a particular scheme can be
registered or not. This is an issue we have not completely resolved in the
registration document and it is a critical requirement.

I tend to support the position that if someone has a workable idea that
meets a reasonable test of "usefulness" and there are no glaring conflicts
with other schemes the registration should proceed.

>  enum, or private enum, or some other kind of enum. I can see how in
>  some  cases you might want to use a private enum as a sip location
service
>  for  resolving E.164-based AORs *after* they reach your domain where you
>  are  acting on behalf of the recipient. At that point if you want to use
>  this mechanism to keep track of different classes of contacts for the
AOR,
>  I have no problem.
>  the *caller* (or an agent working on behalf of the caller) is doing
>  the  resolving of the e.164 number. As I've been trying to explain, the
>  problem is that this leads to partitioning the world into those who
>  use  e.164 numbers as their AORs and those who don't, with entirely
>  different  policies for how to reach VM in the two cases.
>  
>  the callee's phone first, would use ENUM to select the VM if the
>  target  is a phone number. But if the target is a non-e.164-sip-address
then
>  the  way currently defined for doing that is for the caller to use
>  provides. 

That is a understatement if I have ever heard one. :-) 

If a *different* solution is adopted for E.164 numbers,
>  which  only works for E.164 numbers, then there will be features (such as
>  "straight to VM") that only work for E.164 numbers. Then if the
>  feature  is recognized as important, the non-e.164 world will have to
adopt an
>  incompatible solution. And UAs that support both will need to
>  implement both solutions.

Now as I read this draft it struck me that the application being described
is more focused on intra vs inter domain VM retrieval and as such would be
principally used in private enum instantiations.

There should be no question that the enum service registration process can
be used to define private applications that will never be used in e164.arpa
or other globally visible DNS root. We have already opened up that barn door
with the PSTN Signaling data RFC 4769 and with the (by the grace of ...)
CNAM data as well.

The issue on the table is whether this document meets the criterion for WG
document and IMHO it is well within our existing charter. Since there is
clearly interest here and the Enumservices registration procedures document
is far from completion. I am inclined to support making this a WG document
unless there is strong objection.

DISCLAMER: Just because it is a WG document does not mean it will ultimately
be approved etc.

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 25 Sep 2007 13:08:42 +0200

[I'm a bit late on this thread, but anyway ...]

>From what I get from below, your sole motivation now is internal use. Is
this correct?

> callerprefs to determine which of, say 10 different voicemail pods to

Just for clarification, to see whether I understand your motivation: 

Within your call routing system, whenever you need to divert the call
to voicemail you need to somehow look up the correct URI for the
voicemail of that user/TN. As your system is too big to handle all
voicemail on a single server (which would make the rewrite trivial),
you need a more dynamic, DB-driven lookup mechanism to determine the
new URI. You probably don't care whether that lookup is LDAP, local
DB, SIP redirect or whatever as long it's easily implemented and does
not significantly change your operating costs.

(For what it's worth, in http://www.at43.at/en/ we store the VM URI in
the same DB which also hold the SIP registrations. We do not need to
make a second query to anything if the call needs to be diverted to
VM (on timeout or on user not online). )

In theory, you could just use a x-whatever service field to store your
VM URI in your internal ENUM, and since these records just appear in
your own private network, that's fine and dandy and nobody can stop you
from doing that. Especially if you already base your local call routing
on a private ENUM tree.

Documenting this approach in an I-D and registering a service-type seems
to have two advantages:

* it's easier to say to a vendor "we need support for RFC XXX" than "we
  need you to implement this fancy scheme we came up with". Plus,
  hopefully less vendor lock-in.

* if you merge with another company, chances are higher that you both
  use the same scheme, which lowers integration costs.

That all sounds very legitimate to me.

----------

I cannot see a good motivation for a cross-operator use of this
service-type. But who knows what might come up in the future.

/ol
-- 
/ Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 \
| nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H |
\ http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg /