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];phone=office>
and
To: <sip:[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];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]' 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
