Subject: SIP, voicemail, and UPT

From: "Adam B. Roach" <[email-masked]>
Date: Tue, 22 Jun 1999 10:38:46 -0500 (CDT)

I'd like to get a feel for what the group thinks about the following.

Most UPT services (universal personal telephone number -- the
"dial one number and it'll find me" services) will search
through a list of destinations until they find a number that answers. 
They don't care *what* answers; any answer will terminate the search.

Since many numbers have an automatic roll-over to voicemail, an
answering machine, a pager, etc., these services have been
much less useful than they potentially could be.

How would you feel about an extension to SIP -- say, a "280 Voicemail"
response code -- which would help address this problem? Proxies
which implement UPT services could then choose to continue
searching after a 280 response. Since it's a 200-class response,
any clients which don't understand it are already required to
treat it as success, so nothing breaks, and no further requirements
are placed on clients.

(Thanks to Dean Willis for raising this issue originally).

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

---

From: "David Oran" <[email-masked]>
Date: Tue, 22 Jun 1999 12:38:27 -0400

It might be better to handle this with Caller/Callee preferences and CPL
rather than start encoding specific service semantics into the protocol
operation itself.

For example, a voicemail system could SIP register with a property saying it
was a voicemail system, and callers could indicate their willingness to be
connected to a voicemail system in their preferences. CPL could sort out the
more complicated cases.

One important case that any solution should handle is the "which voicemail"
problem
(I think I noted this on the list about 6 months ago). If Mr. Big set call
forwarding to his phone to his secretary, and his secretary in turn enables
voicemail pickup, whose voicemail should the caller get? Mr. Big's or Mr.
Big's secretary?

Dave.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Adam B. Roach
> Sent: Tuesday, June 22, 1999 11:39 AM
> To: [email-masked]
> Subject: SIP, voicemail, and UPT
>
>
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 22 Jun 1999 19:12:38 -0400

Another alternative: This is what caller preferences would allow you to
indicate, so that the service doesn't go to voicemail to begin with. The
problem with 280 is that the caller (or, the UPT-providing proxy) would
have to BYE the service immediately, which seems like a waste.

---

From: Anders Kristensen <[email-masked]>
Date: Tue, 22 Jun 1999 19:06:41 +0100

> treat it as success, so nothing breaks, and no further requirements

Alternatively the callee could signal to an upstream proxy that the
answering entity is in fact a voicemail thingy by redirecting to a URL
with some extension attribute, e.g.

  A -> B: INVITE sip:[email-masked] SIP/2.0
  B -> A: SIP/2.0 302 Voicemail
          Contact: sip:[email-masked];voicemail

This also works for callers unaware of the new parameter but avoids the
callee allocating resources etc. for the case where the caller doesn't
want to go to voicemail, but at the cost of an extra round-trip.  In
both cases application semantics seep into the signalling protocol which
makes me a tad uncomfortable.

Anders

-- 
Anders Kristensen <[email-masked]>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 22 Jun 1999 16:04:15 -0400

> have to BYE the service immediately, which seems like a waste.

In fact, the proxy can't easily send the BYE (security problems + CSeq
collisions), so it would have to go back to the caller.

As Henning has pointed out, this is supported readily in the calller
preferences draft. Specifically,  the INVITE would contain:

Accept-Contact: *;feature=!voice-mail

Locations with voicemail would register:

REGISTER sip:host.com
Contact: sip:[email-masked];feature=voicemail

and the proxy would not forward the INVITE to these destinations.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---

From: Anders Kristensen <[email-masked]>
Date: Wed, 23 Jun 1999 11:34:53 +0100

> and the proxy would not forward the INVITE to these destinations.

But you *do* want it go to voicemail, but only if a non-voicemail
contact definitely cannot be found.  This would seem to imply that the
UPT-proxy needs to be able to tell the difference between an "ordinary"
404 (Not Found) failure and one that's the result of an INVITE being
rejected because of constraining caller-prefs.  So maybe that really is
best done using a new error code?

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 23 Jun 1999 09:39:54 -0400

> best done using a new error code?

I see. I'm not sure how a special error response code helps, though.
Lets say a proxy has three addresses it can forward to, one of which
says voicemail. It forwards to all three, and the voicemail UAC rejects
the the call since the caller preferences indicate no voicemail.
However, a rejection comes from the other two. The problem is that the
voicemail UAS has already rejected the call. I guess this rejection
could get propagated back to the UAC, and then it could try again
without the !voicemail attribute.

Another possibility is if the proxy first tried the non-voicemail
addresses, and then if both fail, tried the voicemail one. This can also
be supported in the current caller preferences framework:

Accept-Contact: *;feature=!voice-mail;q=0.8,
                *;feature=voice-mail;q=0.1
Request-Disposition: sequential

This basically tells the proxy to group the non-voicemail addresses
together, and try those first and then try the voice-mail ones. Of
course, what to do when the CPL for the callee says to do something
totally different is a very good question.

There is a limit to the expressiveness of the caller preferences, of
course. Its somewhere between the expressiveness of CPL and no
expressiveness at all. It was sufficient for this service, and (I
believe) is sufficient for many other useful services. 

-Jonathan R.

---

From: Anders Kristensen <[email-masked]>
Date: Wed, 23 Jun 1999 16:17:08 +0100

> without the !voicemail attribute.

Hmmm, yes. I was thinking the proxy could reissue the INVITE without the
!voicemail attribute but of course it can't. This would be handy for
operators as they could bill for the service :-)  You can't really bill
people for services performed by their own UA.

> totally different is a very good question.

This can still fail, though, in the case where a downstream proxy (or
the UAS itself) knows about both a voicemail and a non-voicemail contact
address, e.g. if the caller invites [email-masked] and the ieee.org
proxy proxies to [email-masked] and [email-masked] in turn, and
the example.com proxy always succeeds with voicemail if nothing else
works. This means the ieee.com proxy never even attempts its alternative
addresses for [email-masked] (things don't quite work out when it's a
forking proxy either).

Anyway, this differs from Classic UPT in that the onus is on the callee
to do something special to provide the caller with the service. If you
wanted to be able to provide callees with a UPT service without
requiring clients to include the caller-prefs to support it you'd have
think of something else.  One idea might be for the caller-prefs to
originate from a UPT-enabled proxy. Obviously the proxy-caller-prefs
might interact adversely with the original caller-prefs, so the proxy
could attempt to do some sort of preferences rewrite that would make it
achieve it's purpose. This could probably get pretty hairy and could
maybe give some surprising results.

Anders

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 23 Jun 1999 17:17:44 -0400

> addresses for [email-masked] (things don't quite work out when it's a

Yes, this can happen. The problem is that there is not a single proxy
which is uniquely providing this service. Caller preferences affects
routing at each server that has relevant information that can be biased
by the preferences. I believe this to be a feature, not a bug.

> think of something else.

What your describing seems exactly the point of CPL - callees describing
services without callers needing to include caller preferences.

  One idea might be for the caller-prefs to
> maybe give some surprising results.

Right; here's sort of how I think it would work then:

Consider a smart proxy which takes ownership of providing this service.
When it receivs the request above, it determines that the user wants to
first try non-voicemail addresses. So, it forwards the request to all
non-voicemail URL's it has, but changes the outgoing Accept-Contact:

Accept-Contact: *;feature=!voice-mail;q=1.0
Request-Disposition: parallel

This causes a rapid search for any terminal that is not voicemail. If
the responses all come back as non-200, it then sends out a second wave
of invites, this time with an Accept-Contact as:

Accept-Contact: *;feature=voice-mail;q=1.0

Now, of course the problem is sending out this wave of new invites. If
they are to different proxies, its all fine, since then its just like
sequential search. But, if this new invite hits a proxy which got the
original, it looks as a retransmission and the old error response is
sent. This approach (and the problem it has) is similar to what was
suggested previously. 

We could fix this with yet-another-identifier that allows different
proxied requests to appear as different transactions to downstream
servers. This is a big change and I'm not sure it works (at the very
least, as Anders points out, it may be very hairy) or is worth it, but
its something to consider.

I might add this Accept-Contact re-writing mechanism would allow us to
support the voicemail service Dave has been talking about: calls to boss
go to secretary, but to boss's voicemail if secretary is not there.

-Jonathan R.