Subject: [Enum] RE: better way to do johnston-enum-conf-service

From: "Johnston, Alan" <[email-masked]>
Date: Sat, 05 Mar 2005 22:58:11 -0500

Cullen,

Thanks for your comments on the draft.

I disagree that the 'sip' and 'web' ENUM service solves this problem.

The problem is allowing an application to discover that a phone number
is associated with a conference, and discovering URIs that provide
control and content related to the conference.    

If you disagree that providing a mechanism for conference discovery is
useful, then we should start with this.  However, we defined "isfocus"
for SIP to solve this problem.  H.323, PSTN, and other protocols don't
have such a useful mechanism.  Remember that all the world is not (yet)
SIP enabled :-)  For the web page, there is a huge difference between
just knowing there is some HTTP URI somehow associated with this phone
number vs. there is a web conference which provides control and content
directly associated with the conference hosted by this phone number.

If you think that having multiple ENUM service records is a bad thing,
then we should start discussing this, because this approach will require
some duplicate records.  However, I think the extra information provided
is useful, and I think others think so as well.

Thanks,
Alan Johnston
sip:alan at sipstation.com

> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy at cisco.com]
> Sent: Thursday, March 03, 2005 11:32 AM
> To: enum at ietf.org; Johnston, Alan
> Subject: better way to do johnston-enum-conf-service
> 
> 
> 
> I read this and I may be missing the point on it but it
> seemed sort of like a bad idea. The conference phone number 
> should have registrations with the services such as sip and 
> web - defining new servers will make things worse. It will 
> hamper interoperability and the existing mechanism will work better.
> 
> Imagine a UA that supports ENUM where I type in a phone
> number to call. If it supports enum today, it will do a 
> lookup, find the sip service and no what to do. Now if it 
> finds the conference service with a sip uri and sip service - 
> what does it do? which one would it choose? will we need 
> another service for IVRs? What about voicemail? What benefit 
> would it have to know that it is a conference - the signaling 
> will tell it that as soon as it contacts it in some signaling 
> protocols. Now image a conference that only published the 
> conf service in ENUM but the UA did not support this, it 
> would not work. What about if the sip service pointed to one 
> place and the conf service pointed to another. All sounds 
> like a very confusing state of affairs with little to nothing 
> to be gained.
> 
> I think I am basically saying that the the currently defined
> services in RFC 4002 and 3762 fully solve the problem that 
> this draft is trying to address.
> 
> Cullen
> 
> 
> 
> 

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

---

From: lconroy <[email-masked]>
Date: Sun, 06 Mar 2005 08:39:29 -0500

Hi Alan, Cullen, Folks,
I fully expect to include a web link to a logo/picture in my ENUM 
domain (just haven't "got a round toit" yet), as I don't have the 
privacy concerns that other do. (That'll certainly be compliant to 
RFC4002 :).

You *could* do the same for the proposed conference web link. However, 
this won't tell you that this has information on a conference. Yes it's 
a web link, so from an ENUM perspective your client needs to know only 
that it has to fire up a browser to use the generated URI. However, 
information on a conference is more than just that - it tells me that 
peripheral information on a conference is stored "behind" this service, 
and it does so right in the ENUM data I've retrieved.

How many times have you been given a dial-in number, but not known how 
to find out what's the schedule for your use of this number, or that 
there is a related number for text phones or for simultaneous 
translation, or ... ? AFAICT, Alan isn't suggesting that each of these 
be separate ENUM entries, but simply that the ENUM client knows that 
"this is where you can get the information". IMHO, it's a great idea, 
and one I trust customers can use real soon now.

all the best,
  Lawrence
On 6 Mar 2005, at 03:57, Johnston, Alan wrote:
Cullen,
then we should start discussing this, because this approach will 
require
some duplicate records.  However, I think the extra information 
provided

Thanks,
Alan Johnston
-----Original Message-----
From: Cullen Jennings [mailto:fluffy at cisco.com]
Sent: Thursday, March 03, 2005 11:32 AM
To: enum at ietf.org; Johnston, Alan
Subject: better way to do johnston-enum-conf-service

---------------------------------------
lawrence conroy    |tel:+44-1794-833666
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum