Subject: RE: [Sipping] use of SIP URI for announcements

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 22 Aug 2001 15:50:47 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, August 22, 2001 3:46 PM
> To: 'Jonathan Rosenberg'; Ben Campbell
> Cc: [email-masked]; [email-masked]; 'Christian Huitema'
> Subject: RE: [Sipping] use of SIP URI for announcements
> 
> 
> I'm extremely hesitant to try and standardize
> something like this because I doubt we will get
> it right. You really want/need flexibility here
> to make up for the mistakes you will make along
> the way until you have sufficient deployment
> experience to "get it right". And you want the
> freedom to explore different paths.
> 
> At the very least, don't try and standardize the
> URL. What about working on the problem of 
> retrieving this configuration information, perhaps
> through "out-of-band" mechanisms like HTTP. A 
> SIP OPTIONS request might also work (yes, this is
> extremely ugly). 

I was waiting for someone to suggest one of these variants.

All that happens is a transformation of the problem. Now, instead of
standardizing URL structure, you are standardizing MIB entries,
configuration parameters, or whatever. Another, somewhat better approach, is
something like SLP. This still requires standardizing service templates, but
the queries are a bit more extensible.

I'm not sure there is an easy way to solve the problem of when an automata
wishes to learn the URL to access a specific service. Either you need to
standardize the structure of the parameters of that service somewhere, or
the usage of this service is known to a human user based on surrounding
context. 

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: [email-masked]
Date: Wed, 22 Aug 2001 15:15:30 -0500

>the queries are a bit more extensible.

The transformation of the problem is exactly what I am
looking for though. Don't mandate implementation quantities
like the URL. Push this off to configuration data that can
be more easily modified. It is a level of indirection that I
am after here. Plus the mindset of standardizing URLs worries 
me a bit. I suggested URNs in a previous e-mail but didn't 
get any takers. Are there strong objections to such an approach?

SLP works for me. Or CNRP, DDDS, etc. If you want a URL,
the service: scheme is there ;) 

/sean

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Aug 2001 09:38:21 -0400

For the voicemail problem seems like there are two parts:

- how does *your* proxy server know where to send *your* voicemail.
- how does some other server figure out how to leave you a voicemail
  message without otherwise bothering you.

Callerprefs seems to give part of a solution to both of these:

- when you enroll for voicemail services, you should give your
  voicemail provider your sip address. It should then REGISTER
  itself, using callerprefs to indicate what role of service it
  is providing. Your proxy then should route calls to you to
  the voicemail endpoint when the context calls for that.

- some other ua that wants to send you a voicemail message should
  address it to you, and use callerprefs to indicate that it
  desires a voicemail service.

Paul Kyzivat
Cisco Systems