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

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

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Wednesday, August 22, 2001 3:21 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]; [email-masked]; Sean Olson; 'Christian
> Huitema'
> Subject: Re: [Sipping] use of SIP URI for announcements
> 
> 
> 
> > My first choice is always to let users access servcies 
> through things
> > like web pages or vxml voice systems. Something like:
> > 
> > <a href="sip:sadasdapda09sd98as8da0-=[email-masked]">click here 
> to initiate a
> > super-foobar automated conference with feature wizbang 
> turned on!</a>
> > 
> > THis means that I don't need to standardize anything, and a 
> SIP client
> > can access that service without needing to know about its existence
> > ahead of time. So, I get the flexibility to design services 
> that are new
> > without requiring standardization for each one. Thats a big 
> goal with
> > sip, right?
> > 
> > Yet, I seem to get a lot of pushback on that....
> 
> 
> That is exactly the intent behind rfc3087. You should not 
> need to know 
> the URL for a service in advance. The owner of the service 
> hands it to 
> you on a web page, a SIP redirect server, proxies you to it, etc.
> 
> 
> 

But, for the cases we are frequently worried about (contacting a voicemail
server, media servers, dialog servers), there doesn't appear to be an easy
way to have the information handed to you... getting it in a web page only
works for end users, not automata. How will my proxy know where to send
requests for voicemail? Thats where I don't see a lot of alternatives
besides standardization (which I would rather avoid if it was possible to
avoid).

-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: Ben Campbell <[email-masked]>
Date: Wed, 22 Aug 2001 14:41:54 -0500

Jonathan Rosenberg wrote:

> But, for the cases we are frequently worried about (contacting a
> voicemail server, media servers, dialog servers), there doesn't appear
> to be an easy way to have the information handed to you... getting it in
> a web page only works for end users, not automata. How will my proxy
> know where to send requests for voicemail? Thats where I don't see a lot
> of alternatives besides standardization (which I would rather avoid if
> it was possible to avoid).
> 

It seems to me that, in the example of your proxy forwarding a call to 
voice-mail, you are going to have to tell it one way or another. You are 
going to have to tell it _where_ the voice mail service is, so I don't 
see why it is that much bigger of a pain to just give the proxy a fully 
formed URL. This is no worse than the fact that, in the web page 
example, someone had to write (or provision something that generated) 
the HTML that included the link to the service.

3087 goes a step further, and recommends that even the voice mail server 
should be told what URL to use. This allows a service provider to use 
whatever convention they choose, instead of having the convention chosen 
in advance by the equipment provider.

---

From: [email-masked]
Date: Wed, 22 Aug 2001 14:45:46 -0500

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). 

SNMP is a possibility as well. What about having
this as an extension to the SIP MIB? 

my two cents,
Sean

---

From: "Dean Willis" <[email-masked]>
Date: Sat, 25 Aug 2001 15:52:23 -0500

Wait a sec, -- You're suggesting that your proxy should use some sort of
algorithm or naming convention to guess where to send you voice mail?

Why don't you just tell your proxy what your voicemail URL is, just like you
tell it the URL you would want it to forward to if it were doing
unconditional call forwarding?

What's next, a convention that allows my proxy to guess which hotel I'm
staying in this week? How about a standard that tells it whether I'm going
to meet a nice girl in the nightclub and wake up at her place and want my
calls there? Maybe one that will predict which dotbomb is going to fold
tomorrow?

Now I could see something like a Caller Preferences thing, that the calling
party uses to ASK my proxy to divert to  my current voicemail
destination instead of ringing me directly. That's a whole different
proposition.

--
Dean

----- Original Message -----
From: "Jonathan Rosenberg" <[email-masked]>
To: "Ben Campbell" <[email-masked]>; "Jonathan Rosenberg"
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Sean Olson"
<[email-masked]>; "'Christian Huitema'"
<[email-masked]>
Sent: Wednesday, August 22, 2001 2:34 PM
Subject: RE: [Sipping] use of SIP URI for announcements

---

From: Ben Campbell <[email-masked]>
Date: Sun, 26 Aug 2001 15:24:33 -0500

The interesting part of caller preferences here is my VM server could 
register itself _as_ a VM service, just like my phone registers as a 
general SIP endpoint. Then, whenever the proxy feels it appropriate to 
forward to voice mail, it could recursivly forward to itself using the 
caller pref syntax to request voicemail (or just follow the same logic 
internally without the explicit recursive step). This gives us the best 
of both worlds, where we use arbitrary URLs for the VM service, but we 
do not have to explicitly provision that URL at the proxy.

---

From: "Eric Burger" <[email-masked]>
Date: Mon, 27 Aug 2001 18:22:55 -0400

OK, so how do I know how to ask for a VM service?  We're just moving the onus of a URL convention (msuri) to a URI convention (the request address I send to the proxy).  I can see how it's more elegant, but it has all of the drawbacks of msuri (a convention) with the added requirement of an additional lookup.

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]]
Sent: Sunday, August 26, 2001 4:25 PM
To: Dean Willis
Cc: Jonathan Rosenberg; [email-masked]; Sipping (E-mail); Sean
Olson; 'Christian Huitema'
Subject: Re: [Sipping] use of SIP URI for announcements

---

From: Ben Campbell <[email-masked]>
Date: Mon, 27 Aug 2001 17:43:09 -0500

> OK, so how do I know how to ask for a VM service?  We're just moving the onus of a URL convention (msuri) to a URI convention (the request address I send to the proxy).  I can see how it's more ele…

It seems to me that _none_ of the proposals for identifying the URL to 
reach a given service solve the problem of knowing when you want that 
service in the first place.

A proxy could have local policy to forward to VM under certain 
circumstances. With caller prefs, this is identical to having a caller 
explicitly request VM. On the other hand, if you have a generic proxy 
with no knowledge of services, then it just moves on to the next 
registered contact by q value. If you choose your q values correctly, 
this still works, without the device registering the VM contact having 
to know how smart the proxy is.