Subject: [sipcore] Clarifying the voicemail use-cases in RFC4244bis

From: Shida Schubert <[email-masked]>
Date: Tue, 23 Mar 2010 10:02:37 -0700

As a service provider we always use the last target as a 
target of voicemail.

 But in a corporate world, call can be forwarded to different 
user and if no one picks up, policy is usually to retarget 
the call to the voicemail of the original target. 

 As different deployment has different practice and 
requirements, it is difficult to say "A" is the only one 
you need to look at to solve the voicemail problem. 

 We can add a normative text saying if used in PBX 
environment to use the first target within its administrative 
domain and say, in non-PBX environment use the 
last target. But that's not much different from what Mary 
had on the slide.. 

  If that's not sufficient then I guess  we can add 
an identifier which identifies a target with the notion of 
 "use this target for voicemail" (May be use RFC4458?). 

 Proxy that handles the call and diverts the call to the 
voicemail after executing whatever policy can add 
this identifier.

 Regards
  Shida

---

From: Mary Barnes <[email-masked]>
Date: Tue, 23 Mar 2010 12:30:45 -0500

I'm wondering if it wouldn't be useful to show these two different
voicemail scenarios and thus we might be able to have normative text
or at least recommended behavior. I believe the HI headers would be
populated slightly differently in these scenarios, so this should
work.  In looking at all the other examples, the HI information that
is relevant is deterministic.   Thus, we might be able to make the
text stronger although I'm not convinced we can do more than a BCP
level of specification.

Mary.

On Tue, Mar 23, 2010 at 12:02 PM, Shida Schubert <[email-masked]> wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Mar 2010 16:37:13 -0400

IMO both mentioned options are broken. The proposed scenario is when 
Alice calls Bob, Bob forwards to Carol, and Carol forwards to VM.

If Carol didn't have VM, the call would have failed back to Bob, and he 
might have forwarded to his VM, or he might have then forwarded the call 
to Dave. When Carol forwards to VM she preempts Bob's ability to make 
the next policy decision.

The given scenarios for handling this mis the point - they don't give 
the control back to Bob. Instead they propose to have Carol's VM server 
use Bob's VM mailbox. This at best works if Bob and Carol use the same 
VM server, or servers that have a special relationship with one another. 
  And they still presume that Carol's VM server knows the policy that 
Bob wants to use.

Having all the info in HI does not solve this problem. The real problem 
is not one of giving Carol's VM server a list of mailboxes to choose 
among. The problem is to convey part of Bob's policy to Carol - namely 
whether to delegate the handling of call failure to Carol, or if instead 
Carol should simply fail the call attempt if there is no answer from 
Carol, and let Bob deal with that.

That is all possible with Callerprefs. If implemented it would give as 
good or better a result in all cases, and doesn't require HI.

	Thanks,
	Paul

---

From: Mary Barnes <[email-masked]>
Date: Tue, 23 Mar 2010 16:19:07 -0500

Paul,

That's one reason why we note that the call flows are examples and not
prescriptive for implementing the services ;) I don't entirely agree
that callerprefs is all that you need, but I will agree that trying to
document some of these services as only needing History-Info is not
necessarily a good idea, although many of them do just need
History-Info.

We had an offline discussion and were considering that the best
approach would be to pull the call flows (except perhaps the first
one) out into a separate document to progress as a BCP - that way we
can include the use of other mechanisms and optimize the
recommendations. Along with doing that, we propose to update the UAS
processing and the Application consideration sections of 4244bis to
have more discussion of using the new tags for services (without
prescribing services per se) would hopefully resolve the concern
raised by Cullen (and others) about the core document not describing
how to use the header (which was the agreed approach for RFC 4244, but
it seems folks realize that wasn't particularly constructive).

Separating the detailed flows in this manner is also more consistent
with how we've done protocol work in most of the other RAI WGs.  We
would of course have to determine the best home for a call flow
document.

Thanks,
Mary.

On Tue, Mar 23, 2010 at 3:37 PM, Paul Kyzivat <[email-masked]> wrote:
> IMO both mentioned options are broken. The proposed scenario is when Alice
> calls Bob, Bob forwards to Carol, and Carol forwards to VM.
>
> might have forwarded to his VM, or he might have then forwarded the call to
> Dave. When Carol forwards to VM she preempts Bob's ability to make the next
> policy decision.
>
> The given scenarios for handling this mis the point - they don't give the
> control back to Bob. Instead they propose to have Carol's VM server use
> Bob's VM mailbox. This at best works if Bob and Carol use the same VM
> server, or servers that have a special relationship with one another.  And
> they still presume that Carol's VM server knows the policy that Bob wants to
> use.
>
> Having all the info in HI does not solve this problem. The real problem is
> not one of giving Carol's VM server a list of mailboxes to choose among. The
> problem is to convey part of Bob's policy to Carol - namely whether to
> delegate the handling of call failure to Carol, or if instead Carol should
> simply fail the call attempt if there is no answer from Carol, and let Bob
> deal with that.
>
> That is all possible with Callerprefs. If implemented it would give as good
> or better a result in all cases, and doesn't require HI.
>
>        Thanks,
>        Paul
>
> Mary Barnes wrote:
>>