Subject: [Enum] Proposal for new enumservice "voicemail", using SIP URI

From: "Jackson, James" <[email-masked]>
Date: Sun, 28 Jan 2007 22:19:38 -0600

I would like to submit a registration for a new enumservice "voicemail"
using a SIP URI. Voicemail platforms are often accessible via SIP and it
would be desirable for callers to have the option to go straight to
voicemail rather than participate in an interactive form of
communication.

Any feedback from the group would be much appreciated.

Thanks,

James

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Jan 2007 08:52:26 -0500

I think the use of new enumservices for stuff like this is getting 
entirely out of hand. The proposed solution would work for E.164 
numbers, but the same functionality is of equal relevance for regular 
SIP URIs.

There is already a mechanism (callerprefs) for requesting (or refusing) 
the voicemail service associated with a sip AoR.

	Paul

Jackson, James wrote:
> I would like to submit a registration for a new enumservice “voicemail” 
> voicemail rather than participate in an interactive form of communication.
> 
>  
> 
> ------------------------------------------------------------------------
>

---

From: "Jackson, James" <[email-masked]>
Date: Mon, 29 Jan 2007 10:49:56 -0600

I think applicability to E.164 only would also apply to the VPIM service
etc. 

I agree that callerprefs is an attractive way to address the problem. At
the same time, I would expect it to be much more difficult to achieve
ubiquitous support for callerprefs.

James

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Monday, January 29, 2007 7:52 AM
To: Jackson, James
Cc: [email-masked]
Subject: Re: [Enum] Proposal for new enumservice "voicemail", using SIP
URI

	Paul

communication.

---

From: Shawn Pouliotte <[email-masked]>
Date: Mon, 29 Jan 2007 09:54:43 -0800

James,

Is there some functionality that you envision that cannot be achieved with
the current services? I tend to agree that the service set is getting a
little unruly and for the most part people are only using the basic ones
thus far. 

Can you elaborate on your requirements?

Thanks
Shawn

On 1/29/07 5:52 AM, "Paul Kyzivat" <[email-masked]> wrote:

>> I would like to submit a registration for a new enumservice ³voicemail²

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Jan 2007 13:56:07 -0500

> ubiquitous support for callerprefs.

It may be difficult to achieve ubiquitous support for the enum proposal 
too. It requires that there exist a unique, globally routable and 
stable, URI for referencing a users voicemail. I think there are many 
deployments in which that will not be the case. (IMS for example.)

	Paul

---

From: "Jackson, James" <[email-masked]>
Date: Mon, 29 Jan 2007 14:06:24 -0600

I'll try to elaborate a bit on the scenario I had in mind. A caller wants to leave a voice message for the callee - they do not wish to communicate with the callee directly. An ENUM query for the callee's E.164 number returns a voicemail service that includes a SIP URI for their voicemail. This URI could be a single generic URI that corresponds to the voicemail system or it could include the Call Forwarding Number of the callee. The client can optionally specify the mailbox in SIP by using a URI parameter as defined in RFC4458 i.e. target=mailbox. If no mailbox is specified, the voicemail system will prompt for a mailbox.

The existing SIP service could be used in conjunction with callerprefs instead of this mechanism although IMHO I think that getting every client and proxy to support callerprefs would be much more difficult.

If the voicemail system supports access via E-mail (VPIM, IVM etc), the client can easily use that via ENUM lookup. However, if the voicemail system only supports access via SIP, it is at somewhat of a loss.

James 

-----Original Message-----
From: Shawn Pouliotte [mailto:[email-masked]] 
Sent: Monday, January 29, 2007 11:55 AM
To: [email-masked]
Subject: Re: [Enum] Proposal for new enumservice "voicemail", using SIP URI

James,

Thanks
Shawn

---

From: [email-masked]
Date: Mon, 29 Jan 2007 15:42:08 -0500

From: "Jackson, James" <[email-masked]>

   The existing SIP service could be used in conjunction with
   callerprefs instead of this mechanism although IMHO I think that
   getting every client and proxy to support callerprefs would be much
   more difficult.

Though would it be more difficult than getting every callee to install
the right information into ENUM?

Dale

---

From: Shawn Pouliotte <[email-masked]>
Date: Mon, 29 Jan 2007 13:16:50 -0800

Hmmm,

Certainly makes logical sense to me - particularly in a private application.
4458 really talks about connecting and not how one gets the address in the
first place. It also presumes its a terminating service (which it typically
is) however having access via enum would allow it to be leveraged on
origination. 

Shawn

On 1/29/07 12:06 PM, "Jackson, James" <[email-masked]> wrote:

> 
> I'll try to elaborate a bit on the scenario I had in mind. A caller wants to
> leave a voice message for the callee - they do not wish to communicate with
> the callee directly. An ENUM query for the callee's E.164 number returns a
> voicemail service that includes a SIP URI for their voicemail. This URI could
> be a single generic URI that corresponds to the voicemail system or it could
> include the Call Forwarding Number of the callee. The client can optionally
> specify the mailbox in SIP by using a URI parameter as defined in RFC4458 i.e.
> target=mailbox. If no mailbox is specified, the voicemail system will prompt
> for a mailbox.
> 
> The existing SIP service could be used in conjunction with callerprefs instead
> of this mechanism although IMHO I think that getting every client and proxy to
> support callerprefs would be much more difficult.
> 
> If the voicemail system supports access via E-mail (VPIM, IVM etc), the client
> can easily use that via ENUM lookup. However, if the voicemail system only
> supports access via SIP, it is at somewhat of a loss.
> 
> James 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 30 Jan 2007 09:48:38 -0500

Jackson, James wrote:
> I'll try to elaborate a bit on the scenario I had in mind.
> A caller wants to leave a voice message for the callee -
> they do not wish to communicate with the callee directly.
> An ENUM query for the callee's E.164 number returns a
> voicemail service that includes a SIP URI for their voicemail.
> This URI could be a single generic URI that corresponds to
> the voicemail system or it could include the Call Forwarding
> Number of the callee. The client can optionally specify the
> mailbox in SIP by using a URI parameter as defined in RFC4458
> i.e. target=mailbox. If no mailbox is specified, the
> voicemail system will prompt for a mailbox.

The above assumes that the VM system is arranged in a suitable way. 
Notably that it has a unique and globally routable URI of its own for 
each mailbox (possibly by a common URI plus a parameter identifying the 
mailbox). Or at least that there is a single globally routable URI for 
the VM server and that the caller will be satisfied with having to enter 
the target phone number a second time.

It also of course assumes that the calling UA has some UI with its user 
to indicate a desire for reaching only VM, and that it will do the ENUM 
query and be familiar with the proposed new enum service.

And of course it also depends on user enum having  been deployed for the 
target number.

> callerprefs instead of this mechanism although IMHO I think
> that getting every client and proxy to support callerprefs
> would be much more difficult.

IMO it is easier to use callerprefs than this proposal. It still 
requires a UI to indicate a desire to do this - that is the same. Then 
it need only insert suitable callerpref headers into the request.

It does not require that the UAC do ENUM, though it is ok if it does. If 
ENUM is done at all, it can be done by a server along the way. And it 
needn't be user enum.

It does require that the home proxy of the target support callerprefs, 
and arrange things so that the VM server is managed in a way compatible 
with use of callerprefs in this way. AFAIK that is not typically the way 
it is today. But then of course this new enum service isn't deployed 
today as well, nor is user enum very widely deployed.

	Paul

> If the voicemail system supports access via E-mail (VPIM,
> IVM etc), the client can easily use that via ENUM lookup.
> However, if the voicemail system only supports access via
> SIP, it is at somewhat of a loss.
> 
> James 
>

---

From: "Jackson, James" <[email-masked]>
Date: Tue, 30 Jan 2007 09:48:51 -0600

In reality we would not have UAs doing ENUM queries or necessarily using a UI. Caller would simply dial something like *99 + number to reach callee's voicemail. ENUM query would be done by the network. If supported, the network would also be the one inserting the URI parameter to tell voicemail what the mailbox is. Also, this would most likely be deployed with some form of infra ENUM rather than user ENUM. Infra ENUM will already be populated to support VoIP peering so the terminating network need only provide an additional entry for voicemail rather than modify their infrastructure to support callerprefs. Perhaps this is too much of a niche application.

James 

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, January 30, 2007 8:49 AM
To: Jackson, James
Cc: Shawn Pouliotte; [email-masked]
Subject: Re: [Enum] Proposal for new enumservice "voicemail", using SIP URI

	Paul

---

From: Duane <[email-masked]>
Date: Tue, 30 Jan 2007 10:56:33 -0500

> the target phone number a second time.

While I won't go into the merits of having such an enum service, 
(although couldn't it just be a sub-type of pstn?) it seems pretty 
trivial to me to be just another SIP URI that could easily be setup, 
both in DNS and in most/all software driven PBXs.

eg

sip:[email-masked]
voicemail:[email-masked]

On the PBX you simply look for vm- strip it and send the call into the 
voicemail system.

eg

100 10 "u" "E2U+PSTN" "!^(.*)$!sip:\\[email-masked]!" .
100 10 "u" "E2U+PSTN" "!^(.*)$!voicemail:vm-\\[email-masked]!" .

-- 

Best regards,
  Duane

---

From: "Jackson, James" <[email-masked]>
Date: Tue, 30 Jan 2007 11:05:02 -0600

I have been thinking about the PSTN service in another context, but
perhaps it is more generally applicable here. Specifically, consider the
case where the called number is purely PSTN and you want to reach their
voicemail. In theory an ENUM query could return the Call Forwarding
Number and the call could be forwarded out a Media Gateway. The mailbox
would be indicated by the Redirecting Number.

James

-----Original Message-----
From: Duane [mailto:[email-masked]] 
Sent: Tuesday, January 30, 2007 9:57 AM
To: Paul Kyzivat
Cc: Jackson, James; [email-masked]; Shawn Pouliotte
Subject: Re: [Enum] Proposal for new enumservice "voicemail", using SIP
URI

eg

sip:[email-masked]

eg

-- 

Best regards,
  Duane

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 30 Jan 2007 14:33:36 -0500

A fundamental problem I have with using ENUM is that it is fundamentally 
tied to cases where the address of the callee is an E.164 number. That 
is fine in cases where the problem is intrinsically tied to the use of a 
phone number. But it is an unappealing solution to any problem that also 
applies when the callee is identified by a SIP URI. I certainly see that 
to be the case here. I just as well may want to get to the VM for 
sip:[email-masked] as for tel:+12125551234.

BTW, that also means that indicating you want VM by prefixing the 
address with *99 isn't an ideal interface. I guess it is *an* interface, 
that might be suitable for UAs that can only deal with numbers. But 
another interface will be needed for alphanumeric calling. I don't think 
the concept of adding to the callee's URI is appropriate in this case. 
Whatever technique does work for alphanumeric URIs would hopefully work 
for phone numbers as well. In general a sip UA supports a telephone 
dialing interface already needs to recognize and locally process some 
star codes, so it ought to be able to do so for this one too.

	Paul

---

From: "Jackson, James" <[email-masked]>
Date: Tue, 30 Jan 2007 13:49:26 -0600

I agree that callerprefs is a potential solution for the SIP URI case. I
don't see how it would address the Tel URI case though, or to be more
specific the case where the voicemail system is in the PSTN.

James

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, January 30, 2007 1:34 PM
To: Jackson, James
Cc: Duane; [email-masked]; Shawn Pouliotte
Subject: Re: [Enum] Proposal for new enumservice "voicemail", using SIP
URI

	Paul

---

From: "Jackson, James" <[email-masked]>
Date: Tue, 30 Jan 2007 14:02:05 -0600

Let's say this was modeled after the enumservice voice... in this case
we would have enumservice voicemail using a Tel URI.

James

-----Original Message-----
From: Jackson, James 
Sent: Tuesday, January 30, 2007 1:49 PM
To: 'Paul Kyzivat'
Cc: Duane; [email-masked]; Shawn Pouliotte
Subject: RE: [Enum] Proposal for new enumservice "voicemail", using SIP
URI

James

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, January 30, 2007 1:34 PM
To: Jackson, James
Cc: Duane; [email-masked]; Shawn Pouliotte
Subject: Re: [Enum] Proposal for new enumservice "voicemail", using SIP
URI

	Paul

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 30 Jan 2007 22:03:11 +0100

I fully support this argument
Richard

________________________________

Von: Paul Kyzivat [mailto:[email-masked]]
Gesendet: Di 30.01.2007 20:33
An: Jackson, James
Cc: [email-masked]; Shawn Pouliotte; Duane
Betreff: Re: [Enum] Proposal for new enumservice "voicemail", using SIP URI

        Paul

---

From: "Jackson, James" <[email-masked]>
Date: Tue, 30 Jan 2007 16:38:02 -0600

I'm not sure I follow. It sounds to me that we're saying that
callerprefs is the correct way to do this for a SIP URI and since we
want the same logic to apply to SIP URI and Tel URI, then we shouldn't
use ENUM to do this for Tel URI either ? So there is no benefit in using
ENUM if it only enables calls to terminate to voicemail systems that
reside in the PSTN ?
 
James

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]] 
Sent: Tuesday, January 30, 2007 3:03 PM
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [Enum] Proposal for new enumservice "voicemail", using SIP
URI

Von: Paul Kyzivat [mailto:[email-masked]]
Gesendet: Di 30.01.2007 20:33
An: Jackson, James
Cc: [email-masked]; Shawn Pouliotte; Duane
Betreff: Re: [Enum] Proposal for new enumservice "voicemail", using SIP
URI

        Paul

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 30 Jan 2007 18:29:31 -0500

James,

Do you want to turn the DNS into a softswitch?

This seems a slippery slope.

Mike

> From: Jackson, James [mailto:[email-masked]] 
> Sent: Tuesday, January 30, 2007 12:05 PM
> To: Duane; Paul Kyzivat (pkyzivat)
> Cc: [email-masked]; Shawn Pouliotte
> Subject: RE: [Enum] Proposal for new enumservice "voicemail", 
> using SIP URI
> 
> 
> I have been thinking about the PSTN service in another 
> context, but perhaps it is more generally applicable here. 
> Specifically, consider the case where the called number is 
> purely PSTN and you want to reach their voicemail. In theory 
> an ENUM query could return the Call Forwarding Number and the 
> call could be forwarded out a Media Gateway. The mailbox 
> While I won't go into the merits of having such an enum 
> service, (although couldn't it just be a sub-type of pstn?) 
> it seems pretty trivial to me to be just another SIP URI that 
> could easily be setup, both in DNS and in most/all software 
> driven PBXs.
> 
> eg
> 
> sip:[email-masked]

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 30 Jan 2007 22:19:39 -0500

Chair hat off .. I agree with Mr. Stastny and Mr. Kyzivat as well. And with
the argument that Jason Livingood makes that this is really covered By RFC
4238.

Chair hat on...

The larger issue is one we will need to deal with in Prague is that this
work group is winding down. With the Infrastructure ENUM issues now in the
hands of "higher authority" we have only one real task which is the
advancement of RFC 3761 to Draft.

We do need to declare victory here and start to close up shop unless there
is compelling technical reasons not to do so and frankly I have not seen one
recently.

> Sent: Tuesday, January 30, 2007 4:03 PM
> To: Paul Kyzivat
> Cc: [email-masked]

---

From: "Jackson, James" <[email-masked]>
Date: Tue, 30 Jan 2007 21:58:23 -0600

That's fine. RFC4238 works great if the voicemail system implements VPIM
- most do not. The VPIM service defines e-mail access to voicemail much
like the ifax service defines e-mail access to fax. However, there is
also a fax service for PSTN. If someone could shed some light on why a
voicemail service for PSTN is unreasonable that would be appreciated.

Thanks,
James

-----Original Message-----
From: Richard Shockey [mailto:[email-masked]] 
Sent: Tuesday, January 30, 2007 9:20 PM
To: 'Stastny Richard'; 'Paul Kyzivat'
Cc: [email-masked]
Subject: [Enum] The larger issue here.

Chair hat off .. I agree with Mr. Stastny and Mr. Kyzivat as well. And
with
the argument that Jason Livingood makes that this is really covered By
RFC
4238.

Chair hat on...

The larger issue is one we will need to deal with in Prague is that this
work group is winding down. With the Infrastructure ENUM issues now in
the
hands of "higher authority" we have only one real task which is the
advancement of RFC 3761 to Draft.

We do need to declare victory here and start to close up shop unless
there
is compelling technical reasons not to do so and frankly I have not seen
one
recently.

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 31 Jan 2007 10:41:16 +0100

the
there
> one recently.

I agree

What we have to find out before we close shop is how someone
may propose an Enumservice (template?) and who is making 
finally a decision.

We need also to have a procedure for x- Enumservices

Richard

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 31 Jan 2007 10:54:07 -0500

> Sent: Wednesday, January 31, 2007 4:41 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Enum] RE: The larger issue here.
> 
> 
> Richard Shockey wrote:
> >
> > The larger issue is one we will need to deal with in Prague is that
> this work group is winding down. With the Infrastructure ENUM issues now
in the hands of "higher authority" we have only one real task which is the

> there is compelling technical reasons not to do so and frankly I have not
> seen one recently.
> >
> 
> I agree
> 

Yes thank you and that is the task of the ENUM service registration draft,
which we need to review in Prague. I think Jason has been frustrated at the
lack of input to the document.

> 
> We need also to have a procedure for x- Enumservices.

I suspect it will be like many of the routine IANA procedures with a expert
committee appointed

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 31 Jan 2007 10:59:02 -0500

Because the IETF defines the voice mail service for the PSTN as the VPIM
standard. We generally don't go around creating enum services for things
that are not defined as a standard.

Frankly,  from the comments you are seeing I would not be optimistic on the
chances a draft along the lines you propose would make it through the WG.

> Sent: Tuesday, January 30, 2007 10:58 PM
> To: [email-masked]; Stastny Richard; Paul Kyzivat
> Cc: [email-masked]
> Subject: RE: [Enum] The larger issue here.
> 
>

---

From: Jim Reid <[email-masked]>
Date: Wed, 31 Jan 2007 16:10:25 +0000

> I suspect it will be like many of the routine IANA procedures with  

FWIW, this mirrors a similar concern in the dnsop WG. There the issue  
is getting a lightweight procedure for issuing codes for new resource  
record types. The WG is debugging a process that involves an expert  
(singular) making a determination. I think this model may well be a  
good idea for this WG too. IMO if an expert committee is going to be  
appointed to decide about subtypes (ie registrations for new ENUM  
services fields), you might as well just leave that to the whole WG.

---

From: "Jackson, James" <[email-masked]>
Date: Wed, 31 Jan 2007 10:55:34 -0600

It's fair for the IETF to assume that Unified Messaging platforms
supporting voicemail/fax/e-mail should all do VPIM. However, I wouldn't
say it's correct to assume that all voicemail systems will be Unified
Messaging platforms, or for that matter that voicemail and e-mail would
even necessarily be provided by the same entity.

Would the enumservices fax (for PSTN) and voice (for PSTN) be considered
standards ? I suppose we could call T.30 the standard for fax. So then
this looks more like the voice service but for non-interactive sessions.
Perhaps an alpha-pager using the TAP protocol would be fine since there
is a more defined application-level standard ?

Based on the feedback, I don't think I'll be submitting a draft :) I
just want to understand the logic for why a particular contribution
would or would not be useful. I apologize if this discussion is viewed
as disruptive to the group. Anyone can certainly respond to me off-line
if they like.

James

-----Original Message-----
From: Richard Shockey [mailto:[email-masked]] 
Sent: Wednesday, January 31, 2007 9:59 AM
To: Jackson, James; 'Stastny Richard'; 'Paul Kyzivat'
Cc: [email-masked]
Subject: RE: [Enum] The larger issue here.

Frankly,  from the comments you are seeing I would not be optimistic on
the
chances a draft along the lines you propose would make it through the
WG.

> The larger issue is one we will need to deal with in Prague is that
this
> > is fine in cases where the problem is intrinsically tied to the use
of
> a
> > > perhaps it is more generally applicable here. Specifically,
consider
> > > Subject: Re: [Enum] Proposal for new enumservice "voicemail",
using
> SIP
> > >> each mailbox (possibly by a common URI plus a parameter
identifying
> > > the
> > >> mailbox). Or at least that there is a single globally routable
URI
> for
> > >
> > >> the VM server and that the caller will be satisfied with having
to
> > > enter

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 31 Jan 2007 12:30:33 -0500

> as disruptive to the group. Anyone can certainly respond to me off-line

I don't view your submission and discussion as disruptive.

It is natural for there to be different views on how something should be 
done, and often the people holding those views don't realize that 
alternative views exist. Having the discussion surfaces the issues, 
which is a good thing.

	Paul

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 31 Jan 2007 15:06:22 -0500

> From: Jim Reid [mailto:[email-masked]]
> Sent: Wednesday, January 31, 2007 11:10 AM
> To: [email-masked]
> Cc: 'Stastny Richard'; [email-masked]
> Subject: Re: [Enum] RE: The larger issue here.
> 
> good idea for this WG too. 

Hummm interesting. What does the text look like for the procedure?

IMO if an expert committee is going to be
> services fields), you might as well just leave that to the whole WG.

Well that "committee" of experts may be 2 individuals. The ultimate issue is
the WG will start to wind down this year, stop meeting, the list and the
formal WG probably remain open but dormant for some time due to liaison
requirements with the ITU etc.

---

From: Jim Reid <[email-masked]>
Date: Wed, 31 Jan 2007 20:33:07 +0000

On Jan 31, 2007, at 20:06, Richard Shockey wrote:

>>> I suspect it will be like many of the routine IANA procedures with
>>> a expert committee appointed
>>

See RFC2929bis. The DNSEXT co-chairs appointed one of your  
colleagues, Ed Lewis, to be the expert reviewer.