Enpoint B also have 3600 expiry time. So, 1000 + 2600 = 3600. But you got the point.
Actually I faced more interesting issue a bit later, maybe actually it was the reason. Only 1 phone involved. Time 0 -> Enpoint A -> mid_registrar -> upstream_registrar (expires 3600) Time 1000 -> Enpoint A -> mid_registrar (just consume registration) Time 3600 -> NOTHING. upstream_registrar expires. 1000 sec GAP Time 4600 -> Enpoint A -> mid_registrar -> upstream_registrar. Yes, looks like non logic behaviour, but some of my Yealink endpoints sometimes just refreshes registration (maybe TCP network loss or so) in a middle of expires period and than - just wait for full expire time to re-register пт, 27 сент. 2019 г. в 18:53, Liviu Chircu <[email protected]>: > Hi, Igor! > > Correct me if I'm wrong, but doesn't endpoint B think it's registered > for another 1000 seconds at step 4) in your example? > > Anyway, logically speaking, on step 2), the mid-registrar should forward > the call to main reg, since there is no guarantee that any of the endpoints > will send a binding refresh register within the next 2600 seconds. For all > it's worth, A could lose its connection and B could wait between > 2601 to 3599 before re-registering, which would temporarily cause > registration > state to be incorrectly lost on the backend layer. > > Let me set up a test for this scenario and I will come back to you with > my findings. > > Regards, > > Liviu Chircu > OpenSIPS Developer > http://www.opensips-solutions.com > > On 27.09.2019 18:18, Igor Olhovskiy wrote: > > but Enpoint B still thinks it's registered at least 2599 seconds. > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Best regards, Igor
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
