[SR-Users] How to drop negative final response and send ACK

[Marrold]

Hi Koray,

I'm glad you mentioned this, I'm currently working on a similar
configuration and tested your scenario and found the same thing. I'm
assuming you're using TSILO?

I just quickly tried this in the failure_route and it appears to be working
but I'm sure there's still some optimisations to be done. It might need
adapting for your situation.

        if ($sht(tsilo=>active_branch::$tU) &&
t_check_status("[456][0-9][0-9]") ) {
                t_drop_replies();
                t_suspend();
                xlog("suspended transaction [$T(id_index):$T(id_label)] $fU
=> $rU\n");
                $sht(tsilo=>suspended::$tU) = "" + $T(id_index) + ":" +
$T(id_label);
                exit;
        }

One obvious issue currently is when the mobile client registers it resumes
the suspended transaction and does another look up on the location table,
and then sends a new INVITE to the device that previously rejected the
call. If that's a user that manually rejected a call it will be quite
annoying.

I'll follow up tomorrow when I've spent more time on this, but hopefully it
gets you started.

Thanks
Matthew



On Mon, Aug 16, 2021 at 4:04 PM Koray Vatansever <koray.vatansever at gmail.com>
wrote:

> Hi,
>
> I have a problem with the following scenario:
>
> I have web and mobile sip clients for the same username.
>
> If both clients are idle, INVITE is forked and both clients ring.
> If web client is busy and mobile client is online and registered, the
> mobile client rings and the caller hears ringback tone.
> If web client is busy and mobile client is offline, before the mobile
> client receives push notification and registers, web client sends 486 busy
> response and caller hears busy tone.
>
> In this last scenario, I want to wait some time for the mobile client to
> register and ring.
> I tried to drop 486 response in onreply_route[x], but I found that final
> responses cannot be dropped in this route.
> I dropped 486 in reply_route, but I couldn't send an ACK for this
> transaction.
>
> Is there a way to implement this scenario?
>
> I would appreciate if you have any suggestions.
>
> Thanks,
> Koray
>
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users at lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20210816/59c98450/attachment.htm>