And the abstract to that draft says:
At the previous meeting, the working group consensus was that Cullen
could not move this draft forward as an individual submission.
However, there was no consensus to adopt it as a WG item. This
version of the draft carefully documents exactly what it is that
Cullen may not move forward.
Which is one of the best abstract I've seen so far.
In any case, I do agree with you than when you CAN, you SHOULD use
service-specic URIs as you describe below. It is quite obvious. It is
also what is described in RFC 3087. No debate here.
However, you need some level of a workable system in the cases where
the forwarding entity and the VM systems are NOT coordinated, and where
it is not then possible to map the sevice logic to specific URIs. You
also need it for PSTN interop. You may also need it if the service logic
is different between the vendor of the forwarding device and the vendor
of the voicemail system.
I believe that History-Info will provide enough information (except
for the 302 meaning Redirect Servers vs. Retargetting issue I keep
bringing on) for a workable system. And that without replicating the PSTN.
PS: With all the rethoric about "the PSTN VM", I will point out that "PSTN VM"
systems also work the same way. They typically have a "functional"
model where the "old" PBX will request a particular service from the VM
system (à-la-RFC 3087) using some protocol, and another more basic mechanism
based on redirecting numbers for dealing with more basic PBXs or with
interop.
> -----Original Message-----
> From: sipping-bounces at ietf.org
> [mailto:sipping-bounces at ietf.org] On Behalf Of Dean Willis
> Sent: Friday, February 11, 2005 13:33
> To: Cliff McCollum
> Cc: Elwell, John; Paul Kyzivat; 'sipping at ietf.org'
> Subject: Re: [Sipping] draft-elwell-sipping-redirection-reason-01
> How about reading
> http://www.softarmor.com/wgdb/docs/draft-jennings-sip-voicemail-uri
> -02.txt?
>
> The alternative to using history for this broken sort of voice mail
> implementation is to have the element that is forwarding the
> request to
> VM (and KNOWS why it is forwarding the request to VM) use a
> different
> request-URI (or parameter) for busy-forward-treatement,
> no-answer-forward-treatment, immediate-forward-treatment, etc. The
> behavior that the VM delivers is based on the request-URI it
> receives,
> without any explicit knowledge of the processing model.
>
> Logic:
>
> &cause=(forward-to(®istered-contact));
> switch(&cause) {
> case "ok": break;
> case "busy": forward-to("user-busy at vm.example.com");
> case "refused":
> forward-to("user-hates-you at vm.example.com");
> case "noanswer": forward-to("user-away at vm.example.com");
> }
>
> I keep hearing this "We have to have History or Diversion or
> whatever
> because the PSTN encodes cause codes this way for interacting with
> voicemail". That's a weak argument. I'm unwilling to accept
> the logic
> that "SIP must do it this way because the PTSN does it this way and
> we're too lazy to think about the problem from a different
> perspective".
>
> When we follow that logic, we end up with PSTN 2.0 . . .
> constraining
> the applications to exactly what could have been done with the PSTN,
> which is pretty much pointless.
>
> History at least offers some really nifty debugging capabilities,
> although I think building an application that is sensitive to or
> dependent on history info is probably a very bad idea.
>
> --
> Dean, not as chair
>
>
>
> _______________________________________________
> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors at cs.columbia.edu for questions on current
> sip Use sip at ietf.org for new developments of core SIP
>
>
_______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors at cs.columbia.edu for questions on current sip Use sip at ietf.org for new developments of core SIP