You could just take the approach that others have (I know Sylantro behaves this way) and have the ability to have a "primary" registered phone... e.g. I have a phone and a softphone, present the user a menu in their portal that allows them to select which registration (via the useragent) is their primary and only let these type features be sent to those "primary" devices... Their ACD implementation also follows the same rules (so if there are multiple registrations, when a call to an ACD agent is sent, it is not forked, just sent to the "primary" registration)... The fall-back to that is you'd have to use the oldest registration if the user hadn't selected a "primary" endpoint...
-- Tim On Wed, Sep 10, 2008 at 6:04 PM, Mark Gertsvolf <[EMAIL PROTECTED]> wrote: > Andy Spitzer (Woof!) wrote: > > > That would only work if you bypass the proxy, sending the > > INVITE's directly to the registered address. If you don't, > > then the calls all fork anyway. > > Do you really want page's to > > bypass the proxy, and the associated permissions, CDR, and > > other issues that would cause? I didn't want to do that, and > > then have sipXpage have to take on the responsibilites of > > both the proxy AND the registrar. > > Hi Woof! > > There is no need to bypass the proxy. Registration record contains the > user's location as opposed to an AOR. As a result proxy does not fork > the request, but instead sends it to the user's location. > RLS server bypasses the proxy, but it is not necessarily a feature. RLS > server should send the subscriptions via the proxy in order to ensure > symmetric signaling for remote NAT Traversal feature to work properly > http://track.sipfoundry.org/browse/XECS-1626. There are no other side > effects of going through the proxy. > > Thanks, > Mark. > _______________________________________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev >
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
