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 example, I have a client running on my tablet. It has registered
> and has one contact binding. Then I start my smart phone client and it
> registers (same AOR) and receives its contact binding and the tablet
> contact binding in the 200OK. Would it be possible for the smart phone
> to de-register the tablet contact binding?
It is *possible* for the phone to deregister the tablet.
You might even consider it a feature.
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 doubt
that is what you want.
Note that the existing registered devices typically won't learn
immediately that they have been unregistered. But if they want to know
that right away they can discover it be subscribing to the registration
event package.
Thanks,
Paul
> Thanks,
>
> Greg
>
>
> On Wed, Dec 4, 2013 at 3:52 PM, Paul Kyzivat <pkyzi...@alum.mit.edu
> <mailto:pkyzi...@alum.mit.edu>> wrote:
>
> On 12/4/13 4:34 PM, Greg Burrow wrote:
> > Hello,
> >
> > After initial registration, the subscribers AOR has a single contact
> > binding assigned in the registrar. If the client crashes and then
> > recovers, it will re-register and the 200OK will contain the previous
> > contact binding along with the new binding.
>
> What you say is true *if* the client uses a different contact for the
> new binding. If it uses the old contact again, then not.
>
> > In this case is it recommended for the client to de-register the
> previous
> > binding?
>
> If you have some way to know with certainty that the old binding is
> yours, and not for some other UA, then it is ok and perhaps wise to
> do this.
>
> If you are not certain, then it's a bad idea.
>
> > Can this be done by explicitly listing the old contact binding
> > (with exipres=0)
>
> yes.
>
> > or does the de-register need to use contact='*', remove
> > all bindings, and force the client to re-register? If the client
> has a new
> > IP address after recovery from a crash (and a new sip.instance
> value), can
> > the old binding still be removed?
>
> If you are using RFC 5626 then things get a little more complex.
>
> Why would you have a new sip.instance value? The whole point is that
> those should be stable over time.
>
> Thanks,
> Paul
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> <mailto:Sip-implementors@lists.cs.columbia.edu>
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
