RE: [Enum] The larger issue here.

"Livingood, Jason" <Jason_Livingood@cable.comcast.com> Fri, 16 February 2007 21:32 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIAh7-0003lO-7e; Fri, 16 Feb 2007 16:32:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIAh6-0003k4-Cu for enum@ietf.org; Fri, 16 Feb 2007 16:32:40 -0500
Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIAh5-0003Lq-Ri for enum@ietf.org; Fri, 16 Feb 2007 16:32:40 -0500
Received: from ([24.40.15.118]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.30317700; Fri, 16 Feb 2007 16:32:16 -0500
Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Feb 2007 16:32:16 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Enum] The larger issue here.
Date: Fri, 16 Feb 2007 16:32:15 -0500
Message-ID: <45AEC6EF95942140888406588E1A6602B3BED5@PACDCEXCMB04.cable.comcast.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Enum] The larger issue here.
Thread-Index: AcdEpcz4Ug50d5rKRVGQxZ6C/ipwvQADEAx1AAzmV4AAAUYS0AAZU/sgAACS/gADL5P78A==
References: <45BDFC1A.6080108@cisco.com><C1E374E3.5565%spouliotte@nominum.com> <0CED449E95A92A42991EB71B778C17BF04780E07@TSMAIL2.ad.tri.sbc.com><45BF5AC6.7020803@cisco.com><45BF6AB1.1000802@e164.org><0CED449E95A92A42991EB71B778C17BF047BC532@TSMAIL2.ad.tri.sbc.com><45BF9D90.3050008@cisco.com><32755D354E6B65498C3BD9FD496C7D462C4C6C@oefeg-s04.oefeg.loc><011001c744e6$a7f4e5c0$22f0a544@cis.neustar.com><0CED449E95A92A42991EB71B778C17BF047BCC95@TSMAIL2.ad.tri.sbc.com><001b01c74550$bb6f6b10$22f0a544@cis.neustar.com> <0CED449E95A92A42991EB71B778C17BF047FAE62@TSMAIL2.ad.tri.sbc.com>
From: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
To: "Jackson, James" <james_jackson@labs.att.com>, richard@shockey.us, Stastny Richard <Richard.Stastny@oefeg.at>, Paul Kyzivat <pkyzivat@cisco.com>
X-OriginalArrivalTime: 16 Feb 2007 21:32:16.0443 (UTC) FILETIME=[EE02C8B0:01C75211]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472
Cc: enum@ietf.org
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

First off, do not interpret my comments as saying your I-D may not move
forward.  There are all sorts of enumservices and not everyone needs to
agree with each one.  If you have a valid app, put in an I-D so the
community can really comment and add to your idea.  

My comments simply come from the perspective of an implementer.  I
operate a SIP-based IP voicemail system in my group with a very large
number of mailboxes and was just considering this question of exchanging
voicemail between service providers.  

You are correct in pointing out that many voicemail providers do not
support VPIM.  When I personally looked at how to connect
non-VPIM-compliant systems it seemed a bit of a pain compared to ones
that were VPIM-compliant.  But I will tell you that I don't know of any
big implementations out there using VPIM at scale (if anyone does -
please chime in).  It seems to be one of those things some software
companies decided to support but no one is making much use of now.
Whenever I have seen that, even these early s/w implementations may not
work right in version 1.  I think that will change in the next few years
as providers peer real-time traffic.  It may even be that non-real-time
traffic like voicemail is a way to dip the toe into the water, so to
speak.  

A non-VPIM draft could certainly have value to some folks and who knows,
may even win out in the marketplace of implementers in the end.  I would
actually ENCOURAGE you to submit a draft.  Getting a lot of feedback is
actually GOOD.  You should be more worried when you hear silence.  ;-)

I am happy to help review the doc before or after submission and add
some use cases or other content or whatever to it if you like.

Jason Livingood

> -----Original Message-----
> From: Jackson, James [mailto:james_jackson@labs.att.com] 
> Sent: Wednesday, January 31, 2007 11:56 AM
> To: richard@shockey.us; Stastny Richard; Paul Kyzivat
> Cc: enum@ietf.org
> Subject: RE: [Enum] The larger issue here.
> 
> 
> 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:richard@shockey.us]
> Sent: Wednesday, January 31, 2007 9:59 AM
> To: Jackson, James; 'Stastny Richard'; 'Paul Kyzivat'
> Cc: enum@ietf.org
> Subject: RE: [Enum] The larger issue here.
> 
> 
> 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.
> 
> > -----Original Message-----
> > From: Jackson, James [mailto:james_jackson@labs.att.com]
> > Sent: Tuesday, January 30, 2007 10:58 PM
> > To: richard@shockey.us; Stastny Richard; Paul Kyzivat
> > Cc: enum@ietf.org
> > Subject: RE: [Enum] The larger issue here.
> > 
> > 
> > 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:richard@shockey.us]
> > Sent: Tuesday, January 30, 2007 9:20 PM
> > To: 'Stastny Richard'; 'Paul Kyzivat'
> > Cc: enum@ietf.org
> > 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.
> > 
> > 
> > > -----Original Message-----
> > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]
> > > Sent: Tuesday, January 30, 2007 4:03 PM
> > > To: Paul Kyzivat
> > > Cc: enum@ietf.org
> > > Subject: Re: [Enum] Proposal for new enumservice 
> "voicemail", using
> > SIP
> > > URI
> > >
> > > I fully support this argument
> > > Richard
> > >
> > > ________________________________
> > >
> > > Von: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > > Gesendet: Di 30.01.2007 20:33
> > > An: Jackson, James
> > > Cc: enum@ietf.org; Shawn Pouliotte; Duane
> > > Betreff: Re: [Enum] Proposal for new enumservice 
> "voicemail", using
> > SIP
> > > URI
> > >
> > >
> > >
> > > 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:alice@atlanta.com 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
> > >
> > > Jackson, James wrote:
> > > > 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:duane@e164.org]
> > > > Sent: Tuesday, January 30, 2007 9:57 AM
> > > > To: Paul Kyzivat
> > > > Cc: Jackson, James; enum@ietf.org; Shawn Pouliotte
> > > > Subject: Re: [Enum] Proposal for new enumservice "voicemail",
> using
> > SIP
> > > > URI
> > > >
> > > > Paul Kyzivat wrote:
> > > >
> > > >> 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.
> > > >
> > > > 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:123456@example.com
> > > > voicemail:vm-123456@example.com
> > > >
> > > > 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:\\1@example.com!" .
> > > > 100 10 "u" "E2U+PSTN" "!^(.*)$!voicemail:vm-\\1@example.com!" .
> > > >
> > >
> > > _______________________________________________
> > > enum mailing list
> > > enum@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/enum
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > enum mailing list
> > > enum@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/enum
> > 
> > 
> > _______________________________________________
> > enum mailing list
> > enum@ietf.org
> > https://www1.ietf.org/mailman/listinfo/enum
> 
> 
> _______________________________________________
> enum mailing list
> enum@ietf.org
> https://www1.ietf.org/mailman/listinfo/enum
> 

_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum