On Wed, 2008-09-10 at 11:16 -0400, Alfred Campbell wrote:
> Was looking at XECS-1652 and had some questions. If I setup a page
> group for several users and one of those users is on multiple devices
> my understanding is the following:
>
> 1. Currently there is a bug XECS-1591 which can cause certain
> pages not to work when the same user is assigned to multiple devices.
> 2. If XECS-1591 was fixed then the page would still not page all
> devices with the same user on it. I believe it is actually random as
> to which device is paged.
> Being that the administrator could setup the same user on multiple
> devices is there anyway to make this work in a predictable fashion?
> Assigning the same user to multiple devices is not uncommon so we
> should be thinking of ways to deal with this.
The short answer is "No", but of course there are ways to get the effect
that is desired.
The first thing to understand is that we don't make calls to Users, or
to Phones: we make calls to Addresses, specifically to a SIP URI.
Normally a given URI is the address of some user, but it can be
anything.
The second thing to understand is what happens in SIP when an address
resolves to more than one possible target (including when a user "line"
is on more than one phone). The INVITE message "forks", which is to
say, a copy is sent to each of the phones where the address appears -
for user lines these are normally simultaneous, so all phones that have
that "line appearance" (SIP address) on them ring at the same time.
When any one of those is answered, the proxy that forked the call sends
a CANCEL to each of the other forks, which is what stops the others from
ringing. This CANCEL is not optional - it is mandated by the SIP
standard for forked INVITEs, we can't (and shouldn't) change it.
So... if you include a User address in a paging group, and you put that
address on multiple phones, then they will all get the call and the
first one to auto-answer wins: that call will get the audio stream and
the others will not.
The only way to get around this forking behavior is to ensure that it
doesn't happen - that every address in a paging group has exactly one
appearance on any device. We _could_ do that by configuring the targets
in a paging group as a separate line on the phone. So if you want to
make my office phone be part of a paging group, then that phone gets an
additional "paging" line added to it, and the address of that paging
line is added to the group. In theory, sipXconfig could just generate
these "paging" line addresses, and then configure them onto phones as
needed.
There is an end-user interface problem with the above, however: I don't
know whether or not any currently available SIP phones support adding an
address ("line") that does not show on the user interface; I suspect
that few if any do. That means that if you create a "paging" line to
ensure unique addresses, then you use up a button on the phone, and
people will be confused/disconcerted by it.
Phone vendors take note: there are many reasons why a phone
should register a unique address that is _NOT_ associated with
any user interface line. The Pingtel Xpressa (no longer
available) had a hidden "device" line, and it was very handy for
management operations and could have been used for this too.
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
