[OpenSIPS-Users] 401 Unauthorized on BYE request

Andrey F andrey at voip.ninja
Wed Aug 10 12:57:11 UTC 2022


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20220810/e479dedb/attachment.html>


More information about the Users mailing list