[OpenSIPS-Users] 401 Unauthorized on BYE request

[Andrey F]

Hello Bogdan!
Thank you very much for your quick reply.

ср, 10 авг. 2022 г. в 16:49, Bogdan-Andrei Iancu <bogdan at opensips.org>:

> Hi Andrey,
>
> What you say is correct and unfortunately I have the trick here for you -
> indeed, the dialog structure is destroyed upon the first BYE (on its reply
> actually), so the second one will not match the dialog.... :-|
>
> Maybe we can have a feature request to actually have the dialog destroyed
> with a bit of a delay (similar to the transactions), but this is not so
> easy to implement.
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   https://www.opensips-solutions.com
> OpenSIPS Summit 27-30 Sept 2022, Athens
>   https://www.opensips.org/events/Summit-2022Athens/
>
> On 8/10/22 3:57 PM, Andrey F wrote:
>
> Hello team!
> Maybe anyone knows, is there a way to process a situation like this?
>
> Scheme:
> SIP Softphone A <-> OpenSIPS 3.1 <-> SIP Softphone B
>
> Steps:
> 1) SIP softphone B sent BYE request;
> 2) SIP softphone A receives BYE and tried to authorize it (sent 401
> response);
> 3) SIP softphone B receives 401 and generates a new BYE with credentials;
> 4) OpenSIPS did not pass second BYE request, because dialog was terminated
> on first BYE request.
>
> As far as I understand, SIP dialog on opensips is automatically destroyed
> after the first BYE was received.
> From https://opensips.org/docs/modules/3.1.x/dialog.html:
>
> 1.2. How it works
> ...
> The dialog is automatically destroyed when a “BYE” is received. In case
> of no “BYE”, the dialog lifetime is controlled via the default timeout
> (see “default_timeout” - default_timeout
> <https://opensips.org/docs/modules/3.1.x/dialog.html#param_default_timeout>)
> and custom timeout (see “$DLG_timeout” - $DLG_timeout
> <https://opensips.org/docs/modules/3.1.x/dialog.html#pv_DLG_timeout>).
>
>
> The second BYE witch credentials arrived to opensips very quickly (just a
> few ms).
>
> My problem is that second BYE can not pass these procedures:
> 1) *if (topology_hiding_match())*
> 2)* if (t_check_trans())*
>
>
> On first BYE I see this in logs, it is matched.
> 1)
> *if (topology_hiding_match()) logs: *
>
> DBG:dialog:api_match_dialog: We found DID param in R-URI with value of
> XXXXXXXXX
> DBG:dialog:dlg_onroute: route param is 'XXXXXXXXX' (len=12)
> DBG:dialog:lookup_dlg: dialog id=1424242860 found on entry 3032
> DBG:core:parse_headers: flags=58
> DBG:core:parse_to_param: tag=YYYYYYY
> DBG:core:parse_to_param: end of header reached, state=11
> DBG:core:_parse_to: end of header reached, state=29
> DBG:core:_parse_to: display={}, ruri={sip:1 at 1.1.1.1:1}
> DBG:dialog:next_state_dlg: dialog 0x7f16b2b95cf8 changed from state 4 to
> state 5, due event 7
> DBG:dialog:init_dlg_term_reason: Setting DLG term reason to [Upstream BYE]
>
>
> On second BYE I see this in logs, it is not matched.
> 2) *if (topology_hiding_match()) logs: *Dialog can not be matched
>
> DBG:dialog:api_match_dialog: We found DID param in R-URI with value of
> XXXXXXXXX
> DBG:dialog:dlg_onroute: route param is 'XXXXXXXXX' (len=12)
> DBG:dialog:lookup_dlg: no dialog id=1424242860 found on entry 3032
> DBG:dialog:dlg_onroute: unable to find dialog for BYE with route param
> 'XXXXXXXXX'
> DBG:core:parse_headers: flags=58
> DBG:core:parse_to_param: tag=TTTTTT
> DBG:core:parse_to_param: end of header reached, state=11
> DBG:core:_parse_to: end of header reached, state=29
> DBG:core:_parse_to: display={}, ruri={sip:1 at 1.1.1.1:1}
> DBG:dialog:get_dlg: input ci=<CCCCCCCCCCC>(37), tt=<TTTTTT>(15),
> ft=<FFFFFFFFF>(14)
> DBG:dialog:get_dlg: no dialog callid='CCCCCCCCCCC' found
> DBG:dialog:dlg_onroute: Callid 'CCCCCCCCCCC' not found
>
>
> 3)* if (t_check_trans()) **logs:* transaction can not be matched
>
> DBG:core:parse_headers: flags=78
> DBG:tm:t_lookup_request: start searching: hash=44043, isACK=0
> DBG:tm:matching_3261: RFC3261 transaction matching failed
> DBG:tm:t_lookup_request: no transaction found
> DBG:core:parse_headers: flags=ffffffffffffffff
>
>
> Finally, maybe anyone knows how to resolve this problem?
> Thank you!
>
> --
> Best regards,
> Andrey F
>
> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20220811/5bbd1ca0/attachment-0001.html>