Hello I want to clarify current behavior. Let's simplify our scenario. We have only ONE contact but it is PN enabled. We do lookup() for it and don't do t_relay. We get REGISTER from the device (PN enabled) within pn_refresh_timeout <https://opensips.org/html/docs/modules/3.6.x/registrar.html#param_pn_refresh_timeout> and INVITE is forked (branch route is processed). Then we get a provisional response from the device (100, then 180) and final response 486 Busy Here. And nothing happens. Caller doesn't get anything and is just waiting for something. fr_inv_timeout <https://opensips.org/html/docs/modules/3.6.x/tm.html#param_fr_inv_timeout> is not working (because final reply 486 was received? or bug?). Ok, let's assume this is a bug and we wait for fr_inv_timeout (120 sec by default). But why should we wait for fr_inv_timeout? OpenSIPS knows that all armed branches for each contact (in this case only one) are processed, final replies are received and can safely pass the final reply to the caller. This situation should be the same as with ordinary contacts without PN. What can I do in script? How do I know if all branches are processed in branch route and execute t_wait_no_more_branches?
вт, 10 февр. 2026 г. в 19:06, Vlad Paiu <[email protected]>: > Hello, > > That is the intended behavior ... couple of things here > > any REGISTERs need to come in before > > https://opensips.org/html/docs/modules/3.6.x/registrar.html#param_pn_refresh_timeout > so they get an INVITE forked > > the INVITE transaction itself will survive until > https://opensips.org/html/docs/modules/3.6.x/tm.html#param_fr_inv_timeout > is hit, since new branches might appear 'spontaneously' after REGISTERs > come in for it > > if you want to stop the waiting behavior and propagate whatever SIP > codes you received so far, calling t_wait_no_more_branches() is your option > > On 2/10/26 17:34, Andrew wrote: > > Hi > > I am currently testing built-in push notifications (pn_enable 1). I > > successfully placed a call to a mobile phone (our own client), and > > everything worked as described. The E_UL_CONTACT_REFRESH event is > > emitted; then, I send a push notification and the device updates its > > registration. Then, OpenSIPS continues the branch route, and the > > INVITE is relayed. What should I do if the device declines the call? > > The device sends 486 after trying and ringing, which are relayed to > > the caller. However, OpenSIPS doesn't relay this response to the > > caller by default. I tried waiting, but nothing happened; the call was > > just stuck. The 486 response is immediately relayed if we use > > t_wait_no_more_branches() on the branch reply route, but I don't know > > how to use it here. For example, we have three contacts per AOR, and > > we call them. One of the contacts requests push notifications. Three > > branches are armed, and all three contacts decline the call. OpenSIPS > > won't translate any 4xx response to the caller, so the call is stuck. > > Is this intended behavior or a bug? What should we do in this case? > > I've also noticed that the branch index starts at 1, not 0, when we > > have a contact with PN. What is the reason for that? :) > > > > Best regards, Andrew. > > > > > > _______________________________________________ > > Users mailing list > > [email protected] > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
