Feature request: redirect incoming call.

[Gerald Maguire]

    > Consider the following scenario:
    >
    > The user comes into the business center in the morning and chooses
    > cubicle A47, they pull out their PDA/phone/... and browse to the
    > business center web page and choose "Currnet Location", they get a
    > menu which is customized to the local site (since the system already
    > knows they are at the business center based upon the IP address {or
    > other data}), they either select A47 from a menu or enter it. This
    > does several things:
    > 1. it reserves the cubicle/room/... for them
    > 2. it enters the charges for using this cubicle/room/... {to allow
    >    chargebacks to the user's facilities account}
    > 3. it puts an entry in the SIP proxy for:
    >    a. the user's current wireless device
    >    b. the SIP devices in this cubicle/room/...
    >       {this can include a desk phone attached to the PBX, an IP phone,
    >        speakers, data projector,  ... }
    >
    > Now when there is an incoming call for this user - the system can fork
    > the INVITE and the user's PDA/cellphone/... desk phone ... rings and
    > the user answers which ever they want to use - the SIP proxy
    > terminates the rining on all the other devices.
    >
    > When the user leaves they either explicitly update the
    > booking/registration system or their reservation times out.
    >
    > The same can be used when a physical customer meeting occurs and the
    > user goes to the business center's conference room - where they simply
    > do another web based registration.
    >
    > As noted in my earlier mail this can all be done independently of the
    > SIP UA or devices which are used. So while it could be built into
    > minisip, why do so?
    >
    > Chip
    >

    Thanks chip, for the perspective.

    The reasons for this to be handled at UI level are the following:
    - People don't always sit at the place they booked in the business centre.
    - People don't always reserve a seat through the web.
    - We want people to be able to receive calls without performing any
    manual registration at all.
    - This is valid also when working from home (remote workers): if the user
    receives a call but is not ready to take it (headset not ready), he can
    still redirect to another phone (PSTN for example).

    So, there is a rationale for doing call deflection when ringing, at user
    agent level.

I think that by the time the UA starts rining is too late - with
respect to having the user redirect the calls as it increases the
intrusiveness of the interrupt.

If someone is working from home, then increasingly they either have
broadband connectivity with their "office" infrastructure and they can
get the call as a VoIP call or via the PSTN (or both) -- as the CPL
script which is running for them should be their "working from home"
script. Given that Bluetooth headsets such as one of the recent
Motorola ones has a standby time of 200 hours and a talk time of 8
hours - and a rather long coverage range it should be pretty easy for
a user to take a call via such a headset! (otherwise of course it is
questionable if the person is really "working") {Such a headset could
be used via a BT AP/BT dongle on the user's PC or even via the mobile
phone.

If the user does not want to have to manually register, then it would
seem that the best is to have an agent which registers for them; but
in any case it need not be the SIP UA which does the registration or
the redirect - it can be another standalone application which updates
the user's CPL to be appropriate for the user's setting and needs.

Or perhaps more succinctly: if my SIP UA "rings" and I'm not ready for
it/don't want to answer/am not in position to answer it/... , then I
expect that if I don't answer it that an appropriate redirect or
forward should simply happen.

Chip