> I haven't heard of an event server that would so severely
> limit the number of subscriptions. In any case that is
> irrelevant to the current discussion.
I'm referring to the number of simultaneous subscriptions for a user and event
package.
For instance, the server policy might limit a sin
On 12/5/13 12:11 PM, Brett Tate wrote:
>> But if the tablet is still connected, you are likely
>> to get into a fight between the two devices. The tablet
>> will presumably reregister when it thinks its current
>> registration is going to expire. And if it follows
>> the same logic, it then might d
> But if the tablet is still connected, you are likely
> to get into a fight between the two devices. The tablet
> will presumably reregister when it thinks its current
> registration is going to expire. And if it follows
> the same logic, it then might decide to unregister
> your phone. I doub
On 12/5/13 10:34 AM, Greg Burrow wrote:
> Paul,
>
> Thanks for the answers. The client restart use case would normally
> reuse the same contact binding (IP address and sip.instance). But what
> about the use case where a client attempts to de-register another
> clients contact binding.
>
> For ex
On 05 Dec 2013, at 16:34, Greg Burrow wrote:
> Paul,
>
> Thanks for the answers. The client restart use case would normally reuse
> the same contact binding (IP address and sip.instance). But what about the
> use case where a client attempts to de-register another clients contact
> binding.
>
Paul,
Thanks for the answers. The client restart use case would normally reuse
the same contact binding (IP address and sip.instance). But what about the
use case where a client attempts to de-register another clients contact
binding.
For example, I have a client running on my tablet. It has r
