With the others, the user just signified one registration as being the primary through the web portal, or the server did it based upon what was the oldest/first registration...
Doing as you suggested and adding the phones MAC address would definitely provide a unique identifier that could be looked up easily against the phone configuration... That could also provide some very unique options for call routing as well... -- Tim On Wed, Sep 10, 2008 at 9:01 PM, Scott Lawrence <[EMAIL PROTECTED]>wrote: > > On Wed, 2008-09-10 at 19:52 -0500, Tim Jackson wrote: > > > 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... > > Do you know how the "primary" is identified in the SIP protocol? > > When a phone registers, is there an indication in the registered address > that this is the primary or some other phone-unique part of the address? > > One possibility that this suggests is to put an unique address component > into the AOR for different phones. For example, if I have two phones, > one at my office and one at home, I could register them using: > > To: <sip:[EMAIL PROTECTED] <[EMAIL PROTECTED]>;phone=office> > and > To: <sip:[EMAIL PROTECTED] <[EMAIL PROTECTED]>;phone=home> > > My interpretation of the URI comparison rules (RFC 3261 sec 19.1.4) is > that: > > 1. URIs that both contain the same uri parameter with different > values do not match each other, so an INVITE sent specifically > to 'sip:[EMAIL PROTECTED] <[EMAIL PROTECTED]>;phone=office' > should go only to that > one phone. > 2. URIs where one has a particular uri parameter that the other > lacks ignore that parameter, so a request sent to > 'sip:[EMAIL PROTECTED] <[EMAIL PROTECTED]>' should be sent to > both of the above. > > If sipXconfig were to generate an unique uri parameter for the To > address of every phone, and if (and this is a real if) the phones > correctly use that parameter when sending registrations and receiving > requests (for example, would they follow _both_ 1 & 2 above), then there > might be a way to layer device-unique addresses onto the existing user > addressing. > > For anyone out there that's thinking about release schedules, this is > _not_ something we could do in the 4.0 timeframe as we currently > envision it. The current stack code does not strictly follow those > rules (indeed, it does not have a single place where URL comparison > rules are coded, so it is not done consistently even in all sipXecs > components). Introducing this would imply at minimum a very large > regression test effort, and would almost certainly uncover lots of bugs > and create ambiguities that would need to be worked out - not to mention > testing phone behaviors. > > > >
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
