On 05 Dec 2013, at 16:34, Greg Burrow <gregbur...@gmail.com> 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? > Absolutely. If you have credentials for the account they usually apply to all bindings to the same AOR. Policies in the server could potentially change that and have different digest credentials per contact...
Observe that without subscribing to reg status the tablet will not know that someone removed the registration. /O > Thanks, > > Greg > > > On Wed, Dec 4, 2013 at 3:52 PM, Paul Kyzivat <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 >> 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 _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
